var ScreenSaver:String;
var handle:HWND;
begin
Handle := FindWindow('Progman', 'Program Manager');
Handle := FindWindowEx(Handle, 0, 'SHELLDLL_DefView', 0);
Handle := FindWindowEx(Handle, 0,'SysListView32', 'FolderView');
ScreenSaver := 'C:\windows\system32\Mystify.scr /P' + InttoStr( Handle );
WinExec(pAnsichar(screensaver), SW_SHOWNormal);
This code will erase the desktop icons.
How to get the window handle behind the desktop icons?
This isn't really a Delphi question, but anyway... Starting a screen saver with the /P command line switch creates the screen saver window as a child of the given window, with the same size and position - it is meant only to provide a screen saver preview in the Display Properties dialog box. It will not position the screen saver window somewhere in the Z-order beneath some other window. Consequently it will draw over everything, erasing the desktop icons as well.
Unless you create your own screen saver that draws directly on the desktop window I don't think what you want can be done.
As mghie indicates, if you're wanting to start a screensaver, that's not the correct way to do it. Easiest way is:
SendMessage(Handle, WM_SYSCOMMAND, SC_SCREENSAVE, 0);
In my experience, I again agree with mghie; I don't think you can do what you're wanting to do. Windows seems to operate in a different environment when a screensaver is active, e.g. Windows messages don't seem to propagate as expected, etc.
Although, to get at the desktop, I've previously used a handle to the Device Context of the desktop.
var
ScreenDC: HDC;
begin
ScreenDC := GetWindowDC(0);
...
// You can then use the Device Context with Windows API methods such as BitBlt
// and StretchBlt to go graphical work on the desktop.}
...
ReleaseDC(0, ScreenDC);
Related
Anyway to lock orientation to per se Portrait for only a specific form and not the whole application?
Using Delphi xe6, for iOS. Can't seem to find anything by googling. Thank you!
Update:
My underlying issue is that I'm using a zbar unit for scanning and when the screen rotates, the display from the camera view does not. So the app goes to landscape, but the view from the scanner is still portrait, thus making the view look sideways. From what I've googled and tooled around on my own, it appears that locking the orientation maybe easier so here is where I am.
I've found this article: http://www.delphifeeds.com/go/s/84941, but to no avail, the one form I don't want to rotate, still rotates.
I've implemented this code for the time being, although I'm not very found of it. Was just a quick, fix work-around.. I put everything ontop of a layout and on the form's resize event:
with LayoutOrientation do
begin
if Clientwidth > ClientHeight then
begin
Align := TAlignLayout.None;
width := ClientHeight;
height := Clientwidth;
RotationAngle := 90;
RotationCenter.X := 0.948;
end else begin
RotationAngle := 0;
RotationCenter.X := 0.5;
Align := TAlignLayout.Client;
end;
end;
Meh, I don't like this because the app still repaints when it doesn't need to and also the status bar showing at the top still, gives it a funky look. This for the time being works - but really looks like I hacked it, which in this case I did..
Update Application.FormFactor.Orientations before and after showing your form.
Application.FormFactor.Orientations := [TFormOrientation.Portrait];
ScannerForm.ShowModal;
Application.FormFactor.Orientations := [TFormOrientation.Portrait, TFormOrientation.Landscape, TFormOrientation.InvertedLandscape];
It actually depends how do you generally controll your application orientation.
If you use Layouts to control orientation you could force the use of same layour for every oriantation.
If you are creating different forms for different orientation you can force your application to use same for for every orientation.
I am running a Delphi application multiple times and I need to bring each one to top and simulate a mouse click somewhere on its form.
In my app I have a TWebBrowser component and I want to click somewhere in that browser. The thing is that I need to click on flash object inside that browser. I tried to get the ClassName and Handle to click on flash, but is not working with all websites. So the only thing that works is to simulate a mouse click.
For example I load this link into the browser http://bit.ly/XWaelU and I am trying to simulate click on the big "play" button from the flash player inside.
Can someone help me with an example code on how this can be done?
I think the application must be launched with fixed position so the coordinates of the click remain the same, right?
Thanks.
Assuming you want to click a control on the window, with known position relative to the window, from which you have (can get) the handle, you could use this. Demo only on the current form.
Maybe adapted to your conditions.
Procedure SetWindowTopAndClickOnRelPos(wnd:HWND;Pos:TPoint);
var
ChildControlHandle:HWND;
begin
SetForegroundWindow(wnd);
ChildControlHandle:= ChildWindowFromPoint(WND,pos);
SendMessage(ChildControlHandle,WM_LButtonDown,0,5*$FFFF + 5);
SendMessage(ChildControlHandle,WM_LButtonUp,0,5*$FFFF + 5);
Form4.Memo1.Lines.Add(Format('ChildControlHandle: %d',[ChildControlHandle]));
end;
procedure TForm4.Button1Click(Sender: TObject);
begin
Memo1.Lines.Add(Format('Window: %d',[Handle]));
Memo1.Lines.Add(Format('Button: %d',[button2.Handle]));
SetWindowTopAndClickOnRelPos(handle,Point(Button2.Left + 2,Button2.Top + 2));
end;
procedure TForm4.Button2Click(Sender: TObject);
begin
Showmessage('Hallo');
end;
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'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.
My application does automated screenshots of several dynamically created forms. This works perfectly under Windows XP, but doesn't work well under Vista Aero. Most of the forms appear semitransparent in the screenshots. The problem lies in the window animation of Aero.
How can I check/disable/enable this animation from inside a Delphi (2007+) program?
Or as an alternative: How can I make sure the form is displayed properly before making the screenshot?
The link in the comment from Shoban led me in the right direction. A quick check showed a wrapper for the DwmApi in the VCL and from that it went straight forward. Here is the code I successfully use now:
uses DwmApi;
...
SaveDwmCompositionEnabled := DwmCompositionEnabled;
if SaveDwmCompositionEnabled then
DwmEnableComposition(DWM_EC_DISABLECOMPOSITION);
...
if SaveDwmCompositionEnabled then
DwmEnableComposition(DWM_EC_ENABLECOMPOSITION);
Disabling Aero would be a pity - in general it's not a good idea to change the user's choice of UI style.
You may be able to draw the form another way. One thing that comes to mind is using the PaintTo method to paint it to a canvas. (In fact, if you're taking screenshots of the forms as a way of getting what it looks like you probably don't need to show the forms at all - created them with Visible set to false and paint them to a bitmap. Only show them if the user needs to interact with them.)
I was trying to solve the same problem and found this question, but came up with a completely different solution. It doesn't disable the animation, but it allows you to make the window disappear without animation effect.
var oldWidth := Self.Width;
var oldHeight := Self.Height;
try
if Visible and (Self.WindowState <> wsMinimized) then
begin
Self.BorderStyle := bsNone; // do this first
Self.Width := 0;
Self.Height := 0;
end;
//.. Do your screen capture here
finally
if Visible and (Self.WindowState <> wsMinimized) then
begin
Self.BorderStyle := bsSizeable; // or whatever it was
Width := oldWidth;
Height := oldHeight;
end;
end;
You could also move the window to -maxint for X & Y, but I like this better.
You can add a manifest resource to the exe file, to notify Vista you want that the application runs without Aero
http://www.google.be/search?q=vista+manifest+resource+delphi