This is more like a theoretic question: I am curious why the Show method will not also restore the form (like wsNormal).
I know that Show does not set WindowState:
procedure TCustomForm.Show;
begin
Visible := True;
BringToFront;
end;
but why? I mean, I expect the form to actually show up on screen, when I call Show. Obviously, this will not ALWAYS happen. More exactly, it will not happen when the window is minimized.
So, what is the logic behind Show? Why they left out WindowsState?
Visibility and window state are simply independent properties. It is perfectly reasonably that you may wish to change one but not the other.
The design choice made by the VCL designers was to map the underlying Win32 library to the VCL in as fairly direct manner. This means that VCL designers can have flexibility to make their own choices. Were the VCL designed the way that you suggest it would make it much more difficult to change visibility without also changing window state, for example.
I have a VCL application that i'm testing but don't have the source code.
I need to validate what text was drawn to the labels on the screen but the labels are not a window so I create a hook to the drawtext function and i can get the text that was drawn to the screen.
But i cant validate where on the screen that text was drawn as the function gets hdc and a point where to draw the text in the context.
I need to figure where on the screen that hdc is located and make sure the the label is correct.
Is there a way to do it?
Managed unmanaged dose not matter to me.
You could build a DLL in Delphi and inject that DLL in the target process. As your are happily hooking Win32 APis, I suppose you will not have problems with that.
In that DLL, you could find (using Win32 APIs) the HWND which is the "parent" of the Label.
With that HWND, you can find the associated TWinControl. For that you must dive into the VCL source code.
For Delphi 4 (yes, I know, it's old) you have to build an Atom String, use GlobalFindAtom, and then GetProp. The result is a pointer to the TWinControl.
For Delphi7 (old, too) you have to use RegisterWindowMessage with a string made up off "ControlOfs" followed by the module handle and the thread ID. The LRESULT of a SendMessage is then a pointer to the TWinControl.
Sorry, I don't know for other Delphi versions, but all should be findable in the VCL sources.
Once you have the TWinControl pointer, you can enumerate the children as TComponent, and get their Name's (as they appear in the source code you don't have...), their ClassName's, and so on, you get the idea.
I think you would need to do something like this:
Call WindowFromDC to find out the window that hosts the label. As you know, a Delphi label is non-windowed and the control actually paints on its parent window. This may fail if the parent is double buffered. In that case you've no hope of getting the window handle from the device context since all you have is the device context of a bitmap.
Now that you have the window on which the label paints, you need to find out the location of the label on the window. The VCL calls SetWindowOrgEx to arrange that the device context has logical coordinates 0,0 at the top-left of the label. So you can call GetWindowOrgEx to find out the location of the label relative to the parent.
Now you know the location of the label relative to the parent, and the window handle of the parent, you can work out where the text is being drawn on screen with ClientToScreen.
Since device contexts only have meaning in the process that owns them, you'd need to inject into the target process to call this.
i know that windowless controls are not magic. A windowless control can have input focus (e.g. Internet Explorer). Input focus is nothing more than drawing either:
a blinking cursor
a dotted line around the perimeter
a slight blue tinge on a button
and when the user begins mashing keys, reacting appropriately. You know the keystrokes are meant for that focused control, because that's the control has focus.
In the case of my (Windows®) window, i would have to know that my windowless child control (let's pretend it's a descendant of TGraphicControl) gets the keyboard events. So during my form's OnKeyDown, OnChar, OnKeyUp, i would need to pretend they are going to my windowless child control.
Which i can do, but it is a pain.
But then the user will probably want to use Tab navigation, and i'll have to somehow intercept Delphi's normal tab control order handling, and hook in myself to say that this thing is the next (and previous) in the tab order.
Which i can do, but it is a pain.
And then there's ActiveControl, which doesn't understand anything except TWinControl's. So if Delphi ever tries to figure out who has focus, it will go insane. So i'd have to have an alternate implementation of ActiveControl.
Which i can do, but it is a pain.
In other words: is this just too much work? i'm fighting eveything that Delphi is, all so i can have a few dozen windowless controls accessible through keyboard input? The Delphi designers never contemplated using interactive windowless controls, and if i try now to work it in, i'll just stuck in the hurtlocker?
Delphi gave me the chance of aiding me willingly, but i have elected the way of pain.
Some further explanation of windowless controls is needed.
Not every control you interact with has to be a windows control. It is quite possible to have focus on, and send keyboard input to, a control that is not a Windows window.
For example, nearly every control you see in an Internet Explorer browser window is a windowless control. In the following screenshot you can see an edit control, which you can type in, and a button which (in this screenshot) has focus:
You can see the dotted focus rectangle, and the button is bluish (which on Windows indicates that it has focus).
If i were to press Spacebar while the Google Search button has focus, it would press the button. The reason this works is because Microsoft wrote an entire widget library of controls. These controls look and feel (almost) exactly like the regular common controls - they are very nearly exact clones of the Windows common controls, right down to the themes being applied.
Mozilla Firefox and Google Chrome also use a widget library of controls. They don't use Microsoft's built-in windowed controls, but instead use a library of graphical, interactive, windowless widgets.
And if you have a suitable development environment, then the windowless widgets work just like "normal" windowed controls. GTK+ is a widget library, and Glade is an IDE that lets you layout controls in that widget library.
i don't know in what development environment Firefox, Chrome, or Blender were created in, but their widgets support windowless controls.
So now onto my question.
Unless i'm mistaken, it appears to me that although Delphi supports a base TControl, (which has width, height, and can paint itself), it cannot receive keyboard focus. It seems to me that Borland never designed Delphi's VCL as a generic widget library. The only evidence i have to support this is that a Form's ActiveControl is a TWinControl:
property ActiveControl: TWinControl;
That doesn't mean that Delphi could be, or must be, limited to windowed controls. The VCL widget library could be extended to support giving focus to windowless controls.
But perhaps Delphi already supports windowless controls, and i just don't realize it? Is there already an established mechanism in Delphi to support giving focus to TControl's? But i'm a reasonably smart guy, and i'm pretty sure Delphi's VCL cannot do what other widget libraries can do.
Which then leads to another question: how much work would be be to subclass forms and such to support it? Is there someone else out there, perhaps someone on TeamB, who's much smarter than i, who has already tried it, and come to the conclusion that it's impossible?
i'm asking now, up front, if trying to add windowless control support is damn near impossible (i.e. futile) - so that i don't spend weeks on it for nothing. i'm trying to draw on the knowledge of a community of Delphi developers.
i'm asking a question.
It's futile to build windowless controls and fit them into Delphi's VCL framework.
You bring up Internet Explorer as an example. But in that case, it's entirely in charge of everything that resides on it. It has its own internal notion of what the active control is, but think about what it looks like from the outside: It's just one giant control. When you ask the OS what has focus, the single browser control has it, no matter which of the browser's subcontrols appears to have focus.
When you press Tab, it looks to the OS as though the browser has simply consumed a tab character, just like edit controls do. Edit controls move the cursor over a few spaces and add tab characters to their internal buffers; browser controls move the cursor to another region of the display.
You're thinking of doing all this on a Delphi TForm. Delphi forms already have a framework for managing the active control and handling keystrokes, and you're going to have to fight it all. If you want windowless controls, go the Internet Explorer route and build your own container control to hold them so that you can remain in charge of everything that happens inside it.
Your container can be a VCL control, but the things you put on it probably can't — they'll still be expecting to use the VCL focus- and keyboard-handling rules. Notice how you can't put ordinary Windows controls in Internet Explorer, either. Anything you put there needs to go through specific ActiveX interfaces. Maybe you'll need interfaces, too, or maybe you can just make your own set of control classes that descend from some special ancestor class you design to work with your container. Don't start with TGraphicControl; it's too entrenched in the VCL to be usable as the basis for your offshoot control library.
It will be a lot of work, but then again, so was Internet Explorer.
Yes, it is futile.
And it's not Delphi's fault, you're just fighting Windows itself.
If you need a control that behaves like a windowed control, use a windowed one.
And you're right, trying to recreate the whole API stack of windowed controls from scratch is a pain.
Yup, you pretty much have it figured out. Using windowless controls means that you lose everything Windows can do to help you. Having more than a couple on a single actual window is pain.
Most of these programs were most likely not originally developed using RAD type tools so had no choice but to re-invent the wheel. One of the largest advantages of Delphi is the deep VCL and 3rd party component support to provide the look you desire.
One technique that I have used with great success to reduce the amount of window handles used in a complex (tax preparation) form based application was to draw the text on a canvas, and moved a single TCustomEdit decendant to the position the user was editing. It was trivial to capture the TAB/Up/Down keys and move the edit to the appropriate position. The challenge we discovered was in drawing a hot rectangle around the mouse hovered field. We ended up with a grid array of TObject, where the array element would be nil (no field), a TLIst (grid contains multiple fields) or a a class that contained our field descriptor. This reduced the amount of range checks we had to perform since it was more likely that the box only contained a single field, or at most 4 fields.
fpGUI Toolkit is an example of what you want. The latest fpGUI code in the source code repository is based on a multi-windowed design. That simple means every widget/component has a window handle, but Windows or Linux does nothing with that window, other that basic notification messages (mouseenter, mouseexit, etc). fpGUI still has full control over where each component goes, if they are focusable, how they look etc. Some widgets/components in fpGUI are non-windowed components too. eg: TfpgScrollbar, TfpgMainMenu, the button in a ComboBox etc.
If you want a true non-windowed version, mean there is only one top-level window that has a window handle, all other widgets/components inside that window doesn't actually exist to the OS (they have no window handles), then fpGUI can help too. The initial design of fpGUI Toolkit was based on such a design. Again, look in the source code repository for the v0.4 branch of code. I that design, fpGUI had to handle absolutely everything, creating mouseenter/mouseleave events, translate co-ordinate systems for container components, handle (fake) component focus states etc... Yes the initial design is a LOT of work, but then you have a very portable framework which can easily be applied to other OSes too.
And yes, fpGUI is fully implemented in the Object Pascal language using the Free Pascal compiler to give me cross-platform support. Currently fpGUI runs on Windows, Linux (32 & 64-bit), Windows Mobile and Embedded Linux (ARM) devices.
I have no idea of what your problem really is, here, but I think this little history may be relevant...
We have an application which fills out a dozen forms. The user may fill out additional forms, and also change values filled out by the application it self.
Now, in our first implementation, we used windowed components for every single input field, so that the fields could receive focus and input. That turned out to be a big problem, because all this windows took a lot of resources.
We now have windowless controls for every input field. That means that all we end up with, is a combined drawing of the form and its input fields. When the user clicks inside the drawing, or uses some keystrokes to move/set focus, we create a new windowed control for the clicked field. When the user moves to the next input field, we destroy the first window, and create a new one. This way we only have one windowed control which again gave us a nice speed improvement.
Again - I have no idea of what you really want to manage. TWinControl is a TWinControl for a reason, but there may be a solution to what you want, what ever that would be...
I think fgGUI may help you out.
Do check its Wiki first.
I think you can use this framework for your application in Delphi as it is written totally in Pascal. Actually it is based on FreePascal ;)
HTH
With Delphi 7 trying to change the color of the title bar of the software from the window theme. I have seen code which allows you to change ALL the title bars of all programs, but I am just wanting to change my program.
Anyone seen/done anything like this? Don't mind paying for a component if needed.
I believe Windows sends the WM_NCPAINT message to an application when it should paint the window frame including the title bar. The default behaviour is to fall back to the default Windows handler which draws the default frame. You could replace this, or re-paint the title-bar section right after.
This looks like a good example: http://delphi.about.com/od/adptips2006/qt/draw_captionbar.htm
The answer by Stijn is not fully complete, as the caption and border of the window will also be redrawn when it is (de-)activated. So in addition to WM_NCPAINT you will also need to handle WM_NCACTIVATE. Unfortunately this can not simply be replaced, as there is other code in the default message handler (apart from drawing code) that needs to be executed. But calling the default handler will in turn lead to the default caption and border being drawn first, which you would then need to draw over with your intended colour, resulting in flicker.
One way to work around this is to adjust the drawing region that the default message handler is called with. See "Drawing titlebar on XP with themes" for an example using Windows API calls that should easily translate to Delphi. Note that this deals only with the text in the caption bar, but the principle applies.
You might take a look at a skinning library. ExpressSkin by DevExpress is a good one.
I'm trying to draw over the whole screen by using the desktop canvas and painting to it directly. The problem is I can't clear that desktop canvas. I've tried setting the canvas.pen.style to psNotXOR and draw over the old image but unfortunately, this is not reliable enough and some left overs are still present in some conditions.
My need is to draw a selection rectangle around a window / control when the mouse is over it.
You don't write on what OS you have problems with the artefacts after clearing.
At least with desktop composition activated it is a very bad idea to draw directly to the desktop and to do XOR painting (see "Drawing To and Reading From the Screen -- Baaaad!" in this blog post). Apart from the negative performance implications you can't be sure what other painting happens at the same time and what effects and animations alter the displayed content, so a simple XOR may not be enough to completely erase everything.
One possible way to implement it would be a transparent overlay window of desktop size, and to draw your rubber band selector over that. Invalidating the whole window if the size changes should be enough, no need to erase the old selection line. If the overlay is removed the line will be gone too. Desktop composition will make sure that no flicker occurs. However, switching applications while selecting an area will be problematic, you need to catch this and immediately cancel the selection.
Edit:
I just tested it with Delphi 2009, and with the following test app:
a form with FormStyle set to fsStayOnTop and with AlphaBlend set to True
with an overridden CreateParams() method to add the WS_EX_TRANSPARENT extended style flag
I can pass all mouse clicks through to the underlying windows while being able to draw into a window on top of them. This should get you started.
I've done some stuff like this in the past and I've never come up with an acceptable solution.
Having a think about it though you could send the desktop HWND an invalidate command.
Because the desktop is a modified listview control you should able to use something like
procedure InvalidateDesktop;
begin
RedrawWindow(GetDesktopWindow, 0, 0, RDW_INVALIDATE);
//if that doesn't work then try this:
//Sendmessage(GetDesktopWindow, wm_setredraw, 1, 0);
end;
That might do what you want, I haven't tested it as I've just knocked it up for the example.
the problem is that Windows won't return me the control behind the mouse
I think you need to hook the mouse event messages for this - the hooked message then gives you the window handle that the mouse is over.
Look up SetWindowsHookEx(WH_MOUSE,,,) and MOUSEHOOKSTRUCT.
This is how we do it in our app:
FBitmap.Canvas.Brush.Color := clWhite;
FBitmap.Canvas.FillRect(FBitmap.Canvas.ClipRect);