I'd like to get the window handle of a new vista-style Open/SaveDialog opened by my Delphi application.
It was possible with the old style dialog by parsing OnShow, but with the new style dialog there is no such event.
Is there a possibility maybe to iterate through all window handles in Windows and get it that way?
Thanks!
Edit: I know that OpenDialog.Handle will return the handle, but only when the dialog is visible (otherwise it's 0). I'd need an event to catch the Handle straight after showing the dialog (without any user action, ie.: select an item in the dialog, changing the file type, etc.).
I'd like to get the window handle of a new vista-style Open/SaveDialog opened by my Delphi application.
This is available through the dialog's Handle property.
Probably the easiest way to catch the event of the dialog showing is to use a CBT hook that you set immediately before showing the dialog, and remove as soon as it closes.
TOpenDialog has an OnShow event which fires just after dialog is shown so you can use to get the OpenDialog.Handle since the handle is already set at that time.
EDIT: After some pepole pointed out that using of OnShow event changes the dialogs apperance I tested this out and can confirm that using of OnShow event realy does change the dialogs aperance.
Related
I have a TTaskDialog that has an OnButtonClicked event handler, in which a lengthy process (several seconds) is performed. This works fine, but I'd like some indication to the user that things are happening while that lengthy process is chugging along. I would like to have a marquee progress bar on the dialog that is initially hidden, appears when the CommandLink is clicked, and runs while the lengthy process is performed - I'd settle for a progress bar that is visible but not enabled when the dialog is displayed and is "turned on" in the OnButtonClicked event. Just including the tfShowMarqueeProgressBar flag causes the bar to appear and be scrolling when the dialog first displays, and the ProgressBar property of the dialog doesn't have Enabled or Visible type properties to control this behavior.
There are TaskDialogs in Windows itself that do what I want, so I know it's theoretically possible, though I realize that the structure of the VCL wrapper around the native control may make it difficult or impossible using the VCL object.
Is what I want possible using the TTaskDialog VCL object?
The Windows API provides the message TDM_NAVIGATE_PAGE to change the TaskDialog at runtime. You would have to pass a TASKDIALOGCONFIG structure along with this message that defines the dialog's properties. In its dwFlags field you could specify the TDF_SHOW_PROGRESS_BAR flag to show the progress bar. But this requires a lot of work as the other fields in the TASKDIALOGCONFIG structure must match the properties that you have set for Delphi's TTaskDialog component.
Delphi creates a TASKDIALOGCONFIG structure as a local variable in the function TCustomTaskDialog.DoExecute in Dialogs.pas that is used to display the TaskDialog.
How do I create this custom print dialog and get the values of the red options when the user clicks ok?
The print dialog below is not created manually, the app I took this screenshot from is probably modifying the default print dialog.
The items circled in red is associated with some data found in the app I took the screenshot from.
The class name of this dialog is #32770 (Dialog) which is the same print dialog found in notepad, wordpad, and vb6 common dialog print. So it is clear that it is modifying the dialog, adding controls to it somehow
You could look at Customizing Common Dialog Boxes but don't expect this to be simple from VB6. it is clumsy enough in C++.
You could just create your own dialog Form.
Update:
Perhaps consider using the download in HOW TO: Raise and Control Print Dialog Boxes from Visual Basic?
When I'm calling an OpenDialog from my form on ButtonClick event. The dialog does not shows as modal and is also displays in taskbar (in WindowsXP). I can return to main form and click Open again and again - popping up several dialogs at once..
How do I make an OpenDialog to be modal in Firemonkey?
Is it specifically made so that no modal dialogs are allowed due to multi-platform anture of FM?
EDIT: The bug is fixed in Update 3.
I think it's a bug. There are a lot of modal type bugs with FireMonkey, and hopefully they will be fixing them soon. Currently, even modal forms aren't modal.
For your problem, I have a workaround for Windows, but you might not like it.
You need to fix the following line in the TPlatformWin.DialogOpenFiles() method in FMX.Platform.Win.
Under with OpenFile do change:
hwndOwner := 0;
To this:
hWndOwner := FmxHandleToHWND(Application.MainForm.Handle);
The function utilizes the Windows GetOpenFileName API call, even though it's deprecated on Vista and above. If a owner handle is passed in, the dialog is modal, otherwise it's not.
You might want to submit this as a bug to qc.embarcadero.com along with the workaround.
I have a wpf project which uses transparent windows and I share this transparent window styling for my dialog windows and my mainwindow.
I am getting an error on my DragMove() event of my MainWindow AFTER I close a dialog window that uses the same window style. To make this even more strange this exception only occurs when I handle a mouseleftbutton event on a label in my Status Bar on the MainWindow. IF I swap out the label for a button and replace the mouseleftbuttondown with a click event I do not get the error.
The strange thing is that the dialog window that pops up does not implement dragmove, and I'm not dragging around my mainwindow either. Somehow dragmove gets called after my code execution returns to the mainwindow after a showdialog() call.
An easy fix for me currently is to swap my label for a button and wire up the click event instead.
However, I'm more interested in hearing about what causes this issue and why a click event works but the mouse one fails miserably.
My "StatusBar" is simply a stackpanel with labels and other stackpanels (which contain more labels).
Has anyone else fought this issue before? Would I need to implement some sort of mouseclick event handler override so that I can capture and cancel this exception from happening?
Repro code can be provided if needed. I got enough hits on dragmove here so I am hoping this is an easy one for somebody out there.
Thanks in advance for any help!
my brain isn't working properly today. I forgot about routing of events in this scenario. I simply needed to set the Handled property on my routedevent that fired off when the mousebutton was down. Somehow I missed that in the debugger before posting the thread.
The 'correct' way to make a borderless window movable --> https://stackoverflow.com/a/3275712/146032
Be sure to only call DragMove when triggered by event MouseLeftButtonDown and don't forget to handle the event using e.Handled=true;
if you receive this exception when messagebox show complete. place Dragemove();
inside try and empty in catch.
If I create a new Delphi form, hook its OnResize event, and run the app, OnResize is fired before the window is shown. What I don't know is whether this will always happen, for any window.
(For anyone familiar with the Windows API, I've traced it to the ShowWindow call in TCustomForm.ShowingChanged (Forms.pas line 5503 in Delphi 2007), which apparently triggers a WM_SIZE... at least, for a new window with no other properties set. I haven't seen it documented that ShowWindow always fires WM_SIZE, so I don't know whether I can count on this or not.)
So: Can I rely on a TForm always firing OnResize when it's first shown? Or are there circumstances (maybe if the window is non-resizable, maybe if the Position property has certain values, etc.) where OnResize might not fire before the window is first shown?
No, this event doesn't always fire when the form shows, depending on things like BorderStyle. For example, it fires on startup for bsSingle, but not for bsDialog.
It's easy to test. Just add some logging code to the main form's OnResize event, change the BorderStyle and run your app.