Is there any way to embed a TPopupMenu directly on a form, as if it was a panel always open? or maybe just the TMenuItems.
No, it is not possible to embed a menu on a form. The reason is partly that a menu isn't an ordinary window that you can easily manipulate.
So you need to find a different solution. And there are many options you can chose from:
Using a TToolBar:
It doesn't look particularly modern and out of the box you don't get much control over the appearance, though. Also, I don't know exactly how robust this solution is. I stopped using toolbars many years ago.
Using a TCheckListBox:
In this case, I'd recommend you to create a subclass TCheckListBoxEx which toggles an item if you double-click its caption.
Creating a custom control:
This is what I'd do if it is about a central GUI in an important application, because this way you get full control over the appearance and behaviour and can make it really robust. I have done a modern such menu at work, but currently I am at home so I cannot show you it. Here, however, is a menu I made more than ten years ago for a hobby project:
If you don't need the menu to be attached to the form like a control, but only need it not to close when you select an item in it, there are (hacky) ways to achieve that. But that is a different Q.
Everything I've found says I can't do this with Delphi 2's TMainMenu but if somebody here has managed it somehow, I'd really like to know the trick. I found code that changes the System menu font size but none that confines the change to only the application. Anyone here know how to do this or do I have to just accept Delphi 2's tiny menu font size that appears on today's large screen monitors? (Moving the app to an upgraded Delphi is not the answer I need ;-)
The only way to achieve per application custom menu fonts is with an owner drawn menu. Delphi 2 does not support owner drawn menu items directly in the VCL properties of a TMainMenu component. This support was introduced only in Delphi 4.
You could still implement an owner drawn menu, but it would involve implementing them using standard Windows API techniques, and handling the required messages on the forms which own the menus involved. It is not especially difficult but not as straightforward as the event based implementation available in Delphi 4 and later.
You can still use a TMainMenu to define your menus but in your application you would then need to programmatically set the owner draw flag on the menu items and handle the resulting messages appropriately. Doing this, you will need to handle all aspects of drawing the menu - you cannot simply set/change the font and leave the system to draw the menu items. You may also need to provide additional handling for any keyboard shortcuts you have set up.
If this is a viable approach then information on implementing owner drawn menus at the API level can be found here.
I'm trying to activate Hint from control of different application created from delphi upon focus, I'm using hook to identify the focused control, and then use WM_MOUSEMOVE, which I think will activate the Hint of that control, the handle would be the Control itself and the lParam is the Left and Top of the Control. The Control activate the OnMouseMove Event, but the Hint never shows. but when I use SetCursorPos, Hint show, but I need to show the Hint with out the cursor move on that Control. Can you please help me with this? Thank you in advance... by the way I'm using Delphi XE4
Among the really asked question is how to show the hint of a control that resides on another application (i am afraid without hook that application can not be done), the title is "Delphi - Activating the Hint from another control of Application".
First is first: That can be done without knowing what language the other app was done, but it is very complex to put it here (and i am not an expert on such way of coding, also i hate apps that work that way).
Second: The main idea is to hook the other application, search on Google some code of that apps, that can show you a rectangular hole square of the object the mouse is passing over, that application while doing it is iconized (i do not remember the name of it).
Waht such app does: As you move the mouse over the screen it overlays a rectangular over the control that mouse is over, then if you press the key to print screen, that small region is the only thing that goes to clipboard; on of such apps i saw had an extra funcion, they can move such controls if you press cursors on keyboard, also can hide/enable/disable such control... more, it can also make controls that are invisible to be visible, etc... i saw it working on my computer, and hey, for fun it is pretty and to DeBug or get extra things on some apps is also great (make some menús to be visible and enabled and then can use such funtions).
Please, please, understand i am agaist piracy and also against using such apps to let code to be run... some apps need pay for letting some menus enabled, but they have the code there, no need to change EXE to have/use that menus; just using this kind of apps makes that limited apps to be unlimited (just enable or show hidden menus and voila).
Note: To unhide menus, mouse point is not needed to be over the app, can be anywhere and is not moved.
The idea i want to say is: Any app can move, alter any control on any other app (at least on Windows) that is running, so maybe there can be a way to show such hint.
In the past i had use such app (sorry i do not remember the name) for DeBug my own apps, so i do not need to recompile in such cases where something was wrongly hidden, also work with buttons, labels, texts, combos, memos, etc.
Now my small problem is: I just need exactly what title say, but i can not make it to work.
Must be:
Mouse position must be irrelevant (it also must be able to be outside the application)
Just when a button that has focus is pressed with keyboard (Space or Enter) or just after some code somewhere on my application, i want to show the Hint of a specific TEdit for a short period of time.
I did not get Hint to be shown; not unless mouse point is over such TEdit but i want/need mouse pointer to not be over it, neither it to jump to the TEdit.
Idea Conept for that Hint to be shown: After doing some code that changes something, show extra info associated.
Example:
A button with that loads a file using an open dialog, filename is put on a ReadOnly TEdit (so it let user copy the text, but not change it); i want extra info that i punt on .Hint of such TEdit to be shown inmediatly.
That hint use is for not overload window with a lot of fields (TLabels) for showing such file data.
Simple idea: such Hint shows TimeStamp and size of the selected file.
P.D.: Not much related (since i am trying with a normal plain text hint), but hints can also store a full HTML page and with 3rd party tools be shown as an HTMLhint, so they can show a lot info of that file (also its content, etc) in a web based format; as i say i first try with standard plain text hints.
In order to show hint programatically you need to call TApplications ActivateHint method to which you specify the position parameter.
http://docwiki.embarcadero.com/Libraries/XE3/en/Vcl.Forms.TApplication.ActivateHint
Based on position parameter Application automatically finds which controll is at that position and shows its hint.
NOTE: Position parameter screen coordinates in pixels and not your controll coordinates. So you will have to use ClientToScreen method to change your coordinates apropriately.
You can see simple example of how to use this here: https://stackoverflow.com/a/15031208/3636228
Now if you need to do this from another application then you will have to add some comunication mechanizm to these two application so that one could send a proper message to tell the other to show the hint at specific position. But this does require you to be able to change both applications.
EDIT: This works with VCL applications but I'm not sure if it would work with FireMonkey applications.
I have an interesting observation and question, but first a comment. I have been using Delphi for 14 years and have taken a job developing an iOS mobile application using XE5. This is my first time using FMX and frankly I feel like I am stepping back in time many moons ago. In other words, if this is the future, then it feels like I have crippled. No problem though. Roll with the punches. Developing in this brave new world is not just a job. It is an adventure.
Now my question. Start a FMX mobile project using the "Header/Footer with Navigation" as your base. Then add an edit control (Edit1) to the first tab item. Then set the tab control align to none and move it to the right until you can clearly see the form itself. Then add an edit control (Edit2) to the form.
Now set the form's active control to Edit1 and run the app - no focus on Edit1. Now set the form's active control to Edit2 and run the app - focus is placed on Edit2. Interesting. Tab is a foreign word to tablets, right? Why have active control or even setfocus available? Is this an oversight by Embarcadero? Any thoughts?
Long story short I think they both have potential uses.
I use the SetFocus call to manually show the keyboard. Lets say the user navigates to a page where they're 100% sure to be putting in their username (or any text), I'll use ctrl.SetFocus to show the keyboard just to save them having to click (or is it press now?) on the edit.
I don't see ActiveControl being as useful, but it could definitely still be used. You could possibly use it to set up some sort of tabbing like structure for when the user presses Next on the keyboard (when the edit's ReturnKeyType is rkNext).
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