I have a multi-form application in which a child form is positioned on the second monitor on startup, at which time its BoundsRect is saved.
When the computer's display configuration changes, Windows moves the form to the first (primary) monitor. I can catch this change with WM_DISPLAYCHANGE:
procedure WMDisplayChange(var msg: TWMDisplayChange); message WM_DISPLAYCHANGE;
What I'm interested in doing is moving the child form back to the second monitor when it reappears in the configuration (i.e. Screen.MonitorCount goes from 1 to 2), e.g.:
childForm.BoundsRect := childForm.m_WorkingBounds;
// (or)
childForm.BoundsRect := Screen.Monitors[Screen.MonitorCount-1].BoundsRect;
However this assignment is have no affect -- the child form stays on monitor 0.
I've tried other approaches, such as SetWindowPos(), with no success ...
Root of your problem is in the fact that Delphi VCL does not refresh its internal list of monitors when they actually change. You have to force that refresh yourself.
Monitors are refreshed with TScreen.GetMonitors method that is unfortunately private method so you cannot call it directly.
However, TApplication.WndProc(var Message: TMessage) processes WM_WTSSESSION_CHANGE and upon receiving that message it calls Screen.GetMonitors - this is most benign way to achieve your goal.
When you receive notifications that monitors are changed just send it to Application:
SendMessage(Application.Handle, WM_WTSSESSION_CHANGE, 0, 0);
I tested this with old version Delphi5 and it worked easy just to:
Screen.Free;
Screen := TScreen.Create(Nil);
The screen handling has changed in later versions of Delphi, however a similar approach may work.
Related
I want to create a Delphi application that does something interesting when the user moves his mouse over the top-left corner of the screen. I thought about it and plan to do it with the following strategy:
Create a very small 3x3 Form and make it transparent and always on top. Also make it with no title bar or border.
Define mouse enter event for the Form.
I use the following code for step 1:
procedure TopLeftForm.FormCreate(Sender: TObject);
begin
FormStyle := fsStayOnTop;
self.TransparentColor := true;
self.TransparentColorValue := self.Color;
self.BorderStyle := bsNone;
end;
The problem is that I found that when the Form is transparent, it can't capture mouse enter events. I could make the Form not transparent in order to get mouse enter events, but that way users can see the Form at the top-left screen corner, which is not what I want.
What's your suggestions to my problem?
What you want is a 'Hook' that can give you information about mouse events without the events being intended for your program. It's too big a topic to be able to give you a how-to in one go, but these two links should be helpful:
Understanding how to use Windows Hooks
Mouse Hook Tutorial with Delphi codes
Why use a Windows Hook?
The Windows environment is designed around messages being passed around. Typically, a program is only interested in messages that are sent directly to its own windows. Trying to make sure that your application has a window that will get the messages blocks other applications from receiving those messages when they are in the same location under yours, and if another window is over yours then you won't get the messages. If you want to know about activity that's happening that wouldn't normally be sent to you - for example, a mouse click outside of your application's window. To enable applications to have visibility of events that are not destined for itself, a windows hook can be used.
There are different types of hooks, depending on what you want to access. A mouse hook is appropriate for what you have specified here. The system maintains a 'Hook Chain' for all of the hooks that have been installed - it will be your responsibility to pass the messages on down the chain, and to uninstall yourself from the chain.
To access the messages, your hook function will look something like this (code taken from the 2nd link above and adapted):
function MouseHookHandler(ACode: Integer; WParam: WParam; LParam: LParam): LResult; stdcall;
var
vMouseInfo: PMouseHookStruct;
begin
if ACode < 0 then
Result := CallNextHookEx(Data^.MouseHook, ACode, WParam, LParam)
else
begin
vMouseInfo := PMouseHookStruct(Pointer(LParam));
PostMessage(Data^.AppHandle, WM_CUSTOM_MOUSE, vMouseInfo^.pt.X, vMouseInfo^.pt.Y);
// we dont want to block the mouse messages
Result := CallNextHookEx(nil, ACode, WParam, LParam);
end;
end;
In your hook function:
ACode is dependent on the type of hook and indicates the event
wParam and lParam have a meaning specific to the event
To pass the message on, you should call CallNextHookEx - however for some hooks, the message will always be passed on regardless.
Hooks can be installed as Global hooks - meaning they intercept messages on all threads running in the same Desktop / WinStation as the calling thread. So, if you have multiple users connected via RD, for example, the hook is specific to one of those desktops only.
I call gtk_window_is_active(wnd) and always receive 0, even when I know for sure that wnd is active and receiving keyboard input. What is the cause and where is the remedy for this?
In fact, I run gtk_window_list_toplevels() and iterate over the list - and gtk_window_is_active() returns 0 for each of them!
When you create a GtkWindow it is still in the 'unrealized' state. You have to call show() on it and let the main loop run, then the window gets realized. So if you call gtk_window_is_active after creating the windows, but before the main loop has chances to run, you will get false.
Thanks to Emmanuele Bassi, Gnome Foundation staff, I figured it out: the problem is that my focus-in-event handler returned 1 (TRUE), and thus prevented the default GTK behaviour. It turned out (something not obvious) that keeping track of the active window is part of that default behavior that i unknowingly overrode.
So, I changed focus-in-event handler of my windows to return FALSE (0), and ever since gtk_window_is_active() works like a clock.
I came to realize an unhelpful (to my task) detail: gtk_window_is_active() only works AFTER all focus-in-event handlers have completed working. Well, I have a mouse click handler that activates some other window, and then needs to check if a certain window is active (these things belong to different objects and different modules, yet are executed within one click hadler invocation). In my case gtk_window_is_active() is useless: it returs FALSE for the active window until after my click handler has finished and the focus-in-handlers (mine and the default) have finished, too.
we want to take care that all running busy indicators will be stopped after a couple of time. How can we do that? For the moment we use setBusy(false) for each control.
Thanks a lot!
I think that you should change your overall approach because it's not a good UI/UX pattern.
First of all, why do you have more than one busy control in your view? For instance, you if you are loading record in a list you just set busy the list, not the whole page. If you are submitting a form data, you set busy only the form not everything else.
Second of all, why do you say "For the moment we use setBusy(false) for each control"? You should remove the busy state after a specific event. For istance when you finished to load list's result or you get the result of a form submission.
Anyway, to solve your current issue, the best approach is to use XML binding with a temporary JSON model.
You could have a JSON model like with content like this:
{
busy: false
}
and you bind the busy property of the control to youtJSONModel>/busy at this point when you need to set the control to a busy state you can do this.getView().getModel("youtJSONModel").setProperty("/busy", true); and when you have finished the operation you can do this.getView().getModel("youtJSONModel").setProperty("/busy", false);
I have events (ProductOrderRequested, ProductColorChanged, ProductDelivered...) and I want to build a golden record of my product.
But my goal is to build the golden record step by step : each session of activity will give me an updated state of my product and I need to store each version of the state for tracability purpose
I have a quite simple pipeline (code is better than words) :
events
.apply("SessionWindow", Window.
<KV<String, Event>>into(Sessions.withGapDuration(gapSession)
.triggering(<early and late data trigger>))
.apply("GroupByKey", GroupByKey.create())
.apply("ComputeState", ParDo.of(new StatefulFn()))
My problem is for a given window I have to compute the new state based on :
The previous state (i.e computed state of the previous window)
The events received
I would like to avoid calling an external service to get the previous state but instead get the state of the previous window. Is it something possible ?
In Apache Beam state is always scoped per window (also see this answer). So I can only think of re-windowing into the global window and handle the state there. In this global StatefulFn you can store and handle the prior state(s).
It would then look like this:
events
.apply("SessionWindow", Window.
<KV<String, Event>>into(Sessions.withGapDuration(gapSession)
.triggering(<early and late data trigger>))
.apply("GroupByKey", GroupByKey.create())
.apply("Re-window into Global Window", Window.
<KV<String, Event>>into(new GlobalWindows())
.triggering(<early and late data trigger>))
.apply("ComputeState", ParDo.of(new StatefulFn()))
Please also note that as of now, Apache Beam doesn't support stateful processing for merging windows (see this issue). Therefore, your StatefulFn on a session window basis will not work properly when your triggers emit early or late results of session windows since the state is not merged. This is another reason to work with a non-merging window like the global window.
For example I need to disable two buttons in runtime. After I disabled first button it bacame gray, the second - it also became gray. But I do not know how to make the repainting simultaneous!
I need something like that:
freeze the Form (disable repainting)
disable first button
disable second button
Enable Form repainting
How to implement that?
Look at the Win32 API WM_SETREDRAW message. For example:
SendMessage(Handle, WM_SETREDRAW, False, 0);
Button1.Enabled := False;
Button2.Enabled := False;
SendMessage(Handle, WM_SETREDRAW, True, 0);
InvalidateRect(Handle, nil, True);
Messages cannot be processed until your application re-enters a message loop, so any attempt to modify/update control state that relies on message processing will not work within a single sequence of code that does not "pump" messages.
Fortunately the VCL controls typically provide a means for force repainting without waiting for messages to be processed, via the Update method:
Button1.Enabled := False;
Button2.Enabled := False;
Button1.Update;
Button2.Update;
This works independently of having to disable form repainting. The form will not repaint until your application goes into a message loop anyway, so disabling form painting and re-enabling within a single procedure that does not itself cause message processing is a waste of time.
This may not be exactly simultaneous repainting of the two buttons, but truly simultaneous painting of two separate control is impossible without getting into multithreaded GUI painting code which I think is way beyond the scope of this problem. Calling Update on two buttons in this way will be as near simultaneous in effect as you need however.
To Elias551:
LockWindowUpdate is probably not the best way to handle this since it is intended for drag and drop operations and can introduce subtle bugs when misused.
See http://blogs.msdn.com/b/oldnewthing/archive/2007/02/22/1742084.aspx
Instead use SendMessage(hwnd, WM_SETREDRAW, FALSE, 0)
The above decision with WM_SETREDRAW does not update child windows.
Instead, i recommend RedrawWindow:
RedrawWindow(Handle, nil, 0, RDW_INVALIDATE or RDW_ALLCHILDREN);
This could help: the API LockWindowUpdate(Handle: HWND) locks drawing to the handle and children.
ex:
procedure TForm1.ColorButtons();
begin
LockWindowUpdate(Self.Handle);
// Make some stuff
LockWindowUpdate(0);
end;
Once the locked handle is reset, the component is repainted