» Вопросы по Delphi (версии 2009, 2010 Weaver, 2011 Fulcrum)

eddoc
Вот и хорошо, что все получилось ).
Я скоро над новым проектом трудиться буду - вот и посмотрю, как все под ХЕ2 обстоит ).

Win7 x64: чЮдеса в решете

В коде [more=читаю ключик из реестра]
Код: function TForm1.FindFBDir: string;
var RegKey: TRegistry;
begin
Result:= '';
RegKey:= TRegistry.Create;
try
with RegKey do
begin
RootKey:= HKEY_LOCAL_MACHINE;
if KeyExists('SOFTWARE\Firebird Project\Firebird Server\Instances')
then
begin
OpenKeyReadOnly('SOFTWARE\Firebird Project\Firebird Server\Instances');
if ValueExists('DefaultInstance')
then
Result:= ReadString('DefaultInstance')
end;
end;
finally
RegKey.Free;
end;

eddoc
А здесь и так всё ясно и известно: х86 приложения на х64 винде работают через WoW (Windows on Windows) прослойку. Имхо, ничего серьёзного. Управляется ключами KEY_WOW64_32KEY и KEY_WOW64_64KEY. Например, KEY_ALL_ACCESS or KEY_WOW64_64KEY.

Подробнее здесь, если есть сомнения: http://msdn.microsoft.com/en-us/library/windows/desktop/ms724878(v=vs.85).aspx

Eternal_Shield

Цитата:

WoW (Windows on Windows)

"Так вот ты какой, северный олень!" (с)

А я все время читаю эту аббревиатуру как "Вау!!!" Спасибо за информацию.

Кто-то уже разбирался с delphi xe2 vcl styles?
Я заметил интересную особенность. Когда их использовать, то изменение некоторых свойств компонентов (например memo1.color:=clLime; или label1.font.color:=clBlue;) не влияет на отображение компонент. Полагаю что цвета заданные в стиле имею больший приоритет чем те, что в свойствах компонент. Не подскажите как изменять цвета отдельных компонент в ран тайм режиме при использовании vcl styles?

Кто-нибудь, объясните разницу между TRegistryIniFile и TRegIniFile . Когда какой из этих классов использовать?

Bonivur
Ну есть же справка и гугл

[more=TRegIniFile]TRegIniFile is a low-level wrapper for the Windows 95/NT system registry.
TRegIniFile presents a simple interface to the system registry, hiding the need to know about the underlying structure of the registry. TRegIniFile acts as a helper object to TRegistryIniFile, which descends from TCustomIniFile (and is therefore more widely compatible with other INI file classes).
TRegIniFile enables handling the Windows 95/NT system registry as if it were a Windows 3.x INI file. Instead of processing an INI file, however, TRegIniFile reads from and writes to the system registry.
Although TRegIniFile descends from TRegistry, it adds the properties and methods used by a TIniFile object. The FileName passed to a TRegIniFile object becomes a subkey under the system registry's root key (HKEY_CURRENT_USER by default). What corresponds to a section in an INI file is treated as a key in the system registry, and what corresponds to data entries under a section in an INI file are treated as data values under a key in the system registry.
Note: TRegIniFile is intended to be used primarily as a helper object to TRegistryIniFile, which unifies the interface to INI files and the system registry. However, applications can use TRegIniFile directly.

----- rus -------
TRegIniFile является низкий уровень оболочка для системного реестра Windows 95/NT.

TRegIniFile представляет собой простой интерфейс для системного реестра, скрывать нужно знать о базовой структуре реестра. TRegIniFile действует как вспомогательный объект TRegistryIniFile, которая спускается от TCustomIniFile (и, следовательно, более широко совместимы с другими классами файл INI).

TRegIniFile обработки позволяет системе Windows 95/NT реестра, как если бы это были INI Windows 3.x файл. Вместо обработки ini-файле, однако, TRegIniFile чтение и запись в системный реестр.

Хотя TRegIniFile спускается с TRegistry, она добавляет свойства и методы, используемые TIniFile объекта.FileName передается TRegIniFile объект становится подраздел под корневой раздел системы реестра (HKEY_CURRENT_USER по умолчанию). Что соответствует раздел в INI-файл рассматривается как ключ в системном реестре, и то, что соответствует записи данных в разделе INI-файл, рассматриваются как значения данных под ключ в системном реестре.

Примечание: TRegIniFile предназначена для использования в основном в качестве вспомогательного объекта TRegistryIniFile, которая объединяет интерфейс для INI файлов и системного реестра. Тем не менее, приложения могут использовать TRegIniFile напрямую.[/more] vs [more=TRegistryIniFile]TRegistryIniFile is a wrapper for the Windows system registry.
TRegistryIniFile presents a simple interface to the system registry and hides the need to know about the underlying structure of the registry. TRegistryIniFile enables handling the Windows system registry as if it were a Windows 3.x INI file. Instead of processing an INI file, however, TRegistryIniFile reads from and writes to the system registry. Because TRegistryIniFile, like TIniFile, descends from TCustomIniFile, you can use it in common code that writes to both INI files and the registry.
In addition, application developers that are switching from the use of INI files to the system registry can use this object to migrate their application with a minimum of coding changes. By finding all references to TIniFile in an application, replacing them with TRegistryIniFile, and recompiling the application, a developer can update an application to use the system registry instead of INI files without having to code any new logic into the application.
Note: Information contained in existing users' INI files is not migrated into the system registry using the method described above. A one-time operation to explicitly copy the INI file data, through TRegistryIniFile, must be used to do this.
TRegistryIniFile adapts the methods inherited from TCustomIniFile to operate on Registry entries rather than INI file keys. It reinterprets the FileName property as a subkey under the system registry's root key (HKEY_CURRENT_USER by default). What corresponds to a section in an INI file is treated as a key in the system registry, and what corresponds to data entries under a section in an INI file are treated as data values under a key in the system registry.
----- rus -------
TRegistryIniFile является оболочкой для системного реестра Windows.

TRegistryIniFile представляет собой простой интерфейс для системного реестра и скрывает нужно знать о базовой структуре реестра. TRegistryIniFile позволяет обработку реестре системы, как если бы это были INI Windows 3.x файл. Вместо обработки ini-файле, однако, TRegistryIniFile чтение и запись в системный реестр. Потому что TRegistryIniFile, как TIniFile, спускается с TCustomIniFile, вы можете использовать его в общий код, который пишет как INI-файлов и реестра.

Кроме того, разработчиков приложений, которые переходят от использования INI-файлов системного реестра может использовать этот объект перенести свои приложения с минимумом кодирования изменений. Находя все ссылки на TIniFile в приложениях, заменив их TRegistryIniFile, и перекомпиляции приложения, разработчики могут обновить приложение для использования системного реестра вместо INI файлы без кода любой новой логики в приложение.

Примечание: Информация, содержащаяся в файлах существующих пользователей INI не переносятся в систему реестра с помощью метода, описанного выше.Разовая операция явно скопировать ini-файла данных, через TRegistryIniFile, должны быть использованы, чтобы сделать это.
TRegistryIniFile адаптирует методы, унаследованные от TCustomIniFile работать на записи в реестре, а не ключи INI-файл. Он переосмысливает FileName собственности как подраздел в корневой ключ системного реестра (в HKEY_CURRENT_USER по умолчанию). Что соответствует раздел в INI-файл рассматривается как ключ в системном реестре, и то, что соответствует записи данных в разделе INI-файл, рассматриваются как значения данных под ключ в системном реестре.[/more]


Согласно мануалу один из них применяется в Windows 95/NT, другой - в старших OC

eddoc, понятно. Значит используем только TRegistryIniFile.

jFobos
Нужно отключать скинирование. Но сделать это можно только для всего класса, а не для отдельного объекта. Примерчик: http://theroadtodelphi.wordpress.com/2012/02/06/changing-the-color-of-edit-controls-with-vcl-styles-enabled/ и в нагрузку: http://code.google.com/p/vcl-styles-utils/

на db-контролах висят обработчики OnChange и тд. при открытия дата-сета, они все начинают срабатывать. что не нужно. пока обхожусь флагами, а как правильно?

neznayka3

Цитата:

на db-контролах висят обработчики OnChange и тд. при открытия дата-сета, они все начинают срабатывать. что не нужно. пока обхожусь флагами, а как правильно?

Не знаю как правильно,потому что не понимаю, почему они не должны срабатывать при открытии датасета. Вообще говоря, сама ситуация из разряда - "тут играть, тут не играть, тут рыбу заворачивали".
Но если на то есть причины - вешайте обработчики в рантайме в тот момент, когда они становятся нужны.

XPerformer

Цитата:

Не знаю как правильно,потому что не понимаю, почему они не должны срабатывать при открытии датасета.

например пи смене страны(вручную), должны подгружаться города. при открытии/закрытии датасета подгрузка данных не нужна.

neznayka3
я уже ответил:
dataset.open;
dataset.onchange := handler; // включить
....
// отключить
dataset.onchange := nil;
dataset.close;

neznayka3
флаги - вполне годное решение
с OnChange(Scroll,...) всё-таки удобнее работать когда они назначены в IDE
а то можна забыть убрать перед билдом, например

с другой стороны, и конструкции типа

Код:
.........
MyDataSet.OnChange:=nil;
try
//тут переоткрываем, бегаем по данным итд
finally
MyDataSet.OnChange:=MyDataSetChange;
end;

Комрады, подскажите.

Вот [more=в этой функции]
Код: function TForm1.TestConnWithExcept(Sender: TpFIBDatabase; out ErrMsg: string; const LogExcept: Boolean = True): boolean;
//возвращаем True, если соединение потенциально возможно, ErrMsg - текст ошибки соединения, если LogExcept = True
begin
Result:= True;

try
TpFIBDatabase(Sender).Connected := True;
except
on E:Exception {EFIBInterBaseError} do
begin
Result:= False;

if LogExcept
then
ErrMsg:= E.Message;

// raise EAbort.Create('');//давим текст ошибки
end;
end;

TpFIBDatabase(Sender).Connected:= False;
end;

eddoc
совершенно верно, по EAbort происходит вылет из функции, и из вызвавшей её итд
это ж исключение, хоть и специфическое
а отлавливать например так

Код:
1) передать текст ошибки в исключение
raise EAbort.Create(ErrMsg);

2) отловить это исключение в вызвавшем методе
try
TestConnWithExcept(.....)
except
on e:EAbort do
.... смотрим e.Message....
on e:exception do
... а здесь,например, raise ....
end

3) можно написать SafeTestConnWithExcept который будет всё это отлавливать и анализировать (чтобы не повторять подобный код всюду)

ant0ni02004

Цитата:

1) передать текст ошибки в исключение

не взлетело

Цитата:

2) отловить это исключение в вызвавшем методе

муторно, придется в метод вкладывать еще процедуру

Переписал функцию [more=с передачей указателя]
Код: function TForm1.TestConnWithExcept(Sender: TpFIBDatabase; PCustomEditObj: Pointer; const LogExcept: Boolean): boolean;
begin
Result:= True;
try
TpFIBDatabase(Sender).Connected := True;
except
on E:Exception {EFIBInterBaseError} do
begin
Result:= False;

if LogExcept
then
TCustomEdit(PCustomEditObj^).Text:= E.Message;
TpFIBDatabase(Sender).Connected:= False;

raise EAbort.Create('');//давим текст ошибки
end;
end;

TpFIBDatabase(Sender).Connected:= False;
end;

eddoc

Цитата:

не взлетело

сорри, копипаст проклятый попутал...
я имел в виду вот что:

Код:
on E:exception do
begin
......
raise EAbort.Create(e.Message);
end;

ant0ni02004

Цитата:

exit(а не raise) - и дальше анализируем

Нет, ну надо же. Как все просто. Мне и в голову не приходило, что эта конструкция работает даже в эксцепшенах

Респект

Всем привет. У меня неожиданный вопрос возник. Летом перед отпуском был абсолютно рабочий проект под Delphi 2010. По приезде, спустя некоторое время вернулся к работе над проектом. И в первый же запуск получаю вылет приложения на саммой ранней стадии с ошибкой Privileged instruction. Проект компилируется-билдится без проблем, по сути никаких изменений не было, но исполняемый файл теперь нерабочий. Даже не знаю куда теперь копать и что править в консерватории. В системе кардинально ничего не менялось, системные обновления (WinXP SP3 x86) устанавливались по мере выхода, никаких новых устройств и драйверов.
В общем, любые советы категорически приветствуются, голова дымится уже.

golkanavt
сделайте полный build проэкта

ant0ni02004
Уже, не помогает. Более того, достал из бэкапа исходники предыдущего билда, компиляю, запускаю - те же грабли. В обоих случаях EurekaLog выдает сходную информацию по ошибке:


Код:
; dxDockControl.dxDockingPaintersManager
; ---------------------------------------
012C3FF8 in eax, $6B ; <-- EXCEPTION
012C3FFA pop dword ptr [esi+$03]
012C3FFD dec esi
012C3FFE imul ebp, [ecx+$B914EDD3], $A7
012C4005 xor esp, [ebx-$43]
012C4008 and [edi+$98F1D762], bh
012C400E repne
012C400F push $70542F90 ; ''...
012C4014 xor [esi], cl
012C4016 sub al, $CC
012C4018 scasd

Используются ли dll? Что использует проект помимо девок? Почитай тут ещё - http://www.devexpress.com/Support/Center/Question/Details/B203103

Цитата:

Используются ли dll? Что использует проект помимо девок?

В явном виде нет, а так куча всего - чуть не весь спектр DevEx, FastReport, FIBPlus, TMS и всякой мелочи. Проект рабочий, поднял еще несколько ревизий из Git'а - со всеми та же беда, походу дело в IDE. С момента возвращения, что вспомнил из изменений - обновлял DotNetFramework, MS Office 2003 -> MS Office 2007, да видеодрайвера.

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

В любом случае, спасибо за участие. Попробую собрать с нуля тестовый проект, да накидать в него сложных форм из проблемного - совсем простое приложение без логики с гридами и контролами без наполнения данными компилируется и запускается нормально.

По ссылке, что Вам, golkanavt, раньше указали сказано, что из-за разных версий кода (в DLL и в проекте) такое может происходить. Намекают, что полный ребилд проекта может помочь (это когда исходники компонентов тоже перекомпилируются заново)

Примечание:
Дизассемблированный листинг от EurekaLog указывает, что исключение (<-- EXCEPTION) происходит на инструкции чтения из порта ввода/вывода (in eax, $6B; чтение из порта с номером 107).

А эта инструкция привилигированная. Должна инструкция выполняться на уровне ядра ОС (ring 0/kernelspace code), а не из кода пользовательского режима доступа (ring 3/userspace code).

ant0ni02004
создайте в проекте папку, например dcu и настройте (Project-Options-Compiler) билдить туда (unit output directory) тогда оно и все системные заодно перебилдит

если это уже сделано - тогда нужно искать кто портит, м.б. и девки
я и сам не раз сталкивался, что работающий проэкт вдруг начинал "чудить" и исключения выбрасывать прямо со старта (никаких обновлений компонент не происходило). полный перебилд помогал.

заодно проверьте, не слетели ли настройки компиляции (complee boolean eval, @ operator итд)

Спасибо всем откликнувшимся. Походу дела проблема была в другом - после проверки диска и переустановки DevEx все заработало как положено.

Как можно выполнять поиск и сортировку тегов в xml используя сабжевый (msxml) парсер IXMLDocument?

Код: var
XMLDocument: TXMLDocument;
Node: IXMLNode;
begin
XMLDocument.Active := True;
XMLDocument.SetNodeIndentStr(#9);
XMLDocument.Options := XMLDocument.Options + [doNodeAutoIndent];
XMLDocument.DocumentElement := XMLDocument.CreateNode('Root', ntElement, '');
Node := XMLDocument.DocumentElement.AddChild('Node');
Node.AddChild('Child');
end;

AlexCoRu
а вот как бы не оказалось что это всё согласно стандарту происходит
я и сам когда-то удивлялся Text-нодам...