У меня есть Delphi 2010 exe, который запускает второй exe.Во втором exe есть диалог, который вызывает openDialog.execute.Когда это выполняется под Windows 2008 Enterprise R2 с удаленным рабочим столом, оно работает, как и ожидалось, , но при запуске в качестве удаленного приложения , как только всплывает диалоговое окно файла, приложение зависает, поворачивая все приложениеокна белые.Единственный способ выйти из него - закрыть приложение.Я попытался заменить TOpenDialog на TFileOpenDialog, результаты совпадают.Я рассмотрел изменение файла RDP, который запускает основное приложение, но не видит там никаких параметров, которые могли бы изменить ситуацию.Кто-нибудь когда-либо видел такое поведение раньше?
2010.07.13 Обновлено
Воспроизводится на простом примере.В примере есть два исполняемых файла.Первый - это средство запуска файлов, называемое m_module.exe, которое содержит одну кнопку редактирования, одну кнопку и приведенный ниже код.Я изменяю имя исполняемого файла в редакторе, чтобы он соответствовал второму исполняемому файлу, прежде чем я нажму кнопку запуска:
procedure TForm1.Button1Click(Sender: TObject);
begin
ShellExecute(Handle, 'open', stringToOLEstr(edit1.text) , nil, nil, SW_SHOWNORMAL) ;
end;
procedure TForm1.FormShow(Sender: TObject);
begin
edit1.text:=application.exename;
end;
Второй исполняемый файл содержит кнопку и код ниже:
procedure TForm1.Button1Click(Sender: TObject);
begin
OpenDialog1.execute;
end;
Первый модуль запускается из файла RDP.
2010.07.14 Обновлено
Я обнаружил, что если я копирую следующие библиотеки:
thumbcache.dll
dtsh.dll
wkscli.dll
из папки \ Windows \ System32 в папку приложения, проблема устранена.
Я также обнаружил, что изменение уровней владения и разрешений для этих библиотек в папке \ Windows \ System32 с TrustedInstaller на группу администраторов приводит к тому же результату (копирование их в каталог приложения меняет владельца и права доступа.)подумайте)
Чтобы подтвердить это, я убедился, что ошибки появились снова, если я изменил уровни владения и разрешений обратно на TrustedInstaller вне группы администраторов.
Так что, похоже, это проблема доступа какого-то рода.Возможно, это поможет выяснить причину проблемы.
2010.07.18 Обновлено
Некоторая дополнительная информация, которая может быть полезна (предоставлена Embarcadero):
Эта статья MSDN для GetWindowsDirectory http://msdn.microsoft.com/en-us/library/ms724454%28VS.85%29.aspx описывает интересное поведение приложений, работающих в службах терминалов.Хотя GetWindowsDirectory не вызывается напрямую, песочница системного каталога Windows для пользователя может вызывать какие-то проблемы.Возможно, одна из библиотек DLL в вызывающей цепочке GetOpenFileNameA пытается сослаться на настоящую DLL в реальном системном каталоге, а не в изолированную, вызывая нарушение прав.Это просто предположение, но это стоит исследовать.Если вы смогли заставить SysInternals Process Monitor или Process Explorer работать на сервере, вы должны увидеть commdlg32 и другие DLL в загружаемой трассировке стека.
Все устаревшие приложения (т. Е. Все приложения, не созданные для служб терминалов или служб удаленных рабочих столов) работают на уровне совместимости приложений.См. Эту статью MSDN http://msdn.microsoft.com/en-us/library/cc834995%28VS.85%29.aspx.Флаг IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE определен в Windows.PAS.В целях тестирования вы можете добавить его в PE-заголовок вашего приложения, добавив Windows в раздел USES вашего приложения и прямо в разделе USES введите:
{$ SetPEOptFlags IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE}
Это приведет к тому, что ваше приложениеобойти уровень совместимости.В настоящее время я изучаю, сохраняют ли порожденные процессы (например, ваш второй exe) все права и настройки приложения, определенные в RDS.