kami

(с) не помню чье: var FProgramVersion: string; function GetProgramVersion: string; var {$IFDEF ANDROID} PackageManager: JPackageManager; PackageInfo: JPackageInfo; {$ENDIF} {$IFDEF IOS} s: MarshaledAString; {$ENDIF} {$IFDEF MSWINDOWS} Exe: string; Size, Handle: DWORD; Buffer: TBytes; FixedPtr: PVSFixedFileInfo; {$ENDIF} begin if FProgramVersion <> '' then begin Result := FProgramVersion; exit; end; {$IFDEF ANDROID} PackageManager := TAndroidHelper.Context.getPackageManager; PackageInfo := PackageManager.getPackageInfo(TAndroidHelper.Context.getPackageName, 0); Result := JStringToString(PackageInfo.versionName); {$ENDIF} {$IFDEF IOS} s := TNSString.Wrap(CFBundleGetValueForInfoDictionaryKey(CFBundleGetMainBundle, kCFBundleVersionKey)).UTF8String; Result := string(s); {$ENDIF} {$IFDEF MSWINDOWS} Exe := ParamStr(0); Size := GetFileVersionInfoSize(PChar(Exe), Handle); if Size = 0 then begin Result := 'Unknown'; exit; end; SetLength(Buffer, Size); if not GetFileVersionInfo(PChar(Exe), Handle, Size, Buffer) then begin Result := 'Unknown'; exit; end; if not VerQueryValue(Buffer, '\', Pointer(FixedPtr), Size) then begin Result := 'Unknown'; exit; end; Result := Format('%d.%d.%d.%d', [LongRec(FixedPtr.dwFileVersionMS).Hi, // major LongRec(FixedPtr.dwFileVersionMS).Lo, // minor LongRec(FixedPtr.dwFileVersionLS).Hi, // release LongRec(FixedPtr.dwFileVersionLS).Lo]); // build {$ENDIF} FProgramVersion := Result; end;

У CnPack есть функция "Полный экран". Но она работает только в Classic Undocked, что не интересно... А в обычном для D2009Up (или еще раньше?) режиме - пишет --------------------------- Ошибка --------------------------- Окно редактора закреплено или не существует --------------------------- ОК ---------------------------

в объявлении reference to procedure забыт пробел между const и названием переменной. Синтаксис отличается и компилятор ругается.

Поправка: RemoveQueuedEvents вызывается само в деструкторе TThread. Если важно, чтобы все синхронизируемые события отработали - при уничтожении TThread в главном потоке нужно вызывать System.Classes.CheckSynchronize(0) до того момента, как оно вернет False.

Разница есть. И она не только в вызове Synchronize, но и Queue. Указание потока в качестве источника метода синхронизации позволяет вам впоследствии сделать TThread.RemoveQueuedEvents(myThread) перед его удалением. Вызов RemoveQueuedEvents необходим, если в синхронизируемых методах может идти обращение к полям и методам уничтожаемого потока. Потому что с удалением потока то, что подлежало синхронизации, никуда не пропадет, а раз поток уже не существует - у вас вылезет AV на ровном месте. Или же ваш код испортит чью-то память, что еще труднее отловить.

Лучший вариант здесь был предложен с AllocateHWND. Только вот в реализации оконная процедура очень подкачала. Не будет такое окно работать.

Попробуйте использовать Navigate (без параметров) вместо Reload. Ну и - делать невидимую работу по правке файла, используя визуальный компонент (Memo) - это, мягко говоря, не комильфо.

Ну, хотя бы потому, что FMX - кроссплатформенен. И в угоду совместимости между платформами приходится от чего-то отказываться, чтобы "оно" без переделок (или с минимальной доработкой напильником, а не кувалдой) работало и на Win, и на iOS, и на MacOS и на Android. Ах, да - забыл. Теперь же еще и Linux. Добавляйте свою анимацию.

https://msdn.microsoft.com/ru-ru/library/windows/desktop/ms644959(v=vs.85).aspx Смотреть в основном про WH_KEYBOARD (перехват в рамках приложения) или WH_KEYBOARD_LL (перехват в рамках всей системы). Примеров в гугле должно быть навалом, подойдут даже от D7 (возможно - с поправкой на юникод), ибо этот механизм не менялся уже сто лет. Но - еще раз подчеркну - это привязка к винде.

нет. Веббраузер - нативный компонент, со своим собственным механизмом работы. Емнип, даже под Windows, даже используя штатный полнофункциональный IWebBrowser2 вы не получите нажатия из него. На винде вы можете поставить хук на клавиатуру и получать все клавиши вне зависимости от того, в какой контрол они летят. На мобильных платформах - нет.

Вы не там ифдефы пишете. Не нужно здесь много модулей. Для примера. (емнип - автор @Равиль Зарипов (ZuBy) ). Единая точка входа в функцию и отличаются только внутренности. function OpenURL(const URL: string; const DisplayError: Boolean = False): Boolean; var {$IFDEF ANDROID} Intent: JIntent; {$ENDIF} {$IFDEF IOS} NSU: NSUrl; {$ENDIF} {$IFDEF MSWINDOWS} Res: HINST; {$ENDIF} begin {$IFDEF ANDROID} // There may be an issue with the geo: prefix and URLEncode. // will need to research Intent := TJIntent.JavaClass.init(TJIntent.JavaClass.ACTION_VIEW, TJnet_Uri.JavaClass.parse(StringToJString(TIdURI.URLEncode(URL)))); try TAndroidHelper.Activity.startActivity(Intent); exit(true); except on e: Exception do begin if DisplayError then TDialog.ShowMessage('Error: ' + e.Message); exit(False); end; end; {$ENDIF} {$IFDEF IOS} // iOS doesn't like spaces, so URL encode is important. NSU := StrToNSUrl(URL); if SharedApplication.canOpenURL(NSU) then exit(SharedApplication.OpenURL(NSU)) else begin if DisplayError then TDialog.ShowMessage('Error: Opening "' + URL + '" not supported.'); exit(False); end; {$ENDIF} {$IFDEF MSWINDOWS} Res := ShellExecute(0, 'open', PChar(URL), nil, nil, SW_SHOW); Result := Res > 32; {$ENDIF} end; И теперь "снаружи" этой функции вам без разницы, под какую платформу идет сборка. В любом случае вы пишете "OpenURL('http://blablabla.net');". Безо всяких IFDEF.

На 10.2 никаких танцев не требуется. Проблемы только начиная с 11 версии, поскольку 11 симуляторы хотят работать только под 64 бита. А делфя пока не умеет мак в 64 бита.

Без малейшего понятия, это надо у заказчика спрашивать. У них планшеты отключены от "глобального" эппла, подсоединены к локальной MDM-системе и полностью контролируются именно ими.

на iPad, у нас жесткое ограничение - информация на экранчик телефона просто не влезет :))) Причем - на устройстве работаем без отладки (эта функция отключена корпоративной политикой безопасности). поэтому только лог. Удаленный + локальный.

у нас в качестве сборщика - какой-то древний макмини. До iOS11 напрягало, что симулятор для отладки запускается безумно медленно. А как перешли на Токио + IOS11 - эта проблема перестала играть роль, поскольку симулятор теперь просто не работает . Радикальное такое решение проблемы :)))

С каких пор в Delphi перестали существовать TCriticalSection, TMutex, TEvent? Которые, кстати, работают кроссплатформенно, используя штатные средства, предоставляемые ОС.

А как? Ну, на винде в теории можно из другого потока закрыть хендл соединения (если используемый для сетевого обмена компонент дает возможность получить хендл). А вот кроссплатформенный штатный HTTPClient -???

нет. Вся работа с визуальными компонентами - только в основном потоке. Только. Если вы пытаетесь работать в доп.потоке, то как сказал @Rusland - нужно оборачивать в Synchronize. Или Queue. Обязательно. Любой из этих двух методов производит переключение в основной поток. и изменение текста+отображение будет идти именно в нем. Надо учитывать, что эти два метода синхронизации с основным потоком дают накладные расходы по времени работы.

Вы обладатель великолепнейшего зрения, реакции и т.п. если в состоянии распознать и проанализировать за 100мс содержимое экрана На самом деле эта проблема аналогична "хочу, чтобы показывалось все 100500 записей" - пользователь физически не сможет оценить всё то, что вы ему отображаете + получается, что сильно нагружается система абсолютно ненужными действиями. Логируйте значения, сохраняйте их в БД, проводите внутренние манипуляции в реальном времени. А пользователю - поставьте таймер, в котором показывайте последнее пришедшее значение + при желании "всего принято столько-то фреймов данных" (по аналогии с отображением количества кадров в секунду).

Зато избавиться от проблем, которые еще не обнаружились, 100% не проявятся при соединении внутри одного компьютера, в 95% случаев не проявятся в одноранговой локалке... но принесут дикую головную боль в этих оставшихся 5%, и 100% будут при соединении через интернет. В отличие от http, в котором все такие проблемы уже решены и реализована именно нужная тебе схема: отправил запрос и получил ответ. Но - хозяин-барин.

Я все-таки повторю свой вопрос: если в одной из реализаций ты пришел к взаимодействию вида запрос-ответ-разрыв связи, то почему не использовать http вместо tcp?

http://fire-monkey.ru/forum/183-tfgactivitydialog/ Вот этот компонент спасет отца русской демократии. Правда, для винды его пришлось чуть дополнить (на самом деле Ярослав уже всё сделал, я только мелкие шероховатости поправил).

CreateProcess, StartupInfo, ProcessInformation, WaitForSingleObject, CloseHandle объявлены в WinAPI. У других операционных систем методы запуска другие.

тогда TCP не нужен. Юзай http, который использует нативность на всех платформах.

Скорее всего, и не будет. Чтобы не висло, вся работа (включая создание) клиента должна вестись в отдельном потоке. А если сперва на винде попробовать?