Hiding the Command window 1

[ajpa]

A trawl through FAQ and the posts reveals that

HIDE WINDOW COMMAND (or "Command" - not clear which)

should do the trick, or that the window will vanish when you display a form, especially if called from a program.

None of this seems to work (except, of course, in a standalone application when there isn't a command window anyway).

In version 2 it used to be possible to run the bulk of your application between the menu's SHOW code and its CLEANUP code. So the whole application was effectively nested inside the menu program, and the command window remained invisible until something went wrong and you crashed out with the menu still active.

Does anyone know how to perform a similar trick in Visual FoxPro (I have version 6)?

Tony Ayres

 

[munishmalik292]

Hi,
If I am understanding your problem I think you are not giving "read events" command in your main program. give this command after you have called your menu program. It will go something like this in your main program...

set sysmenu to (this command will deactivate the foxpro menu)
do menu.mpr (this will call your menu)
(or you can also say do form main.scx if you are calling a main form which has buttons for the menu instead of the regular bar menu)

(Plus add whatever other code you want to for opening database, files, initialising variables, etc. etc. then add these lines)

read events
set sysmenu to defa
return

this should enable your application to run in the foxpro environment without the command window. I hope this is what you were looking for and hope it helps you.

Munish

 

[ajpa]

Dear Munish

Brilliant. Thank you very much. (The only thing one has to be careful about is putting a CLEAR EVENTS into the 'Exit' button of the menu. I got stuck with 'Cannot quit FoxPro' when I first tried it - and of course I had no Command Window to help me solve the problem!)

Tony

 

[ajpa]

Hmmm...

There is actually another problem: all the various forms now seem to want to act as a single unit, and I'm getting messages protesting that I've illegally redefined objects (I'm afraid I haven't got to grips with defining classes yet, and I tend to re-use objects by copying and pasting them).

For the moment, I've had to remove the READ EVENTS and have the window back. I'll try to tidy up the code over time.

Tony

 

[wgcs]

As a Tip, I always have (during development) a command before Read Events:

ON KEY LABEL CTRL+F12 SUSPEND

When you press Ctrl+F12, VFP suspends and gives you're command prompt back. Istead of "SUSPEND", You could have "DO Break.PRG" and in Break.PRG, you can restore some environment, like ensuring the Command window is visible (SHOW WINDOW Command), and removing any other obtrusive ON KEY's (we used to have ON KEY LABEL Enter... etc).

As for "all forms acting as one", we really need to know more about how you're designing your program to be able to hazzard a guess at what's happening.

Are you using form files (.SCX/SCT) with MODI FORM? or class libraries (.VCX/VCT) with MODI CLASS? or are you defining your forms in code (DEFINE CLASS xxxx AS FORM .... Createobject('xxx') )?

 

[ajpa]

That's a good idea, and I'll adopt it.

I'm modifying forms interactively, and setting all the properties from the properties window.

As things are now, and the application having had a spell with the READ EVENTS in place, the most recent form I've been working on (and only that form) seems to hide the command window, which then stays hidden until I've come out of the application and pressed Ctrl F2, in spite of my having issued MODIFY WINDOW SCREEN in the menu's 'Exit' button procedure. What is more, this window removes the 'Format' pad from the menu bar (which the system has always added of its own accord, it not being part of myMenu). There's nothing special about this form: it's got an 8-page frame, a couple of button groups and one or two other miscellaneous controls on it - and the only user-defined methods are Activate, Init and Refresh. This curious behaviour persists even when I re-boot.

I haven't been very careful about variable names. Part of the problem is that I haven't got a grip on their scope. I'm not sure, if I define a variable as public in the Init event of a particular container just how far up and down the heirarchy that variable will be recognised. A big topic, I know, and one which I'll have to tackle by doing some serious reading.

Tony

 

[ajpa]

Aha...

I've discovered that HIDE WINDOW COMMAND (with or without the quotes) *does* work if issued from within a form. So a very crude way of achieving the effect is to call a dummy form from the main program, stuff the keyboard buffer with {enter} in the Init method, and provide a single button whose click code contains

HIDE WINDOW COMMAND
thisform.Release

You get a quick sighting of it as it comes and goes, and setting its visible property to false doesn't prevent that: while if you attempt to DO the form with the NOSHOW keyword, it doesn't hide the Command window at all. I suppose the answer will be to fill the form with a pretty picture that can sit there until the user starts doing something.

Tony

 

[Mike Gagnon]

Tony,

You will find that if you design an application that is meant to be a compiled executable (rather than an application to be used within VFP development environment) the command window is not somethying you need to deal with, it just not there.

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[ajpa]

Mike,

Yes, I know, because I have written one or two small single-form applications which sit happily on a remote server (and use solutions provided by kind members from this forum). It's just that my biggest application sits on the local net in my office, so it isn't stand-alone (and in any case, I'm forever tinkering with it). I just thought it would look tidier without the command window.

And it does. The method outlined above does work. It's a bit fiddley getting everything just right, and one or two odd things happen in the dummy window (for instance that you can't invoke the button's click method by stuffing the keyboard buffer with {leftmouse}), but I've got it working to my complete satisfaction now.

Thank you, everyone, for the support.

Tony