» Вопросы по Embarcadero RAD Studio XE3

HeMet

Цитата:

У кого XE3 с последним апдейтом, можете сказать? что написано в TPlatformWin.RegisterCanvasClasses и TPlatformWin.UnregisterCanvasClasses?

procedure TPlatformWin.RegisterCanvasClasses;
begin
FMX.Canvas.D2D.RegisterCanvasClasses;
FMX.Canvas.GDIP.RegisterCanvasClasses;
end;

procedure TPlatformWin.UnregisterCanvasClasses;
begin
FMX.Canvas.D2D.UnregisterCanvasClasses;
FMX.Canvas.GDIP.UnregisterCanvasClasses;
end;

sergionn

По поводу мака и хакинтоша - хакинтоши глюкавы и плохо работают на последних версиях ОС Х. Так что если есть желание разрабатывать на маке или ios -это 100% нужно брать маковское железо.

По поводу "разработке в вритуальной машине" - имхо, это ок, так и надо даже на вин делать. Не вижу никаких сложностей в CrossBox на мак - софтина ставится тупым копированием .app в папку /Applications. Более того, у ЭМРО абсолютно так же было на XE2 - только их софт назывался PAServer, и ставится он чуток сложнее, и не имеет ГУЯ (в отличие от РО).

По поводу - "зачем нужен этот костыль". Ну - это дело вкуса, обсуждать вкусы смысла нету..

Важно понимать разницу между ЭМРО и РО.

У ЭМРО была эмуляция GUI через FMX, и даже они отказались от этого подхода, убрав поддержку iOS из XE3. Лично могу сказать, что на XE2 писанный софт на топовом (на тот момент) iOS-железе еле ползал. Скоро нам явят Delphi for iOS, где "все будет по-другому". Ну - когда явят, тогда и посмотрим, обсуждать чего именно сделают смысла не вижу!

У РО другой подход - онги делают свой софт нативным на платформе. В чем смысл такого кросс-платформенного софта? В том, что часть софта можно сделать кросс-платформенным. Это примерно 15-40% кода приложения, который может быть общим между разными платформами. Оставшийся код - это ГУЙ, который для каждой платформы специфичный. Имеет ли для вас смысл ради 15% кода брать РО?

Ну и еще одно соображение - все продукты РО интегрированы в VS2012. Если юзать их, вы немного избавляетесь от "зоопарка" средств разработки, которыми приходится пользоваться. Но - опять же, не полностью! Все равно все нужные SDK должны быть. Не знаю - кого как, а меня раздражает "скакание" по разным IDE. Другой вопрос, что для средних и больших проектов есть несколько программеров, для каждой платформы может быть своя группа - ну и ей естественно проще использовать нативные средства платформы.

Так что решения РО - для небольших групп разработчиков, которые хотят поддерживать большой спектр платформ (возможно) чуть-чуть проще, чем при "дефолтных" решениях. Как то так планируется!))


Добавлено:
HeMet

"РО никогда не предлагала фреймворков".

Для РО основным бизнесом является либа Дата Абстракт + RO SDK, которые как раз кросс-платформенные. Только сейчас они для каждой платформы нативные. Поэтому в определденном смысле РО хлебнули поддержки разных платформ.

Что получится из Sugar - вопрос открытый. пока либа довольно скромная.

deks
1) Хакинтош основанный на том же железе, что и оригинал работает так же как и оригинал. Купить оригинальное железо можно в ближайшем компмаркете за "сущие копейки"
2) Разработка на виртуальной машине - это как секс с презервативом - все делаешь правильно, стараешься,
а понять не можешь, что происходит, нет обратной связи с процессом, и результат на 100% не понятен.
+ Стоит у меня Vmvare player + osx 10.8 - часть программ использующих opengl и шейдеры не работают, хотя галочка "accelerate 3d graphics" стоит.
3) Я в своих рассуждения ПОКА еще НЕ высказывал суждение о emb Moblie studio - ибо не о чем пока.
4) Мне пофиг на чем ro делают деньги, я вижу что подход их в корне неверный:
дядьки успешно сделали ПОЧТИ кросплатформенный, ПОЧТИ паскаль, но не сделали самого главного
- кросплатформенной библиотеки, ради которой в принципе вся суета и должна была затеваться.!
Внутренняя логика конкретно моего приложения - это 15-20% кода, все остальное это гуи, взаимодействие с пользователем, вывод данных, сеть.

sergionn
Ну что здесь в общем можно сказать: Пишите свою IDE, которая удовлетворила бы всем требованиям. Пишите свой компилятор, который собирал бы все для нескольких систем.

А на Embarcadero жаловаться нечего - это уже не Borland и не CodeGear, это другая фирма со своим путем, не самым приемлемым для всех нас.

P.S. Это все же утопия, чтобы они писали нормально IDE и компиляторы, а не бесконечно тянули деньги за недоработанные продукты.

sergionn

На счет железа - у мака есть хитрый bios, который не всегда получается пихнуть в хакинтош - отсюда все проблемы с хакинтошами. Поэтому разработку для мака лучше делать на маковском железе. При этом для маковского железа существуют вполне официальные драйвера для windows - через boot camp. Так что для разработчика маковский компьютер удобен.

OpenGL на виртуальной машине да, не стоит разрабатывать) Для этого, возможно, придется грузить комп в нативную ОС. Однако и Fusion, и Parallels на мак в последних версиях все меньше лажают с графикой.

По поводу подходов к кросс-платформенности: у РО просто свой подход, у ЭМРО свой. Выбор за пользователями. Но у обоих все решения в стадии бэта, поэтому сравнить не получится! Одно могу сказать - то что у ЭМРО было в XE2 на FMX - неработоспособно на iOS. Что сделают сейчас - посмотрим. Также могу сказать, то - что у РО есть для iOS сейчас - вполне работоспособно. Но нет готовых кросс-платформенных приблуд.. Sugar в стадии closed beta. Даже DataAbstract и SDK - пока не портированы под Oxygene!

если это про UEFI то cейчаc вроде почти все материнки его имеют, и Win64 грузщится через него, а не через старый DOS BIOS

Кстати, забавно как CodeTyphon (дистр Лазаруса) говорит про некую Orca Lib

Типо это - наш ответ на FireMonkey

Возможно издалека ,с концептуальной точки FMX не так безнадежен, как мы привыкли думать

Arioch1

Не совсем про EFI - помимо него, нужна поддержка железа конкретного PC в OSX, которую туда добавить сложно. Вся проблема не собственно в EFI, а в его содержимом от Apple. Плюс в схеме добавления поддержки железа в OSX. Все эти kext, DSDT и прочее - это из этой же оперы. В общем, хакинтош делается тогда, когда повезет - что все PC железо совместимо или для него есть хорошие кряки по добавлению драйвера этого железа в OSX (методов много). Ну или нужно при покупке PC планировать именно хакинтош, чтобы PC-железо было совместимое. На мой взгляд, геммороя больше чем переплаты за Mac-железо (больше касается нотебуков). Если уж зажглось сделать хакинтош, то проще это сделать из специально купленного desktop PC. Имхо, много инфы по теме на _http://wiki.osx86project.org/ Сделать из ноутбука хакинтош - иногда просто невозможно.

Про FMX: концептуально две проблемы. Одна - с GUI: эмуляция всегда будет не идеальной. Некоторые контролья сложно сделать - html/web view, rtf view. И вторая: интероп с Objective-C runtime и другими имеющимися SDK. Зачем нужна среда для программирования iOS, которая не может задействовать имеющиеся SDK для iOS? Или снова - дожидаться когда все свое сделаем для Дельфей?

как узнать программу по умолчанию, которая открывает файл с определенным разрешением или узнать, что такой программы нет и назначить ее?

neznayka3
Проверять наличие соответствующего узла в ветке HKEY_CLASSES_ROOT\ реестра.

c++ bulder xe3 embarcadero rad studio x64
Сколько строк влезет, размер строки, общее ограничение по памяти на экземпляр класса TStringList ?
Сколько экземпляров максимального размера поддержит приложение ?
Скорость работы в рассмотрение не брать.
Заранее спасибо !
А. Дорин
SKYPE ALEXANDER_A_DORIN

Доброго времени суток!
Подскажите, есть ли в XE3 встроенный механизм работы с SVN? Если да, то где его найти/настроить?

vcrank
Есть. Прямо в меню File можно выбрать загрузку проекта из SVN репозитория. Сравнение версий интегрируется во вкладку History в дизайнере. Коммиты, емнип, через ПКМ на дереве проекта.

HeMet
Что-то я не разобрался. Выбрал нужный пункт. Спрашивает какой-то URL. Что именно вводить?
Как свежесозданный проект загрузить в репозиторий?

vcrank
ПКМ в Project Manager, там выбрать Add to Version Control. Указать адрес репозитория, где будет храниться проект. Репозиторий - это папка, которая содержит папку .svn. Однако, Студия, кажется, сама репозитории не позволяет создавать. Поэтому, либо юзать какие-то интернет-сервисы типа code.google.com либо качать дистриб SVN сервера, ставить себе на комп и создавать репозиторий у себя на компе. Может быть, ещё какие-то варианты есть, но я их не знаю.

neznayka3

Цитата:

как узнать программу по умолчанию, которая открывает файл с определенным разрешением или узнать, что такой программы нет и назначить ее?

вот тут есть ответ http://stackoverflow.com/questions/2577213/how-can-i-get-the-name-of-the-program-associated-with-a-file-extension-using-del

> в XE3 встроенный механизм работы с SVN

Имхо не стоит. Есть встроенный, от Уве Шустера. Есть альтернативный от Jedi CodeLib
И то и другео половинчатое какое-то.

Скажем, закоммитить пару модулей в Git - сойдёт. А вот всерьез работать - лучше через черепаху.
С SVN чуть лучше, но не намного.

Arioch1
Собственно я и использую TotroiseGIT, хотя раньше у меня стоял Version Insight Plus от Шустера. Сейчас он, почему-то за сайтом не следит, но в репозиторий коммитит.

Подскажите ещё пожалуйста Code Formatter для XE3
Обычно пользуюсь GExpert, но для XE3 его ещё нет

Отмена вопроса.

vcrank
а стандартный не подойдет?
http://docwiki.embarcadero.com/RADStudio/XE3/en/Formatting_Source_Code

XPerformer
Я про него читал, но найти (expand the Formatter node) не смог. Наверное из-за того, Что у меня Lite версия

мне тут интересный вопрос задали, а ответа я не знаю. Может ли современная среда Embarcadero компилить флеш приложения?

mdid
Нет. Эта среда для разработки под Delphi, C++ Builder и отдельно HTML5 + JS.

Вопрос по выравниванию кода тоже снимается. Нашёл GExperts в блоге разрабов
http://blog.dummzeuch.de/experimental-gexperts-version/

подскажите в чем сейчас лучше писать документацию для юзеров. никогда этим не занимался.

neznayka3
Для delphi лучше всего подходит Help&Manual (платная, но стоит того).
А так можно и в блокноте писать.

нужен обобщенный контейнер очереди с приоритетами, и с поддержкой обобщенного же интерфеса к нему
TPriorityQueue<TItem> = class( IPriorityQueue<TItem>)...
с возможностью произвольного удаления элемента
есть ли такой?

Добавлено:
еще вопрос: есть ли какая нибудь либа , реализующая синхронизирующую блокировку (Critical Section) в виде функции с ключом, как функция
lock(this)
скажем в решетках?
то есть

Код: resourceLock(self);
try
...
finally
resourceUnlock(self);
end;

AlekXL

Цитата:

еще вопрос: есть ли какая нибудь либа , реализующая синхронизирующую блокировку (Critical Section) в виде функции с ключом, как функция   lock(this) скажем в решетках? то есть

TMonitor.Enter(); TMonitor.Exit(); - одни из древнющих методов в Delphi прямиком из System.pas, которые ещё и быстрее, чем крит. секции/мьютексы;

Цитата:

TMonitor.Enter(); TMonitor.Exit();

спс. хотя не такие уж и древние. Со времен 2009, кажется.
В-том то и беда , что у меня, как и многих , знания Delphi застыли если не на уровне D7, то на D2007
А потом некоторые из таких ренегатов жалуются, что язык умер

Eternal_Shield,


Цитата:

TMonitor.Enter(); TMonitor.Exit(); - одни из древнющих методов в Delphi прямиком из System.pas, которые ещё и быстрее, чем крит. секции/мьютексы;

Захотелось проверить, быстрее ли TMonitor чем крит. секции. Увы, на XE и XE3 (Win32) крит. секции быстрее ровно в 2 раза.