Delphi7 (cannot use latest). I want to replace (easy way, not making my form) MessageDlg calls with Vista style dialogs (must still work on old OS!). I need buttons Yes/No/YesToAll/NoToAll in this.
How to do it?
MessageBox isn't a way: I need all 4 buttons Yes/No/YesToAll/NoToAll in one form, or maybe checkbox instead of ToAll btns.
On Vista you use the native task dialog, TaskDialogIndirect. This has all the functionality you need. You'll need to translate the headers to Pascal, but if you don't fancy doing that yourself then you can use the JEDI header translations, for instance.
On XP and older there is no task dialog. There is no native system dialog with the functionality that you desire. Therefore you need to implement the dialog yourself. Create a Delphi TForm descendent. Add the necessary text, buttons, styling etc. Show it with ShowModal.
One of the issues with all this is that TaskDialogIndirect must be bound at runtime with GetProcAddress. In fact, use GetProcAddress to determine whether TaskDialogIndirect is available, and if not fall back to the XP code path.
If you don't want to build this yourself you can use one of the many extant libraries that offer such functionality. For instance: http://blog.synopse.info/post/2011/03/05/Open-Source-SynTaskDialog-unit-for-XP,Vista,Seven
Related
I'm injecting a number of forms into an existing application using a dll.
I don't control the existing application, nor do I have source code for it.
(I doubt the source code exists any more).
I want to show a TextHint in a TEdit.
In the form designer this works, but in the application it doesn't.
I traced it to the fact that StyleServices (This used to be called ThemeServices (now deprecated)) is not enabled, disabling the TextHint.
Obviously I cannot enable styles for the application, all I have is a dll.
Is there a way to show the texthint?
I prefer to use a stock TEdit.
The dll is written in DX and the old application is written in D7.
BTW I don't care a hood about any additional styling/theming or the like. I just want the texthint to display.
Is there a way to show the texthint?
Standard TextHint functionality in a stock TEdit is dependent on the EM_SETCUEBANNER message, which only works when Visual Styles are enabled:
Note To use this API, you must provide a manifest specifying Comclt32.dll version 6.0. For more information on manifests, see Enabling Visual Styles.
If Visual Styles are not enabled in the app you are injecting your code into, then the only way to do what you are asking for is to subclass the TEdit window and custom-draw it manually when its text is empty.
I want to interoperate with third-party application and to provide a dialog box to it. API wants standard DialogProc and DLGTEMPLATE pointers. However, i'd really like to take advantages of VCL, form designer and such. How can i do this? Which code samples i can study?
Technical:
How can i do:
embed VCL form (or frame) into dialog box created from some boilerplate DLGTEMPLATE i supplied.
connect VCL WndProc to windows DialogProc.
Delphi VCL does not interoperate with standard windows Dialogs designed with dialog resource types. Visual studio supports creating dialog resources, still, even in VS 2010, but Delphi never has. Whatever it is that you've got an API for, please mention exactly what it is, and this will (if it isn't some obscure or in-house thing) increase the odds that someone can help you. Since the API expects a dialog handle, and expects to show that dialog and then run your dialog procedure, and send you stuff, you have two choices:
Don't use delphi at all. Use visual studio 6, because that's about the era that this API must have been designed for.
Use delphi, but use a third party dialog designer from Visual Studio 6 or Borland C++ 4.5, or so, we're talking about 1996 era here, and then write your DialogProc without benefit of any VCL controls or vcl code whatsoever.
I have never ever heard of anybody daft enough to rely on windows dialog resources to build their plugin-screens-in-a-dll-via-an-API. I'd really like to know what app it is you're trying to extend.
You might be able to add a modal dialog box that you show modally, from your code, and such a modally shown sub-dialog (a second level dialog) could use the VCL, but the top level dialog is not even under your control.
The problem: I need to obtain the selected text from a window in a Windows application (not my program). I am doing my work in Delphi XE and the software I am attempting to access is a kluge built over the past 15 years with C, C++, VB and who knows what else. I do not have the source code. The edit box (an RTF memo) I am attempting to read is of the class "Ter32Class". When I use wm_copy, nothing goes to the clipboard. when I use wm_gettext, nothing. When I use wm_keydown commands (to simulate Ctrl-Ins or Ctrl-C) nothing happens. Note that I can get all of these alternatives to work in wordpad, notepad, and FireFox but not this application (or OpenOffice, incidentally, but that's not the issue). The only way I have been able to programmatically obtain text from this box is to use autohotkey with the simple "send ^c" command. While it works, it is inelegant. HELP?!?
More information: Window hierarchy: Ter32Class is a child of OI_Mdi which is a child of MDIClient, which is a child of OI_Window . I am drilling down to obtain the appropriate handle as it will respond to a paste command.
I am using Delphi XE but I'd love any solution in C++ or VB if no Delphi XE gurus have the answer.
From Quick Macros Forum
One of the windows I need to talk to is of class Ter32Class which
apparently is a TE Edit Control, an editor that doesn't inherit from
the standard RichText Control
and
The published method of talking to this control is via it's DLL
so unless something has changed (post is 2006), it appears you'll need to use it's dll to get the text.
From Sub Systems (TE Edit control website)
Application Interface functions
GetTerBuffer: Retrieve Window Text
HANDLE GetTerBuffer(hWnd, size)
What is the difference between the new TFileOpenDialog and the old TOpenDialog?
In my computer (Win 7/DXE), when I run the code, the dialogs look the same.
TOpenDialog executes TFileOpenDialog when the following conditions are met:
the program is running under Vista (and up)
UseLatestCommonDialogs is true (which is the default)
no OnIncludeItem, OnClose or OnShow events are set
So while still using TOpenDialog on your system you may likely end up automagically executing TFileOpenDialog in most cases, which explains why they are looking the same for you.
Remark: TFileOpenDialog does not fall back on older Windows systems (XP and under) - it just raises an exception. On the opposite, TOpenDialog does some sort of "fall forward".
TOpenDialog wraps the traditional GetOpenFileName. It works on all versions of Windows.
TFileOpenDialog wraps the new COM based dialog that was introduced in Vista. It therefore only works on Vista or later. It has more functionality than the older dialogs, most notably the tight integration with search.
Vista common dialog
Compatibility common dialog
The GetOpenFileName API will in fact produce the new dialogs in most situations, if called correctly, so you can't actually tell the difference. That said, historically the VCL's wrapper for GetOpenFileName was implemented imprecisely and always resulted in the compatibility dialog being shown.
But what does the new COM dialog have to offer then?
The new dialog offers a much easier customisation interface at the loss of some generality. If you use the old dialog template based customisation with GetOpenFileName on Vista or later then the dialogs degrade to ugly compatibility versions that lack functionality.
The other big advantage of the new dialogs is the ability to select unlimited number of files. The old GetOpenFileName interface returned multi-select filenames in a fixed size buffer. This can be a real limitation and in my own code I have had to hack the VCL code to make this buffer larger for when my app runs on XP.
TOpenDialog will delegate the work to TFileOpenDialog if possible. The test it uses requires all of the following to be true:
Running on Windows Vista or later.
Dialogs.UseLatestCommonDialogs global boolean variable is true (default is true). This allows you to disable the use of the new COM dialog should you elect to do so.
No dialog template is specified.
OnIncludeItem, OnClose and OnShow events are all not assigned. Presumably these cannot be fired by TFileOpenDialog.
Summary
If you continue to use TOpenDialog then you will reap the benefit of unlimited number of file in multi-select mode. However, if you wish to customise the dialog, and have the new dialogs rather than the ugly compatibilty dialogs, then you need to do the following:
On XP use TOpenDialog and the dialog template method.
On Vista and later use TFileOpenDialog and implement customisation with IFileDialogCustomize.
I currently use the TOpenTextFileDialog as it has the Encodings option, but under Vista it appears using the older open dialog style. I'd like the new style open dialog, but with an encoding combobox that I can fill with custom strings. Basically I want the exact open dialog that Notepad shows under Vista. Of course I also need the corresponding save dialog as well.
I've done some research and it seems that the OFN_ENABLETEMPLATE flag causes the Vista common dialog to fall back to the old style. Unfortunately that's also the flag that lets the TOpenTextFileDialog modify the window to add the encodings combobox (if I understand things properly.)
Does anyone have a suggestion on how to get what I want under Vista but still have it work under XP? I assume that Windows 7 will have the same issue. I'm using D2009. Thanks for any suggestions or help!
With Vista a new way of dealing with file dialogs has been introduced, for more information google for the IFileDialog interface or have a look at this blog post. As you say yourself, using the OFN_ENABLETEMPLATE flag causes the Vista common dialog to fall back to the old style.
With Delphi 2007 and 2009 you can use the TFileOpenDialog and TFileSaveDialog in the Vista Dialogs components category. To make your application compatible with pre-Vista Windows versions you should keep using the TOpenTextFileDialog for those, and check at runtime whether you are on Vista and can use the new dialogs:
if Win32MajorVersion >= 6 then begin
// use TFileOpenDialog
// ...
end else begin
// use TOpenTextFileDialog
// ...
end;
Now you only need to add the customization to the Vista dialog. The blog post shows how to do this, by adding a handler for OnExecute of the dialog (because at the time when this is called the IFileDialog interface has been set up already), querying the Dialog member of the file dialog for the IFileDialogCustomize interface, and using this to add the additional controls.