Is there a way that I can force the help question mark button to be visible on a form that is not a dialog in Delphi 2010?
I want to use the help question mark so that a user can click it then go to a control, but by default it is only available if the border style is dialog, but our application does not use dialog forms
I was looking at Overriding the CreateParams procedure but I am not sure what code to put in it to force the button to show?
Paul
According to MSDN, this is not a Delphi-specific limitation, but it is imposed by WinAPI. As you may know, the help question mark is turned on by WS_EX_CONTEXTHELP style, which cannot be combined with WS_MAXIMIZEBOX and WS_MINIMIZEBOX styles. So you can have a non-dialog form and display the question mark, provided that the form does not have maximize and minimize buttons in its caption. If you need the maximize and minimize buttons as well, then I think you should subclass the window and provide custom nonclient paint (drawing the question mark on your own) and nonclient hit-test processing.
You want a help button in the top (grabber) non-client area of a non-modal window that appears beside maximize and minimize?
Use TJvCaptionButton (included in the JEDI VCL) on your form, put a help question mark bitmap on the control button, and have that open the help to a particular page, from an integer help context like this:
Application.HelpContext(aHelpContext);
Because it paints in the non-client area of the window, you might experience some strange behaviour on some Windows theme settings; I don't think Jedi JvCaptionButtons look quite native on Win7 with Aero enabled, for example.
Update The linked question below in comments mentions putting the form into help-mode like this, contributed by DavidH:
SendMessage(Handle, WM_SYSCOMMAND, SC_CONTEXTHELP, 0);
end;
Related
Recently I've been doing some research in to VCL Styling (Embarcadero XE2 for Delphi).
I can load and set the styles so that works fine.
Currently I'm exploring the VCL Style Designer and what I try to figure out is how can I move the minimize, maximize, resize, close and help button to the left instead of the current default right while the application text (caption of the form) is on the right.
I am at my whits end and hope some one can give me some pointers.
So basically what I try to 'emulate' is the Mac look on a Windows form.
Any help is welcome.
What do you want accomplish is not related to the VCL Style Designer, instead you must create a custom form style hook.
Follow these steps.
Create (and register) a new form style hook descending from the TFormStyleHook class.
Override the PaintNC method to draw the title buttons in the new positions.
Handle the WM_NCMOUSEMOVE, WM_NCLBUTTONDOWN and WM_WM_NCLBUTTONUP messages to detect the status of the title buttons (hot, pressed) and fire the actions (close, restore, maximize, minimize).
I'm looking at wanting to implement a tooltip similar to the way Delphi XE does when you're debugging and you hover over an object. ie, it opens up a hint window with + signs which you can expand etc.
I'm trying to create a hint window which will show a list of items (for example) when hovering over a control (such as a button) which will let the user click on an item and I can then do something based on the item they've selected.
Are there any components out there that might do that already? Or am I better of just creating a borderless form and handle the showing/hiding myself with mouse events?
Thanks
Jason
I know there are hint components with embedded html. So you can have a kind of html treeview inside you hint!
I think it is a solution for you.
HTMLHint from TMS Software
THintBox from Cramon Utilities (freeware!)
I have been trying to find a good-looking design using Aero in Delphi 2010. One of the obvious uses one sees, is where the glass frame is extended to include the OK/Cancel buttons at the bottom of the screen. I notice though that this doesn't look quite right in Delphi 2010 - there is a white border all around each button.
This image shows the problem: the top 3 buttons are from my app, the bottom two were taken from Paint.NET's Layer Properties dialog.
I tried various combinations of DoubleBuffered and a few combinations of placing the controls on other controls first, but the problem remains. Any ideas?
If no one has a clean solution, as a workaround use TBitBtn with DoubleBuffered = false.
It appears that the only workaround is owner-draw, or a third-party button control Check out the Glass Button by Roy Klever or, as stated in the QC entry linked below, TBitBtn with DoubleBuffered=false, which was the accepted answer above to this question.
This is a bug in Windows Aero DWM or else a bug in the windows common controls, or a bug in the way the VCL class hierachy handles common control window messages and painting when painting on glass. In short, windows common controls do not paint themselves properly on glass, or rather DWM composition (Aero) is broken. Surprise surprise.
The standard VCL button component uses the Window Class BUTTON from Windows Common Controls.
Note that TSpeedButton does not use the windows common control, and does not have this problem. however, it also does not accept focus.
It appears Embarcadero knows about this issue, it is QC # 75246, which is closed because it is really a bug in the common controls library, as Won't Fix, with the suggestion to use TBitBtn. Buttons are not alone, this is part of a group of QC reports including panels, and other common controls.
However I have a commercial TcxButton (part of developer express components) which accepts keyboard focus, and does not draw this glitch. Any code that uses the Win32 common control button control appears to have this problem. It may be possible that a low level Win32 API hacker might find a workaround for this. I am looking into it. This answer will be updated if I figure it out.
One interesting detail: TcxButton has three drawing styles, cxButton.LookAndFeel.Kind = {lfOffice11,lfFlat,lfStandard}. Selecting lfOffice11 adds this glitch back in. It looks like a strange interaction between the glass feature in aero in Vista/Win7 and the common control/xptheme button drawing code.
It may be that the only workaround is to use a completely app-drawn button control and to not use Windows common controls buttons, or any button control that relies upon the XP theme engine to draw buttons, on an aero glass pane.
Edit: July 28, someone at Embarcadero has closed the above QC Entry, which was a mistake. I am urging them to reopen it, if only to clarify if this is indeed a Windows bug in the common controls dll.
If you wish to play around, make a copy of the VCL source code for the TButton and TCustomButton classes from StdCtrls, as I have done here, modify CNCtlColorBtn, so that you force one of three things to happen - PerformEraseBackground, DrawParentBackground or inherited, and see the results. Interesting stuff.
procedure TCustomGlassButton.CNCtlColorBtn(var Message: TWMCtlColorBtn);
begin
PerformEraseBackground(Self, Message.ChildDC);
Message.Result := GetStockObject(NULL_BRUSH);
(*
with ThemeServices do
if ThemesEnabled then
begin
if (Parent <> nil) and Parent.DoubleBuffered then
PerformEraseBackground(Self, Message.ChildDC)
else
DrawParentBackground(Handle, Message.ChildDC, nil, False);
{ Return an empty brush to prevent Windows from overpainting we just have created. }
Message.Result := GetStockObject(NULL_BRUSH);
end
else
inherited;
*)
end;
Some interesting reading on Vista era glass/DWM/aero APIs (C++ developers blog)
Here I'm providing some code that makes TButton look right on Glass. Unfortunately it makes the form "click-throw", so I don't think it's a good idea. But maybe you can find a way to fix the form's "click-throw".
if you are able to use win32 api, try exploiting NM_CUSTOMDRAW notification (not ownerdraw), as i do (yes, buttons DO send it, including radio and checkboxes. For these it is best to use WM_CTLCOLORSTATIC though.). This is how it is done in C++, but the idea is the same. While my idea is good, it so happens that my buttons do DISAPPEAR once per program execution from the window, when they are customdrawn and i need to hover mouse over them so they are visible again. That's why i'm still looking for comments for this. Note that it is really difficult to reproduce disappearing buttons in one-form applications. I hovewer am experiencing this behaviour in every project.
case WM_NOTIFY:
switch(((LPNMHDR)lParam)->code){
case NM_CUSTOMDRAW:
{
NMHDR *nmh=(NMHDR*)lParam;
//these 6000 through 6004 are button identifiers assigned by me
if(nmh->idFrom >= 6000 && nmh->idFrom <= 6004){
switch(((LPNMCUSTOMDRAW)nmh)->dwDrawStage){
case CDDS_PREERASE:
//BackgroundBrush is a HBRUSH used also as window background
FillRect(((LPNMCUSTOMDRAW)nmh)->hdc, &((LPNMCUSTOMDRAW)nmh)->rc, BackgroundBrush);
break;
}
}
break;
}
break;
i have a flow panel that i'm adding extra items to it at runtime based on whether they have chosen to show all the items. that's all works fine; the expansion is controlled by a toolbar button.
the trouble is we'd like the user to be able to move his mouse over the "+" sign to expand the section.
initially i looked at TSpeedButton (OnMouseEnter) but even when it's "Flat", the focus rectangle still shows and so the glyph isn't centered. the main problem with this solution is it's appearance.
then i looked at making a descendant of TImage. that's a bit "unconventional" but it'd work. in OnMouseEnter or OnClick, it'd toggle an internal boolean "Expanded" flag and then load the appropriate picture from a resource. i have a dislike for unconventional solutions like that.
i need to add it to a few different screens so it's probably prudent for me to have/build a component for this. i have JVCL but i don't see anything suitable offhand.
thank you for your comments/help!
I always liked the approach used by the ModelMaker Code Explorer.
For example, when you're adding a new method, some rarely-used stuff is displayed collapsed ('Options and Directives' in the image below).
(source: 17slon.com)
When you hover over the text, you notice that it's actually a flat button. (Except that it's not - I believe Gerrit does some custom painting magic here).
(source: 17slon.com)
When you click this button, a panel appears. Button is still there, but with a new image. You can click it to close the panel.
(source: 17slon.com)
The state of this toggle button is preserved between sessions. IOW, even if you restart the Delphi, next tima you invoke 'Add Method', the 'Options and Directives' panel will appear exactly as you left it the last time.
i have a dislike for unconventional solutions like that.
Over the past few years, I have grown a bit suspicious of unconventional UI solutions — which is what you seem to be creating here. Why not just use a button that the user actually has to click? That seems to be much more common in the software I use, be it MS Office or programming utilities. Also, I'd make the button somewhat larger: in the screenshot, it really seems like a tiny little thing you have to target with your mouse cursor. Oh well, and if I'm bugging you with advise you haven't asked for anyway, why not give it ">>" as a caption instead of "+"? And if you'd give it a textual caption with a mnemonic as well, it'd actually be keyboard accessible. All this should make your UI better and more intuitive. I guess.
I do apologize for not answering your question, but I hope you'll spend 2 minutes thinking whether your users would actually prefer this solution :-)
Good luck!
Actually, I think that using a TImage in this situation is pretty conventional. I have seen many people suggest using the TImage, when either the TButton, or any of its associates did not have the right amount of control for whatever the developer was trying to do.
Have you tried a TBitBtn? I think when you get rid of the text it centers whatever image you have associated with it. I just checked in Delphi 6, all I have installed on this machine, and it had the MouseMove event.
I have a Delphi 7 application that has two views of a document (e.g. a WYSIWYG HTML edit might have a WYSIWYG view and a source view - not my real application). They can be opened in separate windows, or docked into tabs in the main window.
If I open a modal dialog from one of the separate forms, the main form is brought to the front, and is shown as the selected window in the windows taskbar. Say the main form is the WYSIWYG view, and the source view is poped out. You go to a particular point in the source view and insert an image tag. A dialog appears to allow you to select and enter the properties you want for the image. If the WYSIWYG view and the source view overlap, the WYSIWYG view will be brought to the front and the source view is hidden. Once the dialog is dismissed, the source view comes back into sight.
I've tried setting the owner and the ParentWindow properties to the form it is related to:
dialog := TDialogForm.Create( parentForm );
dialog.ParentWindow := parentForm.Handle;
How can I fix this problem? What else should I be trying?
Given that people seem to be stumbling on my example, perhaps I can try with a better example: a text editor that allows you to have more than one file open at the same time. The files you have open are either in tabs (like in the Delphi IDE) or in its own window. Suppose the user brings up the spell check dialog or the find dialog. What happens, is that if the file is being editing in its own window, that window is sent to below the main form in the z-order when the modal dialog is shown; once the dialog is closed, it is returned to its original z-order.
Note: If you are using Delphi 7 and looking for a solution to this problem, see my answer lower down on the page to see what I ended up doing.
I'd use this code... (Basically what Lars said)
dialog := TDialogForm.Create( parentForm );
dialog.PopupParent := parentForm;
dialog.PopupMode := pmExplicit;
dialog.ShowModal();
I ultimately ended up finding the answer using Google Groups. In a nutshell, all the modal dialogs need to have the following added to them:
procedure TDialogForm.CreateParams(var Params: TCreateParams);
begin
inherited;
Params.Style := Params.Style or WS_POPUP;
Params.WndParent := (Owner as TWinControl).Handle;
end;
I'm guessing this does the equivalent of Lars' and Marius' answers in Delphi 7.
Is the dialog shown using ShowModal or just Show? You should probably set the PopupMode property correct of the your dialog. pmAuto would probably your best choice. Also see if you need to set the PopupParent property.
First of all, I am not completely sure I follow, you might need to provide some additional details to help us understand what is happening and what the problem is. I guess I am not sure I understand exactly what you're trying to accomplish and what the problem is.
Second, you shouldn't need to set the dialog's parent since that is essentially what is happening with the call to Create (passing the parent). The dialogs you're describing sound like they could use some "re-thinking" a bit to be honest. Is this dialog to enter the properties of the image a child of the source window, or the WYSIWYG window?
I'm not sure I quite understand what you are getting at, but here's a few things I can suggest you can try...
This behaviour changes between different versions of Delphi. I'd suggest that this is due to the hoops they jumped through to support Windows Vista in Delphi 2007.
If you are using Delphi 2007, try removing the line from the project source file that sets the Application.MainFormOnTaskBar boolean variable.
With this removed, you should be able to use the various Form's BringToFront / SendToBack methods to achieve the Z-ordering that you are after.
I suspect that what you've discovered has been discussed on this link
Of course, I may have just missed your point entirely, so apologies in advance!