Create a "Simple" App/EXE

[gguerra333]

I need to build an EXE from a simple PRG. Is there a way to build an application without a form. I need it to run at specific intervals (using windows task scheduler) update some tables and then exit. I have tried doing it with a form and placing the code within different methods. The init method opens the tables but as far as the actual code to update the tables I have tried putting it in the activate, refresh, show etc methods and no go. I even tried placing one command button on the form and still nothing. I need the program to run without user intervention and exit/quit automatically.. Any ideas anyone?

 

[Olaf Doschke]

>SET SYSMENU TO

You don't need top do that for an exe, an exe doesn't show the sysmenu, the sysmenu is the IDE menu, it's not present in the runtime.

Bye, Olaf.

 

[gguerra333]

The reason I did not (or could not use a form) is that no matter where I placed the code to automatically update the tables it would not execute. I tried the form Activate, valid, show etc methods and nothing would work. Also this needs to run completely without user input and I could not get a form to run without at least one control. (I did not try a timer control however). In any case I think I will use the _SCREEN itself, change the caption, remove or disable the system menu and use ? to display status messages. This keeps things simple and effective.

Thanks Olaf..

 

[Olaf Doschke]

Did you see my code? Is it in a form or just using a form? are the "do stuff" lines part of the form? No. Why do you search for an event inside the form? You DO a nonmodal form and then the code following DO FORM executes, immediately and as you have a reference to the form with the NAME clause you can address it - from outside.

By the way, you could also use a form event, the event running after Load, Init, Show and Activate: GotFocus. If you put a control on the form, then it's GotFocus, whatever get's focus first. Anything else is too early and before the form shows. And you don't need a timer, you just need to release the form at the end of your code. Using a form just for output without misusing one of it's event is more transparent. That means if you come back into your project you find the main code in main.prg and not in some event of the form in which you would never guess to look first. Why look out for such an event at all?

Bye, Olaf.

 

[gguerra333]

I did glance at your code. When I started this little project I did start with a form and the first thing I tried was the gotfocus event. It did not run and I think it did not run because there are no controls defined within the form. I did not think of doing stuff outside of the form because in reality no form is needed.. In any case hardly anyone will ever see the program running. It will run on a server out of sight so I think I am good for now. Thanks Olaf

 

[Dan Freeman]

You are going woefully wrong here and making things way too hard on yourself.

Do not make the form modal. A modal form is a wait state, and you don't want that. Set the form's Desktop=.t., then DO FORM as Olaf has shown you. The code in your PRG will proceed after the form displays itself. You don't actually need ANY code inside the form. None. Not one single line.

It isn't rocket science, but it can go badly off the rails if you do TOO much.

One example I see in your code is the CANCEL command. It's pointless, and a throwback to a prior era. When your code ends, so does your application. There's no need to CANCEL. Ever. In fact it can cause some rather unpleasant side effects. That's what I mean by "doing too much".

 

[Dan Freeman]

By the way, I stand by my WAIT WINDOW comments. There is nothing like it anywhere in Windows. It exists only in Foxpro, much the way the OK button with a big red checkmark screams "DELPHI!".

 

[gguerra333]

Thanks anyway Dan, BUT I don't care if there is anything like it in Windows (TM) as you put.. I just want it to work and for that matter I can always use the old ? command which is WAY more rudimentary than WINDOW WAIT. OH and there is no form here, just "stuff" as Olaf puts it. It opens some tables, does some updating and then closes, all automatically. This is not for public consumption anyway so the "Windows" thing does not matter. If you want "Windows" compliant move over to .NET.. Foxpro is dead (at least as Microsoft is concerned). I still love it and find it quite useful. Have a good one...

 

[Olaf Doschke]

>the OK button with a big red checkmark screams "DELPHI!".
Well, or PASCAL or any other Borland language, also C++ Builder.

I bought Borland Pascal with my first PC Pentium I changing from Atari ST. And such buttons were revealing most any Borland language, also Borland C++, which I had later on. I remember a big green chackmark though, and a red X for cancel button. Like here:

http://alycesrestaurant.com/messageboxes.htm

Bye, Olaf.

 

[Dan Freeman]

Ah yes, Olaf. I had the colors backwards. (Showing my age!) Been a long while since I've seen them!

gguerra333, if you're going to be rude you can help yourself.

 

[gguerra333]

Dan, I wasn't trying to be rude, so if I came across that way I am sorry. I was just trying to solve a problem and not worry so much as to what "looks" right and whether it is "Windows" or not. As for the CANCEL command you mentioned earlier it does what I need which is close the program. If I were in VFP it would kick me back to the command window (I could use QUIT as well).. thisform.release or CLEAR EVENTS would not apply here since there is no form and no READ EVENTS.
just curious, what would you use?

 

[Dan Freeman]

When your code ends, the program ends. There is no need for CANCEL, particularly as the last line of code. It accomplishes exactly nothing that won't happen anyway. The program will end on its own when there's no further code to execute.

It also doesn't hurt anything in this case, but it may betray a lack of understanding which is the only reason I mentioned it. In other cases, it can send things into a weird state, which is why it's good to understand that it just isn't ever necessary.

 

[gguerra333]

There will also be varying opinions. Not using a command to indicate the end of code IMO is sloppy. If not CANCEL, then RETURN or QUIT or if dealing with forms then the appropriate commands, not just an abrupt end to the code that leaves you wondering Now What? I always document my code even if i am the only one that will ever read it or look at it. So if nothing else you can think of it as a form of documenting the code. Everyone has their own way of coding and I have been coding since way before any type of OOP or "Visual" anything existed as you can probably tell, I am old school. In the old days you wrote complete programs/applications not just "snippets" of code here and there. So bear with me if I seem old fashioned. Although I am self taught in VFP (and still learning) I have been coding in Foxpro/xBase since the mid 80'. Now just curious Dan, how can things go into a weird state by using CANCEL?

 

[gguerra333]

Here is s copy and paste from the VFP help file

CANCEL Command  

Ends execution of the current Visual FoxPro program file.

RETURN Command  

Returns program control to a calling program.

QUIT Command  

Ends the current Visual FoxPro session and returns control to the operating system

Now using the RETURN command to end my program code would be "Sloppy" in my opinion but would accomplish the same as no command as you suggest but how would you suggest that CANCEL or QUIT would not do what I want?

There is no lack of understanding...

 

[Olaf Doschke]

CANCEL has a special meaning and way to end a program abnormally, it is meant to exit earlier and, well, CANCEL actions, not return normally. I'm also not sure what Dan means with unpleasant side effects, but CANCEL surely does act on the call stack in a different way than a normal RETURN would. And I wouldn't put CANCEL at the end of any procedure, just beacause I don't intend to return any value.

If you want something to document the end of your program, rather use QUIT than CANCEL. In purpose of documenting code, this would leave me wondering "Why Cancel?" Was all that code wrong, why does he want to cancel? Canceling out of something in the end looks very awkward, doesn't it? If you want to quit, you can call QUIT. You could also put a comment there: *END to document this is the end of code. As you don't do any READ EVENTS you don't need CLEAR EVENTS nor QUIT, though. I can still understand to do that for indicating the completeness of the program. You could also do without ENDPROC, ENDFUNC but I also add these, even though foxpro will not fail on these missing. But even QUIT will cause something else than omitting it, if you define an ON SHUTDOWN action. Try it yourself: put ON SHUTDOWN MessageBox("Bye") into your prg and then end it with QUIT or without anything. There is a difference, and in the end it might be best to only have a comment *END

Bye, Olaf.

 

[gguerra333]

Thanks Olaf, I guess we can agree to disagree.. CANCEL is not used to return values. RETURN is used for that but at the end or in the middle of a called procedure. This is not a procedure it is a simple linear program that starts and ends within the same file which brings me to repeat what the VFP help file says.

CANCEL
Ends execution of the current Visual FoxPro program file.

with special emphasis on the words "program file"

If the developers of VFP did not want people to use it they wouldn't put it there. Sure you can CANCEL inside a DO WHILE loop like the example in the VFP help file but the correct command there would be EXIT and then issue CANCEL or QUIT at some other place in the code.

This is more from the entry in the VFP help for CANCEL

Remarks
Control returns to the Command window when Visual FoxPro is being used interactively. 
If a distributed run-time application is running, CANCEL terminates the application and control returns to Windows. 
If a program is executing in Visual FoxPro during design time, CANCEL terminates the program and control returns to the Command window.

Executing CANCEL releases all private variables.

You can't really dispute what it says or at least I won't. I can tell you the difference between CANCEL and QUIT in my case.. If I am still testing the program in VFP I sure do not want QUIT because that will close eveything and take me back to the OS just like the VFP documentation states. Once you have a working program sure you can use QUIT. VFP is high level language and most people are not concerned with a "call stacks" ENDPROC and ENDFUNC may work but this is not a PROCEDURE or FUNCTION. Anyhow enough said and let's move on, thanks again Olaf.

 

[Mike Lewis]

May I jump in for a moment.

Whenever I see CANCEL in a program, I assume it's because the programmer wants to abnormally terminate the program when running in the development environment. It's a temporary command. It is typically used because you are not yet ready to test any subsequent code, or because you want to interrupt the processing, perhaps to check the results.

I would never use CANCEL in a live program. I would use RETURN to come out of a function or method. I would use QUIT to terminate the entire application.

The description of CANCEL in the VFP Help file is literally correct. It describes the effect of the command, but it doesn't give any insights into how or why it should be used in practice. This is in fact typical of much of the Help.

OK. That's all from me. Thanks for listening.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

Mike, you have a lot better feeling for the english language than I have, thanks for that, you hit the nail.
I would always read CANCEL as a abnormal exit, a cancellation, and a QUIT as a quit.

Also I never said CANCEL is there to return values, I said the opposite, I said: "I wouldn't put CANCEL at the end of any procedure, just beacause I don't intend to return any value." That's double negation.

CANCEL could be used, if you intend to end a procedure without returning a value, as it cancels out there. But you're right, it's useless to talk of it as returning without return value, as CANDEL doesn't only cancel out of a method or prg, it removes all stack levels and abnormally returns program execution to the top stack level, which can be the Foxpro command window, or Windows itself, depeding from where you started.

But surely CANCELs intention is an abnormal ending of an application, in contrast I read QUIT as a normal end of execution, technically it may make no difference.

The help also says on CANCEL, that it releases all private variables. That also may cause the side effects Dan speaks of, but is done anyway, if you return back to the top callstack level, and QUIT does that, too, even though the help mentions other aspects of QUIT there, which would also run anyway, eg closing all tables and file handles in general.

Bye, Olaf.

 

[gguerra333]

On last thing I had to say..
To be honest I never used CANCEL either in the past to end a program and I probably have used RETURN more than anything but since it became a topic here and I threw it into some sample code I posted earlier in the thread (not consciously) and someone had issue with it then it became a debate so to speak. It has not been my practice to use it, if it is a forms based app then I use thisform.release and CLEAR EVENTS and it if is a regular procedure or simple linear program such as this example I simply use RETURN, but never anything at all. Please forgive the double negative.

I can see where CANCEL would signal the abnormal termination of an event in the ENGLISH language.. i.e. our event is canceled due to inclement weather. but CANCEL in VFP cancels the execution of program code and I would not rely on it to do any normal housekeeping such as closing files or releasing variables, that would be done explicitly prior to ending the program.

Just my two cents worth and no more said from me, I promise.. Bye

 

[Olaf Doschke]

Guerra,

nobody wants to silence you. I've also written the one or other unnecessary comment. It's surely enough said and you made an overall experienced expression, we don't judge old fashioned programming styles as bad, here. You're welcome.

Bye, Olaf.

PS: This is just my standard signature, in german forums I write "Tschüß" instead of "Bye", as it's a very local german (Hamburgean) way of both saying good bye and wishing you well. In the etymology of the word comes from latin "ad deum" (to god / god be with you) and transformed into adeus, adiós, adjüs, atschüss and was then shortened to Tschüß, as 'bye also is shortened from good bye and may even come from "god be by/with you".

I'm not very religious, but I still pay my church tax.

I sometimes get the feeling this is seen as offensive, as a way of saying "go away". It's not meant that way.

 

[JRB-Bldr]

Hamburgean ??

Is that a Big Mac or a Whopper?