This is my first time I using c++ builder 10 vcl form, how can set a window form behavior like On screen keyboard I interesting in this feature:
A dialog can send key input to any foreground window without itself
being activated to function as an on-screen keyboard. Regular windows
get activated and focused when they are clicked or something. To avoid
this, a window needs to be a non-activating window. You can do this by
creating a window with the "WS_EX_NOACTIVATE" extended style, or by
modifying its style using "ModifyStyleEx".
Source:
https://www.codeproject.com/Articles/32563/Virtual-On-Screen-Keyboard-Example
In uMain.cpp I tried to set this code but not work:
#include <fmx.h>
#pragma hdrstop
#include "uMain.h"
// ---------------------------------------------------------------------------
#pragma package(smart_init)
#pragma resource "*.fmx"
TForm2 *Form2;
void __fastcall TForm2::CreateParams (TCreateParams &Params)
{
TForm2::CreateParams(Params); // inherited
Params.ExStyle = Params.ExStyle | WS_EX_NOACTIVATE;
}
Note: In the Gui option column left, I have a option Formstyle I set StayonTop and work, but I have no see nothing relation to my case.
I appreciate any advice.
Related
I upgraded to XE4 recently and am now in the progress of finding the changes and so-called fixes from XE3.
One that surprised me a lot is that the context menu for the button on the taskbar doesn't appear any more.
It is very easy to duplicate: Just create a new Firemonkey project in XE4 and run it on Windows. Right click on the taskbar application button and see if the context menu comes up. I mean the menu with "Close", "Restore", "Minimize", etc.
This is only on Windows XP and Server 2003. On Win7 it works and shows the "Close" menu item.
Also the title of the button is now different. It should be "Form 1" as the caption of the main form, but instead it is Project1 as the executable name.
This is on all Windows versions.
Can someone help me with this one? People still use XP and this behavior is quite unexpected for the user.
Thanks
Some time has passed since I asked the question, but I found a solution in the meantime and will post it in case it is useful for someone else.
The problem with the wrong caption and missing menu comes from the fact that Delphi XE4 changed the window structure of the Firemonkey apps. Before that the window of the main form was placed on the taskbar and had the appropriate caption and context menu. In XE4 the app creates a new window with a class name "TFMAppClass" and uses it as the main application window that is placed in the taskbar. The main form window is a sibling of that one.
This leads to not being able to set the taskbar button caption, not having a context menu, not responding properly to clicks on the button and not being to hide the button when the main form is hidden.
So, what was needed was to hide the app window from the taskbar and show the form window instead. To do it once is not enough though, because the app window's style is reset on each minimize/restore and it reappears on the taskbar.
To hide the app window simply call ShowWindow(AppWindowHandle, SW_HIDE).
To show the main form window on the taskbar we have to set the WS_EX_APPWINDOW extended window style with SetWindowLong() and call ShowWindow each time the app is shown, restored, etc and bring it to the foreground.
This is done by placing a hook to intercept the WM_CREATE, WM_SHOWWINDOW and WM_ACTIVATE messages and apply the styles when those messages are called. To make the usage easier all of the code is placed in a single unit and the hook is set in the initialization part.
There are no functions to call. To use the unit simply place it somewhere in the uses clause.
unit FM3TaskbarFix;
interface
implementation
{$IFDEF MSWINDOWS}
uses
Winapi.Messages, Winapi.Windows, System.Sysutils, Fmx.Forms, Fmx.Platform.Win;
var
GHookHandle: HHOOK; // Handle for the hook we set
GAppWnd : HWND = 0; // Handle of the main application window
function CallWndProc(nCode: Integer; iWParam: WPARAM; iLParam: LPARAM): LRESULT; stdcall;
var
ActiveThreadID, WindowThreadID: DWORD;
ProcMsg: TCWPStruct;
begin
Result := CallNextHookEx(GHookHandle, nCode, iWParam, iLParam);
if (nCode < 0) then
Exit;
ProcMsg := PCWPStruct(iLParam)^;
case ProcMsg.message of
WM_CREATE:
// Save the "main" app window handle for later usage. There is only one window with the TFMAppClass class per app
if (GAppWnd = 0) and (PCREATESTRUCT(ProcMsg.lParam)^.lpszClass = 'TFMAppClass') then
GAppWnd := ProcMsg.hwnd;
WM_ACTIVATE, WM_SHOWWINDOW:
begin
// Hide the app window. This has to be called on each minimize, restore, etc.
if IsWindowVisible(GAppWnd) then
ShowWindow(GAppWnd, SW_HIDE);
// Only handle Show/Activate. wParam of 1 means the app is shown or activated, NOT hidden or deactivated
// Also apply the style settings only to the Application.MainForm
// We don't want to show other forms on the taskbar
if (ProcMsg.wParam = 1) and
(GetWindow(ProcMsg.hwnd, GW_OWNER) = GAppWnd) and Assigned(Application.MainForm) and
(WindowHandleToPlatform(Application.MainForm.Handle).Wnd = ProcMsg.hwnd) then
begin
// Show the main form on the taskbar
SetWindowLong(ProcMsg.hwnd, GWL_EXSTYLE, GetWindowLong(ProcMsg.hwnd, GWL_EXSTYLE) or WS_EX_APPWINDOW);
ShowWindow(ProcMsg.hwnd, SW_SHOW);
ActiveThreadID := GetWindowThreadProcessId(GetForegroundWindow, nil);
WindowThreadID := GetWindowThreadProcessId(ProcMsg.hwnd, nil);
AttachThreadInput(WindowThreadID, ActiveThreadID, True);
try
SetForegroundWindow(ProcMsg.hwnd);
SetActiveWindow(ProcMsg.hwnd);
finally
AttachThreadInput(WindowThreadID, ActiveThreadID, False);
end;
end;
end; { WM_ACTIVATE, WM_SHOWWINDOW }
end; { case }
end;
initialization
GHookHandle := SetWindowsHookEx(WH_CALLWNDPROC, CallWndProc, 0, GetCurrentThreadID);
finalization
UnhookWIndowsHookEx(GHookHandle);
{$ENDIF}
end.
Btw, this code is based on two samples from the net. I don't know who the authors are, but I give them credit for the idea.
There is one issue that remains. When the app is first minimized the button of the app window reappears temporarily, instead of the form button. After the app is restored or minimized again this doesn't happen anymore.
I have a Delphi 2006 app which can pop up a modal dialog in response to an error condition. It seems to get itself into a state where one of these modal dialogs is open, positioned in front of the main form, but neither form is responding to messages. Clicking on either gives a "bonk". The app is running fine, the UI is updating the main form, but you can't do anything. I guess there is most likely another modal dialog under the main form. Whether it is one of mine or one from Windows I have no idea.
Other points:
the app responds to keyboard shortcuts OK. One of these shortuts shuts down the app gracefully and this worked. I have been unable to reproduce the situation since.
the app has a tray icon. This responds to right mouse clicks. If I minimize the app from here the main form minimizes and leaves the modal dialog displayed, still without focus. If I restore the main form, things are as they were, with neither window having focus. Alt-tab has similar results.
platform is Windows 7
I call DisableProcessWindowsGhosting before any forms are created
I open the modal dialogs with
ModalDialog.PopupParent := MainForm ;
ModalDialog.ShowModal ;
I postpone these error dialogs if other modal dialogs are open:
if (Application.ModalLevel = 0) then
{open modal dialog}
My question has two parts:
Is there a way of programmatically finding out what window has focus? I could then take some action for this scenario or a last resort I could them provide a shortcut key to bring it to the front or take some evasive action (depending on the dialog) like set the ModalResult to mrCancel.
How can this situation arise? Normally when I get a modal dialog behind the main form (I can do that by getting the modal dialog to open, minimizing the app from the tray icon, then restoring the app again - the app main form restores in front of the dialog, with the dialog still retaining focus), I can bring it to the front again by clicking on the tray icon, or close it with the Esc key but it didn't work in this case.
**UPDATE**
Misha's fix worked apart from non-delphi dialogs like TSaveDialog. I was able to get them to work as well by adding Application.ModalPopupMode := pmAuto ; just before the call to Execute.
By "got it to work" I mean that the save dialog was in front after the following sequence:
open save dialog
minimize app from tray icon
restore app from tray icon
whereas it was behind the main form without the ModalPopupMode := pmAuto.
So I'm hoping these changes will help the (as yet unreproduced) problem.
If a form that has focus takes too long to respond to messages (Form1), so that Windows thinks Form1 is unresponsive, and Form1 then displays a modal form (Form2), after Form2 is displayed and the application is processing messages again, Form1 will be brought to the front, thereby potentially "covering" Form2.
Putting this in the Application.OnIdle event will do the trick:
if Assigned(Screen.ActiveForm) then
begin
if (fsModal in Screen.ActiveForm.FormState) and
(Application.DialogHandle <= 0)) then
begin
Screen.ActiveForm.BringToFront;
end;
end;
The last active popup window (VCL or not) can be queried with GetLastActivePopup:
function GetTopWindow: HWND;
begin
Result := GetLastActivePopup(Application.Handle);
if (Result = 0) or (Result = Application.Handle) or
not IsWindowVisible(Result) then
Result := Screen.ActiveCustomForm.Handle;
end;
This is somewhat copied from TApplication.BringToFront.
Bringing this window to the front can be done by SetForegroundWindow:
SetForegroundWindow(GetTopWindow);
Note that Application.BringToFront might do the trick altogether, but I once experienced it did not function properly, a situation I have not been able to reproduce since though.
GetForegroundWindow() is the function you are looking for, if you know the title or have the handle of the modal window it's straightforward.
HWND GetForegroundWindow();
Retrieves a handle to the foreground window (the window with which the
user is currently working). The system assigns a slightly higher
priority to the thread that creates the foreground window than it does
to other threads.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms633505%28v=vs.85%29.aspx
I used Misha’s solution and worked a little further (using NGLN’s code), to solve the problems rossmcm has seen (handlings non VCL dialogs).
The following code is running I a timer:
type
TCustomFormAccess = class(TCustomForm);
if Assigned(Screen.ActiveCustomForm) then
begin
if ((fsModal in Screen.ActiveCustomForm.FormState) and
(Application.DialogHandle <= 0)) then
begin
TopWindow := GetLastActivePopup(Application.Handle);
TopWindowForm := nil;
for i := 0 to Screen.CustomFormCount - 1 do
begin
CustomFormAccess := TCustomFormAccess(Screen.CustomForms[i]);
if CustomFormAccess.WindowHandle = TopWindow then TopWindowForm := CustomFormAccess;
end;
if Assigned(TopWindowForm) and (Screen.ActiveCustomForm.Handle <> TopWindow) then
begin
Screen.ActiveCustomForm.BringToFront;
end;
end;
end;
How can I insert the text from an Edit control into any window where the mouse pointer is, without using the clipboard and/or window handle.
I am using Delphi 7.
Call GetCursorPos to find out where the cursor is.
Call WindowFromPoint to find the window under the cursor.
Send an EM_REPLACESEL message to replace the selection in that window. If nothing is selected then the text will be inserted at the caret.
Note: Be prepared for this to fail more commonly than it succeeds. Many applications don't used windowed edit controls. For a more robust solution you should look into UI Automation.
You asked for some code. Here's what it would look like:
var
Pos: TPoint;
Target: HWND;
...
if not GetCursorPos(Pos) then
RaiseLastOSError;
Target := WindowFromPoint(Pos);
if Target<>0 then
SendMessage(Target, EM_REPLACESEL, ord(True), LPARAM(PChar(Edit1.Text)));
If the window underneath the cursor is not an edit window, this will, probably, be benign.
I am using the code below to create a messagebox in Delphi 7. However I also have another form on screen who's FormStyle is set to fsStayOnTop and the messagebox appears behind this form.
Is there any way to force the messagebox to appear in front?
if Application.MessageBox('Amessage here','Title', +MB_APPLMODAL + MB_ICONQUESTION + MB_YESNO) = IDNO then
Call NormalizeTopMosts prior to showing the message box.
Use NormalizeTopMosts to allow a message box or dialog box that is
displayed using the Windows API functions (such as MessageBox and
MessageDlg) directly, appear on top of a topmost form. Otherwise the
topmost form remains on top, and may obscure the message box.
(Hope it's available in Delphi 7.)
Edit: Not sure about the downvote. If it hints in the direction that OP should use the native MessageBox function and set its parent HWND to the topmost window - I would agree. But maybe this is not possible for some reason.
In Windows.pas you can find more flags to MessageBox():
MB_APPLMODAL = $00000000;
MB_SYSTEMMODAL = $00001000;
MB_TASKMODAL = $00002000;
Read about them in MessageBox documentation
You can even use MB_TOPMOST flag.
Try MB_TASKMODAL flag instead of MB_APPLMODAL.
I'm using Peter Below's PBThreadedSplashForm to display during application startup. It gets updated as various databases are opened during the creation of the data module (just before the main form is created).
The problem is that we have a check for the existence of certain things that is done during the creation of the data module. If any of those items are missing, a modal dialog is shown so that either the item can be created or the application closed. (The missing items are typically indexes, and the dialog is primarily used when we reindex databases, so it's aimed at the developers and not normal users.) However, the modal dialog is displayed behind the splash screen; it appears to be the focused window, as the caption changes, but it displays behind the splash screen.
The splash screen is created using the Windows API CreateWindowEx() from a different thread than the main process, using the following code:
procedure TPBSplashThread.CreateSplashWindow;
const
TopmostStyle: Array [Boolean] of DWORD = (0, WS_EX_TOPMOST );
NoActivateStyle : Array [Boolean] of DWORD = (0, WS_EX_NOACTIVATE );
var
wsize: TSize;
begin
wsize.cx := FSurface.Width + GetSystemMetrics( SM_CXEDGE ) * 2;
wsize.cy := FSurface.Height + GetSystemMetrics( SM_CYEDGE ) * 2;
FWnd := CreateWindowEx(
TopmostStyle[ FTopmost ] or WS_EX_TOOLWINDOW
or WS_EX_STATICEDGE or WS_EX_CLIENTEDGE
or NoActivateStyle[ Win32MajorVersion >= 5 ],
MakeIntResource( FWndClass ),
nil,
WS_POPUP or WS_BORDER,
Forigin.x, Forigin.y,
wsize.cx, wsize.cy,
0, 0, hInstance, self );
If FWnd = 0 Then
raise exception.create('TPBSplashThread.CreateSplashWindow: CreateWindowEx failed');
end;
FTopmost is a property (with the obvious meaning) that is never set, so it's False due to the default initialization during class construction. (I've also tried explicitly setting it to False, just in case, with no effect.) I've also tried using SetForegroundWindow() and SetWindowPos() during the OnShow event of the modal dialog with no effect.
Does anyone have any idea what might be causing this?
Ok. Finally got the problem solved. It appears to be caused by the WS_EX_NOACTIVATE flag in the call to CreateWindowEx(). Changing it to remove that seems to solve the problem; the modal dialog displays above the splash screen, and because it's modal the splash screen can't be brought above it.
The working code is:
FWnd := CreateWindowEx(
TopmostStyle[ FTopmost ] or WS_EX_TOOLWINDOW
or WS_EX_STATICEDGE or WS_EX_CLIENTEDGE,
MakeIntResource( FWndClass ),
nil,
WS_POPUP or WS_BORDER,
Forigin.x, Forigin.y,
wsize.cx, wsize.cy,
0, 0, hInstance, self );
Thanks, Rob and Craig, for the efforts.
If you're looking for an explanation, I can't help you.
If you're looking for a solution, you're not the first. Eddie Shipman encountered this same problem in May. His proposed solution was to make the other dialog (the one hidden by the splash screen) be a topmost window, but he ultimately avoided the issue by hiding the splash screen before the application needed to display any other windows.
Another suggestion was to post commands to the splash screen and have it display the message box. The dialog could be parented to the splash screen. It's tricky, though, because you're not afforded any of the luxuries of the VCL anymore since it doesn't work outside the main thread.
You should be able to fix this by parenting the dialog to the splash screen. Assign the splash screen's HWND to a global variable, and override the dialog's CreateParams method. If the global HWND has a value assign it to the Params.WndParent variable that CreateParams passes in. The fact that they're from different threads shouldn't matter, since it's just dealing with the HWND, not a VCL object, and Windows will handle the synchronization.