Is there a way in Delphi 7 to find out if a pop-up menu is visible (shown on the screen) or not, since it lacks a Visible property.
You could make your own flag by setting it in the OnPopup event. The problem is knowing when the popupmenu is closed. Peter Below has a solution for that.
But my I ask why you would want this? Maybe there is a better way to solve the underlying problem.
This seems to be a bit simpler (I used Delphi 2007):
In your WM_CONTEXTMENU message handler, before calling the inherited handler, the popup menu is about to be shown, you can set your flag. After calling inherited, the popup menu has been closed, reset your flag.
procedure TForm1.WMContextMenu(var Message: TWMContextMenu);
begin
FPopupActive := True;
try
OutputDebugString(PChar(Format('popup opening', [])));
inherited;
finally
FPopupActive := False;
OutputDebugString(PChar(Format('popup closed', [])));
end;
end;
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;
I have searched many forums and many web sites but i didn't find the required solution.I had a requirement to show the number of notifications to buttons .When the form Loads.If the notifications are hundred there should be 100 beside the button.if nothing then no notification should be visible.
Please suggest me the required solution..
Thanks In advance.
They are asking the similar functionality as in Icons of IOS4.
If you don't mind using a component for this instead of making your own, there is one that does what you need. It will display a status and looks just like what you have shown in your image link.
You can see this page here
It is not free though.
In iOS 4 there are icons with notifications (for programm-startup) and no buttons (I think), so this is not really the same,... but maybe you can create a custom button (inherit from TButton) and use something like an onPaint Event (sorry this is too much dotnet-style,... don't know how it is called in delphi) to draw this "notification" to the button like you do it in TCanvas.
I think you can use TBalloonHint component. For example, To show the notification,
procedure TForm1.FormCreate(Sender: TObject);
var
point : TPoint;
begin
point.X := sb1.Left;
point.Y := sb1.Top;
BalloonHint1.Delay := 100;
//BalloonHint1.Description := 'This is your Notification!';
BalloonHint1.HideAfter := -1;
BalloonHint1.Style := bhsBalloon;
BalloonHint1.Title := '2';
sb1.ParentShowHint := False;
BalloonHint1.ShowHint(point);
end;
To Hide the notification
procedure TForm1.sb1Click(Sender: TObject);
begin
BalloonHint1.HideHint;
end;
It would be see like the above image
If you want to show images, you can use the BalloonHint1.Images property.
You could use a TPaintBox and draw directly to its Canvas property. TCanvas has a number of methods that would make this a fairly simple task, in my opinion. Just store the background image separately (maybe in a TImage), copy it to the canvas (using the Draw method in the OnPaint event), and then paint the circle (Ellipse method) and the number last (TextOut or TextRect). You can also use the OnClick event of the TPaintBox to manage the "button clicking" operations.
I found this question on Experts-Exchange.
Control's OnExit eats up mouseup event for new control when showing
another window
The problem can be replicated easily.
place 3 tedits on a form. write a showmessage('exit') in edit1's
onexit event run the program give edit1 focus use the mouse to give
edit3 focus, click ok to the showmessage observe how you can't write
anything in edit3 now, until you click with the mouse somewhere on the
form ! give edit2 focus, then use to the mouse to give edit3 focus
observe how you can type what you want in edit3 now !
So far I've established that the problem lies in the fact that edit3
doesn't receive a mouseup-message when the old controls onExit event
displays a window of any kind, i've tried it as well with showing a
form of my own in the onExit event, same result. In fact, windows is
under the impression that the mouse is held down over edit3 after
you've clicked Ok to the showmessage
I guess it's a bug in Delphi/Windows but how to work around it ? I
know i can force a WM_LBUTTONUP on edit3's onMouseDown event (since
its the last event called in the process) but that's more than
tedious, and not always applicable
I am trying to do something similiar:
In the onexit event I show a warningbox and then want to proceed
as normal - moving the focus to where the user in fact clicked.
Is that possible?
Once again PostMessage to the rescue! Defer your dialog just a little bit longer so that Windows can finish its focus change. Post yourself a message instead of showing the dialog directly:
const
WM_SHOWMYDIALOG = WM_APP + 321;
TForm1 = class(TForm)
Edit1: TEdit;
Edit2: TEdit;
procedure Edit1Exit(Sender: TObject);
private
procedure WMSHOWMYDIALOG(var Message: TMessage); message WM_SHOWMYDIALOG;
end;
procedure TForm1.Edit1Exit(Sender: TObject);
begin
PostMessage(Self.Handle, WM_SHOWMYDIALOG, 0, 0);
end;
procedure TForm1.WMSHOWMYDIALOG(var Message: TMessage);
begin
ShowMessage('Nice one');
end;
And everything is fine :)
I'm not so sure that the reason of the behavior is an eaten mouse message. Anyway, either that's the case or not, when you activate a window in an OnExit event of a control, what you're doing is, changing the focus while the focus is changing. That's because, the window is activated before WM_SETFOCUS for the newly focused control returns. This is discouraged, the below quote is from 'Best practices' section of 'Win32 Activation and Focus', a blog entry on MSDN:
Avoid manually changing focus when getting and/or losing focus. This
usually proves to be error prone.
The fact that the controls are disabled during focus transfer due to the modal nature of the activated window certainly would not help. If you really must do this, an approach like Heinrich's answer would at least delay the launch of the window till the focus transfer completes.
In the onexit event I show a warningbox and then want to proceed as normal - moving the focus to where the user in fact clicked. Is that possible?
Yes, (Screen.)ActiveControl will always point to Edit3: before and after the call to ShowMessage:
procedure TForm1.Edit1Exit(Sender: TObject);
begin
ShowMessage('Exit');
PostMessage(ActiveControl.Handle, WM_LBUTTONUP, 0, 0);
end;
But this is just for completeness sake to your question! And it certainly is no tip nor advice! See Sertac's answer for the reason.
Regarding Notification Area recommendations by Microsoft, I'm looking for ideas or a Delphi component to implement Notification Area Flyouts.
The first "natural" idea is to use a standard Delphi form, but I'm facing two issues with it:
I can't get the form border behavior using the standard "BorderStyle" property. Tried to "mimic" the border using the GlassFrame property along with BorderStyle set to bsNone, but there's no GlassFrame when there's no border (at least, in Delphi 2007).
I can't figure out how to make the form close when the user clicks everywhere out of the form itself. Yesterday I was trying with different messages, but no one works as expected.
I will thank any clue or component to make it happen :)
Best regards.
jachguate.
ps. There's a related question in converting notification area icon to Program icon in Win7 (Delphi).
update[0]
I'm still looking for advise. #skamradt answer looks very good, but unfortunately doesn't work well in practice.
update[1]
Finally, The auto-close behavior is working with the WM_ACTIVATE message after a calling SetForegroundWindog to force flyout "activation"
begin
FlyoutForm.Show;
SetForegroundWindow(FlyoutForm.Handle);
end;
Now, I'm looking for advise to reach the border behavior and visual style, because the closest behavior is achieved with style as WS_POPUP or WS_DLGFRAME, while the closest visual goal is achieved setting style as WS_POPUP or WS_THICKFRAME.
I believe what your after is the following:
TForm1 = class(TForm)
:
protected
procedure CreateParams(var Params: TCreateParams); override;
procedure WMActivate(Var msg:tMessage); message WM_ACTIVATE;
end;
procedure TForm1.CreateParams(var Params: TCreateParams);
begin
inherited;
Params.Style := WS_POPUP or WS_THICKFRAME;
end;
procedure TForm4.WMActivate(var msg: tMessage);
begin
if Msg.WParam = WA_INACTIVE then
Hide; // or close
end;
This will give you a sizeable popup window with a glass frame. You can't move the window without additional programming, since the standard windows caption is missing. When another window gets focus, the FormDeactivate event gets fired...but only if you switch to another form in the same application. To handle it regardless of the application switched, use the message capture method.