It may sound silly, but I encountered a few situations, when I would like the application not to show what is happening, until an another specific action happens (stringGrids are filled with data, UI is prepared...). Is there a way to prevent messages from being sent from application to OS?
So, is there some oposit to
application.processmessages
?
Something like:
application.stopProcessingMessages;
fill stringGrids, prepare the UI...
application.processMessagesAgain;
?
Of course, I could run the actions in a separate thread, but there are situations where I either don't want to, or cannot do it in a separate thread.
Check TDataSet.DisableControls for data aware controls, and BeginUpdate / EndUpdate for some VCL / RTL classes (including TStrings), and - specific for the mentioned TStringGrid - see Delphi TStringGrid Flicker
It turned out, that although I thought, that using the WM_SETREDRAW message is the right solution, it has a few disadvantages. The biggest one is, that if used, user can click through the form. So the final solution is simply an empty TPanel placed over the whole form like this
panel1.Left:= 0;
panel1.Top:= 0;
panel1.Width:= frmMain.Width;
panel1.Height:= frmMain.Height;
After the form is prepared, the panel is shrunk, made invisible etc. It reliably hides every flickering and other things, that doesn't look good, and I want to hide them from the user.
We are working with Firemonkey since version 1, and still find difficulties updating components that are currently visible on the screen. There are many 'ways' to request a repaint in Firemonkey, perhaps too many:
Applying a style (ApplyStyle event) - mostly when it becomes visible on screen
Requesting ".repaint" - some components have this
Requesting ".realign" - sometime works, current versions of FMX seem to drop / hide it
Requesting ".invalidate" - some components, mostly forms, have this
Requesting ".invalidateRect" - most components have this
Calling the ApplyStyle event manually - not guaranteed to work and design-wise is incorrect...
Given the lacking documentation for the platform, is there a "well defined" way to change the visual appearance (internal values of a style) when a component is already displayed? I.e. a listboxItem that is already present and visible on screen, a TGrid cell, and so on. Would appreciate your thoughts...
I don't think there's a single unified 'correct way' to refresh the visual of components in Firemonkey.
However, as a recommendation from personal experience, I'd take the .repaint route - this method is at the TControl level, and so it precedes primitives and styled controls (which are generally made up of primitives) and so applies to all visual controls. It also doesn't require parameters, so it's a good all-round solution.
I have noted that Firemonkey has always had an issue correctly repainting controls of it's own accord. Often I'm left with a 'shadow' of the previous visual of a control/primitive, and must call .repaint manually to update it. This got noticeably worse with FM2 and FM3 (presumably due to optimizations made for mobile platforms), and so doing a manual .repaint -- especially where effects such as TGlow and moving or rotating controls/primitives are concerned, has become a standard practice for me.
Have you seen this?
I have a little utility application (for easy load / test xml generation from CDS and/or DBGo), and I had put some buttons (the poorest button of all, TButton) to trigger some actions.
I never paid attention to appearance, because I'm the only one that uses it. So today I added a new button, and they appeared different from the others in designer - but not when running. It's just an copy and paste process (change the button name, caption and event - the rest is equal to the origin).
When I looked the other buttons have an grey gradient and round corners, the button I copied and pasted not (just a bare rectangle). When running all buttons where just bare rectangles.
So I discovered that on designer, W7 and delphi are applying themes. On running, they are obeying the Project/Options/Application/Enable runtime themes flag.
This is annoying. There's a way to make Delphi doing that obeying the project options flag on forms designer?
(Or even manually if is not possible to automate that)?
EDIT:
The toolbars on the form are from CNWizards ;-)
EDIT II:
Apart of disabling themes for the IDE executable, all buttons get themed equally if the form (or project) is reloaded. But it's really weird.
If you want to enable/disable themes in the IDE, then open the properties of bds.exe, select the 'Compatibility' tab, and make sure that the 'Disable visual themes' checkbox is unchecked/checked.
Programs that you run from the IDE will inherit the compatibility settings of the IDE.
Delphi IDE itself is an application and the way the designer draw the form is using the setting for the IDE application (delphi32.exe or bds.exe's compatibility settings) so the answer is no. The default behaviour is different between IDE versions, for eg. the opposite behaviour (not drawing themed) happened in past.
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
I'm developing a multi-document application. Currently it uses MDI which is quite convenient for me (as a developer) as well as for users I believe. However there is one "against" - I haven't found a solution to quickly load many child windows (each time the window is created and maximized to fill the parent's area, there is an 'animation' of resizing which takes a lot of time) so far, thus I'm considering switching back to tabbed interface (which requires some more work, I need to "embed" a form to the page sheet, as there are many "kinds" of forms available, some for editing text documents, some for other objects)...
So, what is your opinion? Should I use MDI or tabbed interface?
To avoid the resizing animation (and thus the delay) of new MDI child windows, send a WM_SETREDRAW message to the parent TForm's ClientHandle property before creating your child windows, and then send it again when you are done, ie:
Self.Perform(WM_SETREDRAW, False, 0);
... create child windows as needed ...
Self.Perform(WM_SETREDRAW, True, 0);
Windows.InvalidateRect(Self.ClientHandle, nil, True);
Windows.UpdateWindow(Self.ClientHandle);
MDI was developed back in the Windows 3 days (or possibly earlier?) and isn't well-supported these days. If you need multiple documents with different forms, I'd recommend using a tabbed interface. Use frames instead of forms, and create the new tabs and place a frame on it, aligned alClient.
There are certainly more negative points to MDI than the one you cite. You can find discussions on this in the Wikipedia, and even in the Windows Interface Guidelines as well. MDI has been deprecated now for years. Microsoft itself isn't using MDI in its "standard" form for any of its big applications any more, they often provide just a MDI emulation together with other UI styles.
If your program is for users with multiple screens both MDI and a tab-based UI have the problem of limiting the document windows to the insides of the parent window.
With a proper application design you don't really have to decide between MDI and tab-based UI. Let your users decide which UI they are most comfortable with, and which fits their working style best. Allow for multiple independent top-level document windows (either in one application instance or in multiple) as well. It can be as easy as creating frame classes for your documents, and deciding at runtime whether to embed them into a tab control, into a MDI child window, or into a top-level window.
Question: is it important that users be able to see more than one of your embedded forms or frames at a time? If not, certainly go for tabs.
Tabs make it easier to navigate and to see what you have available. But with standard PageControl you can only see one tab at a time - there's no "tiling" or "cascading". Problems begin for example when users need to drag things from one tab to another. It can be done, of course, but is not as convenient - because this time users do not see where they are dragging something to.
To overcome this limitation you'd have to look at a docking UI, which adds complexity, but could give you tabs as well as being able to tile them.