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 gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

VFP Window at Runtime

Status
Not open for further replies.

Scott24x7

Programmer
Jul 12, 2001
2,826
JP
So I think I saw something on this years ago, but I have since forgotten, so if someone can help me here, it would be greatly appreciated.

When I have my VFP app at run-time (outside the VFP dev IDE), as an .exe file, I have a window bar at the top that has a Windows Logo (old school one) and next to the "Microsoft Visual FoxPro" is stated.
Is there any way to hide this bar? I have my own interface inside that I'm using now, and I don't need/want any "windows" frame around the running application. How can I do this?

In main form I have the property "TitleBar" value 0 - Off
I also tried setting MDI Form property both to True and False, but neither seemed to help.


Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."[hammer]
 
Scott,

If you want to hide the entire window (not just the title bar), do [tt]_SCREEN.Visible = .F.[/tt] at the start of your program.

But if you are also doing this when running in the IDE, be sure to set the property back to .T. when you finish the test run, otherwise you'll not get back to the IDE.

Alternatively, put [tt]SCREEN = OFF[/tt] in your config.fpw file. This has the advantage that the window will not flash on and off again when the application first loads.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
Hi Mike,
You just flashed me back to 20+ years ago. I had totally forgotten about CONFIG.FPW. So this should live in the same directory as the .EXE as I recall. What else should I be thinking of for that file? I don't have a lot of the old apps I used to use with it. I'll do a quick search, but anticipating I'm not going to find it, just in general, what are good habits to have there?
Thanks heaps!

Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."[hammer]
 
Yes, put your config.fpw in the same directory as the EXE. This is not essential (you can use command-line switches to point to a different location) but it is the simplest.

The other thing you might want to put in config.fpw is [tt]RESOURCE = OFF[/tt]. This will prevent Foxuser files being created on the user's system (unless you have some special reason for wanting these files to be present). It's especially important if the user is launching your app directly from the desktop, otherwise they will see Foxuser.DBF etc appearing on the desktop, which is bound to cause a certain amount of confusion.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
Just look at faq184-6512

Since you want to do your own top level form, yes, you don't want the _SCREEN. This howto tells you what properties to esssentially set on your top level main form.

Bye, Olaf.
 
Scott, I hope I didn't mislead you about _SCREEN.Visible = .F. It is really intended for when you have a top-level form. It doesn't make sense to hide the entire VFP window otherwise, because you will also be hiding your ribbon and all your normal forms.

I have mainly used _SCREEN.Visible = .F. when displaying a login form. At that point, I only want the login form to appear on the screen, not the main window. But I restore the main window once the user has successfully logged in.

I hope this makes sense.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
Hi Mike,
That makes sense. My whole application was gone with SCREEN = OFF in the Config.FPW, so I'll look at the FAQ Olaf pointed out, and see if I can get that working from there.
Thanks much for the reminder of CONFIG.FPW. I went and looked, and I can see some of my old FP2.6 apps had a lot of stuff that I think now no longer matters. I note that it is where I used to set the main "Title" though, but I think that's even pre VFP, which has more control over the window and frame as I recall.

Let me have a look at this.
The Ribbon class is really coming along. I slowed down a bit to resolve this so that I can make sure everything is working as desired once I work through these bits.

I am at that stage where now I have the core functionality of the application in place, it's time to make it pretty...


Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."[hammer]
 
Hi Olaf,
So I looked at that FAQ and there is one thing still. It seems the main thing I was missing was the Show Window property, setting it to 2 gets me close.
In your example there is a "caption" set, and then above the application (for lack of a better word), that caption shows in a "title" bar, with nothing else. Is there a way to make that title bar invisible? (Or set a size to 0 or some way to trick it?)
And also, is there a way to prevent it from taking over the entire screen? I'm running on massive monitors, and I don't want it to resize from the size I've set it...


Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."[hammer]
 
The main thing to pick up from the faq is really just setting your main form ShowWindow property to 2 (As Top-Level Form), which makes your main form a form of the same type as _SCREEN is. That's already the most important thing. Just notice your main form then won't be modal. That is not a problem, as there is READ EVENTS.

As you said you skipped the mainmenu.mpr in thread184-1777736, I already thought you were skipping the whole _SCREEN already, not just the menu. A real SDI (single document interface) application is one, where you define your own _SCREEN by a top level form, that's all there is to it.

Bye, Olaf.
 
Ah found it... stupid.
Don't know when, but that form got its WindowState property set to Maximum. Now at "Normal" it's taking the sizes I want. Very cool.
The stupid "title bar" is blank, after setting the caption to "" and all the controls off but it makes for a lot of white space at the top of the form, which is annoying. I don't know why it won't go away. In my child forms, the title bar is gone entirely. I don't know if this is a side effect of the Top-Level form issue or not.
But it's now very very close to the look and feel I'm trying to achieve.


Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."[hammer]
 
You have a flat look of the top level form title bar on Windows 8-10. Other Windows versions have other themes/looks, so only older Windows versions are a problem. Having flat look on Windows 7 or Vista will look odd anyway. So why care?

If you absolutely must have this, notice it makes a difference if you try to set Titlebar=0 at design time already, or at runtime. You can set Titlebar=0 in Init and what remains in Windows 10 is a white line a few pixels thick. I think you may dig deep into the Windows API on any functions doing something on an HWND and find things to make all borders invisible or transparent. Anyway, I'd not overdo this.

One side effect of your main form having no title bar is you can't drag it. Also, you don't have the close button. If you do your own title bar and accept it to have a few pixels above, then the dragging and other parts of the title bar can be redone. This just is not my taste. The outer design could at least be that of whatever Windows version. If you have a modern website, you also don't care about the outer layer of the browser, this is browser UX, your site has it's own UX and it's typically fine.

What would give much more control about looks is WPF, but then we don't talk of VFP anymore. VFP means Winforms, live with it.

Bye, Olaf.







 
Hi Olaf,
I have already solved the drag issue, as all my other forms are already made this way, which is why it was disappointing that the top level form would behave like that with the bar showing even with nothing on it. I will try your trick of Titlebar = 0 and see if that solves it.

I also noticed, with the top level form now, I have to set my other forms to be "In Top-Level Form" instead of "In Screen" or they don't show up. But that was an easy fix with my other forms all using formclass, so inheritance made that easy.



Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."[hammer]
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top