In my Delphi 10.4 FMX program, I am asking the user for a new file name using the code below
procedure TForm6.btnBlockingClick(Sender: TObject);
begin
//In Win10, this blocks form access when ShowMessage is called
NameCallBack(mrOk, ['name']);
end;
procedure TForm6.btnNonBlockingClick(Sender: TObject);
begin
//In Win10, this does not block form access when ShowMessage is called in the NameCallBack routine.
TDialogService.InputQuery('Enter name', ['Name'], [''], NameCallBack);
end;
procedure TForm6.NameCallBack(const AResult: TModalResult; const AValues: array of string);
begin
if aResult = mrOK then
TDialogService.ShowMessage('Ok pressed')
else
TDialogService.ShowMessage('Cancel pressed');
end;
Any idea why ShowMessage is not blocking when NameCallBack is used as the Callback event for InputQuery? In Win10, what is the best way to show a message to a user in this type of callback routine that keeps the user from accessing the underlying form until the dialog is closed in some way.
FYI: the same thing happens if you use MessageDialog, to allow user interaction, instead of ShowMessage in the callback routine.
Note: this logic works in OSX and IOS, with both dialogs blocking. On Android, neither dialog is blocking but is not a problem, as touching anywhere but the dialogs closes the dialog and requires a second touch to interact with the underlying form again. On Win10, I can doing anything I want with the underlying form while the ShowMessage dialog is visible when used in a callback event.
Thanks for any help with this.
This may not be the best way to work around the bug I found, but here is what I did in case someone else has this problem.
I added a timer to my form, set the interval to 200 and disabled it.
For any TDialogServices.MessageDialog and TDialogServices.InputQuery callback routine where the callback routine also called MessageDialog or ShowMessage, I moved the callback logic into new routines. I then changed the callback routines to set a form variable to indicate which callback routine was called, saved off the relevant info from the callback routine as needed, then enabled the timer.
In the timer event, I first disable the timer then call the new routines based on the form variable.
This now allows both the original dialog and the dialog needed in the callback routine to be blocking on Win10. In addition, Android, OSX and IOS appear to still work correctly as explained in my question.
Related
so there have been a hundred questions whether to Release vs Free forms in Delphi.
I have encountered an interesting issue that I couldn't explain, below is the (over-simplified) pseudo-code:
procedure SomeProc;
var vForm: TForm;
begin
vForm := create;
try
vForm.ShowModal;
finally
vForm.Release;
// more stuff
Application.MessageBox ('some message');
end;
end;
expected behavior:
upon closing my modal form, the messagebox would show up.
actual behavior:
Messagebox doesn't show, and execution proceeds as if user pressed 'No' ('No' is the default in the actual code)
tracing it:
ShowModal ends, no problems here
release is called, CM_RELEASE is posted in the event queue
MessageBox executes // begin internals of MessageBox code, VCL.Forms unit
TaskActiveWindow := ActiveWindow; // a handle to the active window is saved. who is the active window?
MessageBox invokes Application.ProcessMessages
our modal form destructor is finally invoked.
external call to Windows, with the saved handle TaskActiveWindow
If the call to Release is replaced by Free, the issue never occurs. Since the form is a Modal (internally, busy looping processing messages), there is no harm in calling Free, so that solves the immediate problem.
However it does not explain what is actually going on under the hood.
I can assume, but cannot prove, that the active window was still the modal form upon saving the handle. And since the handle's underlying form is then freed, this is why the MessageBox is not showing?
Would love some opinions / insights on the above.
PS: copy-pasting this may not reproduce the issue at your end, but what is definitely true is, no issues are faced when calling Free instead of Release.
I'm looking for a solution, where my app would follow another external app with it's WindowState.
The basic idea is, that I'd have actions made on next changes:
When external app is normalized: Move my form to specific coordinates
When external app is maximized: Move my form to specific coordinates
when external app is minimized: Minimize my form to taskbar.
So said, I want my app to look and behave like it was an actual part of certain external app.
So far here's what I have:
I get the external window handle ok. Using the next function case I get the results as follows:
case WindowPlacement.showCmd of
SW_HIDE: Result := 0; // hidden
SW_SHOWNORMAL: Result := 1; // show normal
SW_SHOWMINIMIZED: Result := 2; // minimized
SW_SHOWMAXIMIZED: Result := 3; // maximized
end;
This works fine. However, at the moment, I'm using timer event to trigger every 100mS, which gets this function result and then takes actions as follows:
procedure TPre2.Timer1Timer(Sender: TObject);
var t: integer;
begin
t:= CheckWindowState(AvoHandle);
case t of
0: Application.Minimize;
1: Application.MainForm.WindowState:=wsNormal; // add position later
2: Application.Minimize;
3: Application.MainForm.WindowState:=wsNormal; // add position later
end;
which gets things randomly working or not. A few times it minimizes and restores just as it should, then the next moment after the external app minimization my app stays visible instead of hiding. Timer is still looping though.
Clicking on the app icon in the taskbar causes it to minimize instantly.
Is there a better approach to what I'm trying to achieve? Or, is there any plausible reason that could cause this not working always?
thx.
This kind of task can be done using a CBT Hook. To implement this type of hook follow these steps.
Use the SetWindowsHookEx function to install a global CBT hook. (In order to install a global hook you should call this method and the callback procedure from a dll, check the MSDN Documentation for details)
In the CBTProc callback function check for the HCBT_MINMAX code.
The LParam of the CBTProc callback function will contain a show-window value (SW_HIDE, SW_MAXIMIZE, SW_MINIMIZE and so on)
From you application use the LoadLibrary method to load the dll with the global hook implementation (you can export a method from the dll to enable or disable the hook).
To communicate your App with the dll you can use a shared memory block (CreateFileMapping, MapViewOfFile) and a custom message (RegisterWindowMessage).
At program start, in the OnActivate event handler, I need to do something which blocks the program for a few seconds. During this time the form's client area is still not completely painted, which looks ugly for the user. (During this blocked time I don't need the program to respond to clicks or other user actions, so there is no need to put the blocking operation into a thread - I just need the form to be completely painted). So I use TForm.Update and Application-ProcessMessages to update the form before the blocking operation which works very well:
procedure TForm1.FormActivate(Sender: TObject);
begin
Form1.Update;
Application.ProcessMessages;
Sleep(7000);
end;
However, I wonder whether there is not another more elegant solution for this problem. This could be for example a OnShown event implemented in a descendant of TForm which will be fired AFTER the form has been completely painted. How could such an event be implemented?
Your real problem is that you are blocking the UI thread. Simply put, you must never do that. Move the long running task onto a different thread and thus allow the UI to remain responsive.
If you are looking for event which is fired when application finishes loading/repainting you should use TApplication.OnIdle event
http://docwiki.embarcadero.com/Libraries/XE3/en/Vcl.Forms.TApplication.OnIdle
This event is fired once application is read to recieve users input. NOTE this event will be fired every time application becomes idle so you need to implement some controll variable which will tel you when OnIdle even was fired for the first time.
But as David already pointed out it is not good to block your UI (main thread). Why? When you block your main thread the application can't normally process its messages. This could lead to OS recognizing your application as being "Hanged". And aou definitly wanna avoid this becouse it could cause the users to go and forcefully kill your application whihc would probably lead to data loss. Also if you ever wanna design your application for any other platforms than Windows your application might fail the certification proces becouse of that.
In the past a simple PostMessage did the trick.
Essentially you fire it during DoShow of the base form:
procedure TBaseForm.DoShow;
begin
inherited;
PostMessage(Handle, APP_AFTERSHOW, 0, 0);
end;
then catch the msg and create an AfterShow event for all forms inherited from this base form.
But that no longer works, well not if you are skinning and have a good number of VCL controls.
My next trick was to spawn a simple thread in DoShow and check for IsWindowVisible(Handle) and IsWindowEnabled(Handle). That really sped things up it cut 250ms from load time since db opening and other stuff was already in the AfterShow event.
Then finally I thought of madHooks, easy enough to hook the API ShowWindow for my application and fire APP_AFTERSHOW from that.
function ShowWindowCB(hWnd: HWND; nCmdShow: Integer): BOOL; stdcall;
begin
Result := ShowWindowNext(hWnd, nCmdShow);
PostMessage(hWnd, APP_AFTERSHOW, 0, 0);
end;
procedure TBaseForm.Loaded;
begin
inherited;
if not Assigned(Application.MainForm) then // Must be Mainform it gets assigned after creation completes
HookAPI(user32, 'ShowWindow', #ShowWindowCB, #ShowWindowNext);
end;
To get the whole thing to completely paint before AfterShow it still needed a ProcessPaintMessages call
procedure TBaseForm.APPAFTERSHOW(var AMessage: TMessage);
begin
ProcessPaintMessages;
AfterShow;
end;
procedure ProcessPaintMessages; // << not tested, pulled out of code
var
msg: TMsg;
begin
while PeekMessage(msg, 0, WM_PAINT, WM_PAINT, PM_REMOVE) do
DispatchMessage(msg);
end;
My final test was to add a Sleep to the AfterShow event and see the Form fully painted with empty db containers since the AfterShow events had not yet completed.
procedure TMainForm.AfterShow;
begin
inherited;
Sleep(8*1000);
......
I have this awkward situation that causes an exception. I've found the problem but the solution is so far tricky to implement for me.
In our application, if a user stays in-active for a certain period of time, the security time-out procedure kicks in to prompt the user the password entry box.
However, whenever a form has a message box displayed during the FormShow() event for any particular reason (thing to pay attention here; the formShow event execution hasn't been fully completed yet) and the user decided to not click the OK button of the dialog box for a certain time, the security code kicks in and tries to hide all forms so that it can prompt a password.
This scenario will trigger the exception "Cannot change Visible in OnShow or OnHide".
Security code loops all forms using TScreen.FormCount and hides them using TForm(TScreen.Forms[ii]).Hide individually. Hide procedure will cause the exception, because I think this form has not completed it's loading procedure fully yet.
I've done tests, and if I display a message box after the FormShow() event is executed, the security code works perfectly fine and hides all windows without any issues.
I've tried several properties and window message checking to do an "if check" before hiding forms, like Screen.Forms[ii].Visible, Screen.Forms[ii].Active but no luck so far. The mentioned form will be visible and there's no guarantee that it will be active, and if it's active how am I going to hide other non active forms. So my question is, which property or Windows message would indicate that a form is fully loaded, or at least it has past the FormShow event of any given form that exists in TScreen.Forms?
I need an answer to what I am asking please, I need a generalized solution that needs to be implemented in the security code, I can't go through over a thousand forms we have in this giant application and individually try to find solutions to any validation/warning logic exist in those forms.
Thank you
The simple answer is to stop showing the modal dialog in the OnShow of the owner form. Wait until the form has finished showing before you display the modal dialog. If you make that change, and that change alone, your existing code will start to work.
The question title you chose was:
Can't hide a window that's not been fully initialized
And so the obvious solution is to wait until the window has been fully initialized.
The simplest way to achieve this is to move your code that currently runs in OnShow into a handler for CM_SHOWINGCHANGED:
procedure CMShowingChanged(var Message: TMessage); message CM_SHOWINGCHANGED;
Implement it like this:
procedure TMyForm.CMShowingChanged(var Message: TMessage);
begin
inherited; // this is what invokes OnShow
if Visible then
begin
// do what you previously did in OnShow
end;
end;
David Heffernan's solution gave me an idea and I solved this issue on my end.
I created following;
const
WM_SHOW_MESSAGE = WM_USER + 1;
private
procedure WMShowMessage(var Msg: TMessage); message WM_SHOW_MESSAGE;
Inside constructor;
PostMessage(Handle, WM_SHOW_MESSAGE, 0, 0);
And this will have the message box logic:
procedure MyMethod.WMShowMessage(var msg: TMessage); message WM_SHOW_MESSAGE;
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Splash Screen Programatically
Show a splash screen while a database connection (that might take a long time) runs
Which is the best place to initialize code such as loading INI file? I want first to show the form on screen so the user know that the app is loading and ONLY after that I want to call lengthy functions such as LoadIniFile or IsConnectedToInternet (the last one is REALLY slow).
The OnCreate is not good because the form is not yet ready and it will not show up on screen.
I do this I DPR but not working always:
program Test;
begin
Application.Initialize;
Application.Title := 'Test app';
Application.CreateForm(TfrmTest, frmTest);
frmTest.Show; <---------------------- won't show
LateInitialize;
Application.Run;
end.
The form will not show until LateInitialize (4-5 seconds) is executed.
procedure LateInitialize;
begin
CursorBussy;
TRY
// all this won't work also. the form won't show
frmTest.Visible:= TRUE;
Application.ProcessMessages;
frmTest.Show;
Application.ProcessMessages;
frmTest.BringToFront;
frmTest.Update;
Application.ProcessMessages;
DoSomethingLengthy; {4-5 seconds}
FINALLY
CursorNotBussy;
END;
end; <--------- Now the form shows.
And yes, frmTest it is my only form (the main form).
After calling frmTest.Show, you can call frmTest.Update to let it render onscreen, before then calling LateInitialize. But until Application.Run is called, the main message loop will not be running, so the form will not be able to do anything else until then.
Another option is to use the form's OnShow event to post a custom window message back to the form via PostMessage(), then have the form call LateInitialize when it receives that message at a later time. That will allow the form to process painting messages normally until LateInitialize is called.
Anything that blocks the main thread for more than a few milliseconds/seconds really should be moved into a separate worker thread instead (especially things like IsConnectedToInternet). The main thread should be used for running the UI.
An easy way to do this, is to send a message to yourself.
I do this all the time
const
MSG_AFTERCREATE = WM_APP + 4711;
...
procedure OnCreate(Sender: TObject);
procedure AfterCreate(var message: TMessage); message MSG_AFTERCREATE;
...
Implementation
procedure OnCreate(Sender: TObject);
begin
PostMessage(Self.Handle, MSG_AFTERCREATE, 0, 0);
end;
procedure AfterCreate(var message: TMessage);
begin
//Do initializing here... the form is done creating, and are actually visible now...
end;
Variant 1: Use TTimer with a 1 second delay, run it from main form's OnShow
In TTimer do the initialisation
This will give time for most components to initialize and draw themselves
Variant 1.1: use message method in function and call Win API PostMessage (but not SendMessage aka Perform) from OnShow. This is seemilar but more cheap and fast. However that message "do init now" sometimes may be received before some complex component on the form would fully draw itself.
Variant 2: use threads (OmniThreadsLib or even plain TThread)
Launch it from MainForm OnCreate and let it prepare all data in background, then enable all needed buttons, menus, etc
That is truly the best way if you have long and blocking functions, liek you described IsConnectedToInternet.
Variant 3: use SplashScreen before showing main form.
That is good because users see that application not read yet.
That is bad for that very reason - people start feeling your program is slow. Google Chrome was told to draw their main form as picture in 1st moments just to make look "we are already started" even the actual control would be ready a bit later.
A long time ago in another forum far far away, someone posted the following to document the life cycle of a form. I have found it useful, so am sharing it here.
Create OnCreate
Show OnShow
Paint OnPaint
Activate OnActivate
ReSize OnResize
Paint OnPaint
Close query OnCloseQuery
Close OnClose
Deactivate OnDeactivate
Hide OnHide
Destroy OnDestroy
Try the OnActivate event.