Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Display Text on Menu Bar 2
- Thread starter Jay9988
- Start date
-
1
- #2
Mike Lewis
Programmer
As far as I know, there is no way of directly addrressing the menu bar. The only thing you can use it for is to create menu pads.
With that in mind, you might be able to get close to what you want by creating a dummy menu pad:
[tt]DEFINE PAD userpad OF _MSYSMENU PROMPT "User: " + lcUserName[/tt]
That will place the user name to the right of the existing menu. Because there is no corresponding DEFINE PAD commands, it won't actually open a menu. You could add [tt]SKIP FOR .F.[/tt] to prevent the menu being clicked on (even though clicking on it won't have any effect). And you could add STYLE and COLOR clauses to make it stand out from the other menu pads.
CORRECTION: I should have said SKIP FOR .T. rather than SKIP FOR .F.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
With that in mind, you might be able to get close to what you want by creating a dummy menu pad:
[tt]DEFINE PAD userpad OF _MSYSMENU PROMPT "User: " + lcUserName[/tt]
That will place the user name to the right of the existing menu. Because there is no corresponding DEFINE PAD commands, it won't actually open a menu. You could add [tt]SKIP FOR .F.[/tt] to prevent the menu being clicked on (even though clicking on it won't have any effect). And you could add STYLE and COLOR clauses to make it stand out from the other menu pads.
CORRECTION: I should have said SKIP FOR .T. rather than SKIP FOR .F.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
- Thread starter
- #3
-
1
- #4
Alec_Gagne
Programmer
Just a thought.
I recall Drew Speedy doing something like this many years ago as he had a similar need to keep a display value in sight and wanted it to the far right of the main menu just to the left of the minimize, maximize and close icons.
He defined a new borderless child form (desktop=.T. Alwaysontop=.T.) and put the desired display text inside that new form. Then he used BindEvents to position and keep that new borderless form hovering over the proper position of his parent form. As the parent form moved on the desktop or was resized, thanks to the bindevents, the child form moved accordingly.
I never had a need to try it, but I saw his demo and it seemed to give him the results he desired.
Alec
I recall Drew Speedy doing something like this many years ago as he had a similar need to keep a display value in sight and wanted it to the far right of the main menu just to the left of the minimize, maximize and close icons.
He defined a new borderless child form (desktop=.T. Alwaysontop=.T.) and put the desired display text inside that new form. Then he used BindEvents to position and keep that new borderless form hovering over the proper position of his parent form. As the parent form moved on the desktop or was resized, thanks to the bindevents, the child form moved accordingly.
I never had a need to try it, but I saw his demo and it seemed to give him the results he desired.
Alec
- Thread starter
- #5
Chris Miller
Programmer
Well, I just would like to point out that Mike's definition of an additional menu item also works, when you define the prompt of the extra menu with leading spaces. It's hard to find out how many spaces you need exactly for the precise right-aligned positioning of a user name, as different names have different widths, but there are possibilities with Fontmetric() and the Txtwdith() function.
There's a third solution, as always, by using GDI+ to draw text anywhere on the desktop, the downside is quite the same as with the extra form: Whenever paint events happen the text is gone, so you have to rewrite the text. It's even more complicated, so I spare posting that code. You can in principle find it in in a paragraph about typography using the graphics.DrawString function. After trying it I think there are more problems GDI+ text rendering raises than it solves. One further problem is finding the right font and size. I noticed the way VFP writes text just with ? on screen or the way label captions are written out differs a bit. And that's also true using the DrawString function of GDI+. In ClearType mode, you have to write text at the same position twice to get the same look as menu items.
That's partly due to how Windows handles fonts with ClearType, but also because the different ways to output strings you have in VFP differ in kerning, too. That can be seen if you have letter combinations like To (where the o is rendered nearer to the vertical line of the T with kerning or AV where V is rendered nearer to the A. The label caption, for example, is rendered with kerning, a menu item prompt is rendered with kerning, but text within a textbox isn't rendered with kerning. So rendering of texts isn't homogenous in VFP.
So there's one more finding of a buggy behavior of VFP spotted by experimenting with GDI+ DrawString. Even without it just the difference of text rendering within a menu prompt, a label caption, the value of a textbox and using the ? command are differing in terms of kerning. You should get the same output from all, when using the same font and font size and font styles, shouldn't you?
Chriss
There's a third solution, as always, by using GDI+ to draw text anywhere on the desktop, the downside is quite the same as with the extra form: Whenever paint events happen the text is gone, so you have to rewrite the text. It's even more complicated, so I spare posting that code. You can in principle find it in in a paragraph about typography using the graphics.DrawString function. After trying it I think there are more problems GDI+ text rendering raises than it solves. One further problem is finding the right font and size. I noticed the way VFP writes text just with ? on screen or the way label captions are written out differs a bit. And that's also true using the DrawString function of GDI+. In ClearType mode, you have to write text at the same position twice to get the same look as menu items.
That's partly due to how Windows handles fonts with ClearType, but also because the different ways to output strings you have in VFP differ in kerning, too. That can be seen if you have letter combinations like To (where the o is rendered nearer to the vertical line of the T with kerning or AV where V is rendered nearer to the A. The label caption, for example, is rendered with kerning, a menu item prompt is rendered with kerning, but text within a textbox isn't rendered with kerning. So rendering of texts isn't homogenous in VFP.
So there's one more finding of a buggy behavior of VFP spotted by experimenting with GDI+ DrawString. Even without it just the difference of text rendering within a menu prompt, a label caption, the value of a textbox and using the ? command are differing in terms of kerning. You should get the same output from all, when using the same font and font size and font styles, shouldn't you?
Chriss
- Status