SiComponents Forums

TsiLang ver 6.2.2 have Vista dialogs support, however, it's kinda strange. If I'm correct. when common dialog is opened on Vista, TsiLang:
1. Creates one-shot timer object,
2. Tunes up dialog Window procedure to fire timer on each WM_WINDOWPOSCHANGED event
3. In the timer procedure enumerates all child windows on the dialog, recursively calling GetWindowText followed by GetTextFrom, then SetWindowText for each control with non-empty Window string found.

The results are, keeping in mind that we have DoRaiseExceptions property set (at least for debug code), quite far from grace. Namely, each opening, moving, changing focus from\to common dialog under Vista produces many side effects, like
1 Dialog controls get enumerated and localized until the first exception is thrown from GetTextFrom, which is occured quite soon during enumeration, actually.
2 siLang Exceptions are generated with 100% probability for different hidden\visible helper common dialog windows which happen to have their titles not empty, for instance, CommonPlacesWrapperWnd, Search bar, something wierd like WorkerW, Tree View, NamespaceTreeControl, misc. edit boxes, containing paths, file names, etc., which normally should never be localized at all.
3 Enumeration process, and, hence, exception throwing, gets repeated each time WM_WINDOWPOSCHANGED event occured.
4 No neet to tell that each time localization is re-started, it throws exceptions on each control which has already been localized.

Yes, you're absolutely right. It is performed exactly in the way you described, otherwise it is not possible to translate Vista's dialog in VCL. The ony bug is that "localization" is called every time window position changed and we will fix this in next update.

Ok, Igor, I understand that if re-translation is turned off, Vista dialogs may restore some control's captions to untranslated state, after, for instance, save dialog roll-up\roll-down, so here it may be the only way. But I would suggest though, that for some child controls, translation should not be called at all, at least some window classes may be filtered out in siDialogEnumChildProc, comparing value returned from GetClassNameW with, for instance, "CommonPLacesWrapperWndClass", "Edit", "WorkerW", "ComboBox"...