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

when clicking on the exe file(vfp 9.0 spk2) it just blink and disapears

Status
Not open for further replies.

land_fla

MIS
Dec 19, 2016
7
0
0
US
Hi again,
What can cause this ?
when clicking on the exe file i just compiled( under vfp 9.0 spk2) it just blink and disapears
Thanks in advance

Of course if you need more detail, let me know, i just added a config file, where i have there, screen = off
 
Lets start with: Did the application Ever Work?

If so and now it is not, What Changed?

You might want to spend some time looking at the free, on-line VFP tutorial videos at:
Of particular interest might be the ones (Parts 1 through 6) named: Building a Simple Application

Good Luck,
JRB-Bldr
 
I guess you miss the Read Events line:

[pre]Do Yourform
Read Events
[/pre]
And in the Destroy event (Or you can use the Release event) you add

[pre]Clear Events[/pre]
 
land_fla said:
it just blink and disapears

The most likely reasoning is what Tore Bleken said.

Do you still see your.exe in task manager?

SCREEN=OFF in a config file hides the main _SCREEN, you then need a top level form to have something even just blinking shortly. Top level forms are never modal, even if you set them to be modal, so you need a READ EVENTS. When you test your application in the VFP9.exe IDE, then the IDE is keeping the process running, in the compiled version there's nothing to do anymore, which quits it.

Bye, Olaf.
 
Olaf is not quite right, you don't HAVE to have READ EVENTS. I don't use it.

A modal form is just that, modal, and stops the execution of a program file.

So my 'main' code would do a bunch of stuff; reading ini file, setting up environment
variables (some of which would be declared public, even though they would be public by
scope anyway) and then has (for example) a DO FORM INSTALL which kicks off the installation
routine and is MODAL - and the code stops there until the form is completed and then continues.


Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.
 
Griff, reread please.

a) top level forms are never modal
b) an application with SCREEN=OFF can't just have an in screen or in top level form, it has to have a top level form, thus a non modal form.

see
vfp help said:
Note that a top-level form is [highlight #FCE94F]always modeless[/highlight], regardless of the WindowType property setting.

Also see faq184-6512

Bye, Olaf.
 
About your idea, Griff,

once the INSTALL form is finished and the real application starts, you have to end this form, don't you? And then the main.prg code continues, when you have no read events in there you have to have it elsewhere, or you are bound to let the INSTALL form stay open. Since it's modal it's the only usable form. You have to tell more about how this works in the end.

Bye, Olaf.
 
You are right, when the INSTALL form finishes the application picks up from there, but you don't ever have to have a READ EVENTS.

After the INSTALL form completes, there might be a form to pick the database, to login, to present a menu so forth.





Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.
 
So your application switches from modal to other modal forms. That's not allowing any state with no modal form, why should that be preferable?

It's no big deal to have a READ EVENTS and have CLEAR EVENTS either in the Unload of the main form or in a menu item for quitting the application, though with the CLEAR EVENTS in unload you can also quit with QUIT. You can guide the user between modal and non modal states and in the end offer a better user experience. And you don't need to care for a stable state of always at minimum one visible modal form. There are many situations I like to fork, eg image processing having two image windows open to copy&paste from one to another, also in business apps, to use drag&drop from one to another form, to name just two cases, there are endless.

Bye, Olaf.
 
I didn't say it was PREFERABLE, just a fact, DO EVENTS is not mandatory, and the modal approach is what I am used to.

Different strokes, it's the beauty of VFP - don't have to use classes and think OOPs all the time, you can, but you
don't have to...

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.
 
READ EVENTS, mot DO EVENTs.

I don't see any way to go for a modal form, if you want to have an application not using _SCREEN. So this isn't something Ernesto (land_fla) can use keeping _SCREEN invisible. I tried that various ways with only setting it visible=.f., with setting a modal in-screen form desktop=.t. and some more, it doesn't work, for a single form application without the _screen as your application backrgound form holding the menu, when you really only want your own single form, I see no way to go without READ EVENTS.

Whatever works for you works for you, but in this special case doesn't help others to design their EXE correctly, so it would be nice, if you gave in and stop proposing a non working solution.

Bye, Olaf.
 
Olaf, I agree. You do need Read Events. Griff is only creating confusing, not helpful at all.
 
Oops (sic) READ EVENTS indeed.

He seems to have a non-working solution already...



Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.
 
To be fair Olaf, I have _screen = off in my config file, and the code, after a splash screen, I turn it on.

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.
 
Thanks for that fairness, it shows why you can work with a modal form. You can do the same using your own non modal top form (instead of _screen) and then start a modal form, but this way you don't have a SDI interface application, you have an MDI application with a main screen. An advantage of that architecture is having more control about the _screen looks and even have controls on it. You can also add controls on _SCREEN at runtime, but it's more convenient to design such a non modal top-level main form in the form/class designer.

The single READ EVENTS as solution and replacement for all the READ commands of earlier Foxpro applications is an advance, or the other way around I'd see it as a step backwards to need to do it the legacy way, mainly having a single path of actions to go through step by step.

Bye, Olaf.
 
Sorry tbleken,

I didn't mean to confuse you B-)

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.
 
Hello Guys,
Still when running the exe file, it shows momentarily(really fast) and close, when i look into the task manager under the process tab, the exe file, is not there
i do have in my main(startup.prg file) the Read events

the below code it is my startup.prg file
Code:
Set talk off
SET SYSMENU OFF
set sysmenu to
SET SAFETY OFF
set century on 
SET EXACT on
SET CPDIALOG OFF
Set Talk Off
Set Confirm Off
Set Century On
Set Echo Off
Set Date AMERICAN 
Set Console Off
Set Safety Off
SET EXCLUSIVE OFF
Set Deleted On
Set Autoincerror Off
Set Status Bar On
Set Exact On

*** Public Variables

Public goMyApp
goMyApp = Createobject('EMPTY')
Rand(-1)  

* Folder Locations
AddProperty(goMyApp, "FolderApp", Addbs(Justpath(Sys(16,0))))

AddProperty(goMyApp, "isEscKey", .F.)  && for escaping intensive loop via ESC key

AddProperty(goMyApp, "FolderClass", Addbs(goMyApp.FolderApp)+'Classes')

SET CLASSLIB TO   && Release all class library
Set Classlib To Addbs(goMyApp.FolderClass)+'_ssclasses' Additive
Set Classlib To Addbs(goMyApp.FolderClass)+'_sandstorm36' Additive
Set Classlib To Addbs(goMyApp.FolderClass)+'bbwin8tiles' Additive
Set Classlib To Addbs(goMyApp.FolderClass)+'ssUltimate' Additive
Set Classlib To Addbs(goMyApp.FolderClass)+'_calendar' Additive
Set Classlib To Addbs(goMyApp.FolderClass)+'_agent' Additive
Set Classlib To Addbs(goMyApp.FolderClass)+'_base' Additive

TRY    
	Set Path To Addbs(goMyApp.FolderApp)+'icons\combined', Addbs(goMyApp.FolderApp)+'icons\small',;
		addbs(goMyApp.FolderApp)+'reports', Addbs(goMyApp.FolderApp)+'classes' Additive
Catch
ENDTRY

TRY  
    Set Procedure To addbs(goMyApp.FolderApp)+'prgs\junlib.prg', addbs(goMyApp.FolderApp)+'prgs\ss2xlsgui.prg' Additive
Catch
Endtry

Try
	Set Classlib To Home(2)+'Solutions\Solution' Additive
Catch
Endtry

* This is mandatory, Path for ssUltimate library
Public ssUltimate
ssUltimate = Createobject('EMPTY')
AddProperty(ssUltimate,'SkinsFolder',Addbs(Getenv("APPDATA")))
_screen.visible = .t.
Do Form Addbs(goMyApp.FolderApp)+'Forms\searchitem'  
READ EVENTS

the Desktop property of the form is set to ".F."

The destroy property has this code below
CLOSE DATA ALL
Clear Events

The form Load property is as below
SET EXACT ON
SET SAFETY off
SET CENTURY on
SET CPDIALOG OFF
SET EXCLUSIVE off

the form Queryunload property as below
Close Databases All

showwindow=2 "as top level form

windowState = 0
WindowType = 0 Modeless

my config.fpw content as below

screen = off
TALK = OFF
CONFIRM = OFF
SAFETY = OFF
ESCAPE = OFF
RESOURCE = OFF
DATE = BRITISH
STATUS BAR = OFF
ECHO = OFF
CENTURY = ON
EXACT = ON
DELETED = ON
HOURS = 24

Still the exe blink for a moment and it is gone
Can any onyone point what could be wrong or missing
Thanks
Note: the form from inside VFP 9.0 ENV. runs perfectly
 
I don't see why it should not work, but just seeing the main.prg code is not knowing all, that might fail. It's totally clear you stay in the IDE without READ EVENTS.

Next step is to ensure what happens in which order. SET COVERAGE TO ADDBS(GETENV("TEMP"))+"yourapp.log" at the start of your main.prg and the run it. Every code running will have a line in this log and you can see how and where the EXE exits at the end of the log file.

Bye, Olaf.




 
Olaf,
I will give a try right now,(on what you just indicated) cause i am already frustrated.

you meant adding the SET COVERAGE TO ADDBS(GETENV("TEMP"))+"yourapp.log" and run it from the IDE ?

or run the exe having in the main.prg file the SET COVERAGE TO ADDBS(GETENV("TEMP"))+"yourapp.log" ?
Thanks

 
The code works in the IDE, you want to find out what differs in the EXE, compile it with the SET COVERAGE and then run the EXE.

Bye, Olaf.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top