i need to run my exe file but the form still shows in the background the main visual foxpro screen 2

[titoneon]

Hi Experts,
I have screen=off in my config.fpw, i added to the project, also i added the config to the folder where i have the exe file, but still shows the main visual foxpro screen with his own menu, what i am missing here, some suggestions will help.
VFP 9.0 SP2

Thanks a lot

 

[Dan Freeman]

You need to set the form's ShowWindow property to 2 (As Top Level Form) or it will default to being in Screen.

To be on the safe side, include your config.fpw file in your project ("Other" tab, under text files). That way you don't have to distribute it with the EXE.

 

[Mike Lewis]

Dan's right about setting the form's ShowWindow to 2. But I don't think that would explain why you are still seeing the main VFP screen.

Is it possible that you have some code in your startup routine that makes the screen visible again? For example, [tt]_SCREEN.Visible = .T.[/tt] Any code that you execute within the program will override what's in Config.FPW.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

The most obvious reason is youdidn't include the config.fpw file correctly in the project. It has to be under "Other Files" and included in the compilation. If you have created it as a new text file or added it to the text files section, it's excluded from comilatoin. Also a config.fpw sitting right beside an EXE is not automatically loaded, so it won't have an effect there, too.

See how it's done from faq184-6512, I'm writing a fpw file via STRTOFILE and add it to the project. It ends up in "Other Files" and is included in compilation into the EXE.

Bye, Olaf.

 

[titoneon]

Hi Guys,
I have made the changes as suggested(still the main visual foxpro is shown and open maximized) , i did not do what Olaf Mentioned in the link but i added the config.fpw and the rest you guys said, also in the form property showwindow i selected 2 (As Top Level Form), here is my startup.prg file, also i am including the config.fpw, which i added under "Other files" tab.

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
Application.Visible = .F.
_screen.windowstate=2
_screen.caption='S H O W  J O B S N U M B E R S '

Public goMyApp
goMyApp = Createobject('EMPTY')
* Folder Locations
*AddProperty(goMyApp, "FolderApp", 'C:\SEARCHJNO')   && b4 compiling, i  should change this to
&& ADDBS(justpath(sys(16,0))) to make things more && flexible
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')
Try
	Set Classlib To Addbs(goMyApp.FolderClass)+'_ssclasses' Additive
Catch
Endtry
Try
	Set Classlib To Addbs(goMyApp.FolderClass)+'_sandstorm36' Additive
Catch
Endtry
Try
	Set Classlib To Addbs(goMyApp.FolderClass)+'ssUltimate' Additive
Catch
Endtry
Try
	Set Classlib To Addbs(goMyApp.FolderClass)+'_calendar' Additive
Catch
Endtry
Try
	Set Classlib To Addbs(goMyApp.FolderClass)+'_agent' Additive
Catch
Endtry
Try
	Set Classlib To Addbs(goMyApp.FolderClass)+'_base' Additive
Catch
Endtry
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, addbs(goMyApp.FolderApp)\prgs\imgcapture.prg Additive
Catch
Endtry
Try
	Set Classlib To Home(2)+'Solutions\Solution' Additive
Catch
Endtry
Do Addbs(goMyApp.FolderApp)+'ss_support.app'
Public ssUltimate
ssUltimate = Createobject('EMPTY')
AddProperty(ssUltimate,'SkinsFolder',Addbs(Getenv("APPDATA")))
Application.Visible = .T.
_screen.WindowState = 2
Do Form Addbs(goMyApp.FolderApp)+'Forms\searchjob'
READ events

config.fpw
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
SECONDS = OFF

Any help is very appreciated
Thanks

 

[Mike Lewis]

_screen.windowstate=2

I think that's the problem. That line will override the SCREEN = OFF in your Config file.

When we said you should set your main form to be top-level, we meant the main form, not the outer VFP window. You need to remove the above line, then display your main form. Then set that form's WindowState to 2.

Mike






__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mike Lewis]

Just to add: A couple of other possible problems with your code:

- [tt]_screen.WindowState = 2[/tt] is present twice. You'll need to remove them both.

- You've also got [tt]Application.Visible = .T.[/tt] I don't know why you've got that. It would control the visibility of an automation server, which I assume is not relevant in this case. I suggest you remove it.

Also, the code you posted has a lot of stuff that is not relevant to the issue of the visibility of the outer window. When dealing with this kind of problem, it helps to strip out all the irrelevant stuff, and to focus on the minimum code you need to reproduce the problem. Not only will that make it easier for you to understand what's going on, it also makes life easier for people in the forum who are trying to help.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[titoneon]

Mike,
I don't understand what is going on, i just removed everything you told me, i also enable the property "always on top" in the form i want to be only shown, when running the exe file, the main visual foxpro windows always appears behind my form, i don't want the visual foxpro screen at all, i also set to "T" the desktop property for my form, the "showWindow property as 2" (top level form), windowState Property as 0(normal) and windowStyle =modeless.

Don't understand why the main visual foxpro still active and behind my form
Sorry for the whole code i pasted, i was in a hurry
Thanks a lot

 

[Olaf Doschke]

Aside of what Mike is saying and which is essential to your problem and most probably solving it already, also setting the _screen.caption is not doing any good, if you intend to not show it. Your main top level form should have the application name as it's caption.

A more important thing remaining: There is no point in putting every single SET CLASSLIB inside a TRY..CATCH..ENDTRY. If a classlib is missing in source code or within the executable, you swallow that error and as a result you get no error, but you also can't use classes from the missing classlibs, so this kind of error handling is not helping at all, you just don't see what's missing in the first place and things don't work for mysterious reasons, that would be obvious, if you at least would log these errors and let a user send you the error log for inspection.

Error handling is not about suppressing any technical message from end users by preventing any error to occur, error handling is about finding errors and their reson at development and test time and at least logging and perhaps also forwarding them to a bug tracking system at runtime.

You can stop the system message from appearing to users, as it doesn't help them, but error messages and line of error, program class, method and other informations are helpful to you as the developer or collegues or at least us to help fix the bugs still slipping through testing into production.

TRY CATCH was introduced later and can be used to catch simple expected errors, eg you add a routine PACKing your application database, then you may put a code looping all tables and PACKing them into a TRY block and in CATCH display a message to the user stating currently database maintenance fails due to tables still being used. in the FINALLY block close all tables. This would be a good use of catching and suppressing errors. In other places you want to know there is an error to get the info about missing components.

So overall what you need despite of the introduction of TRY..CATCH is a global error handler routine taking in some parameters as ERROR(), MESSAGE(), LINE(), PROGRAM() which itself also may get these detail infos by reading error information from an array created by AERROR() and logging that information together with perhaps variables saved by SAVE TO into a log file, or several, or a dbf. That error handler than may just display a general message to the user and quit the application. There is no reason to continue or retry, if you can't judge how fatal that would be, eg working on the wrong workarea, because the error having occured has switched that, may cause more harm than just quitting.

At least there is no point in doing an error free application which even doesn't give you any hints on what's missing, what errors occur and make the application not work correctly.

Bye, Olaf.

 

[Mike Lewis]

Looks like you need to do some creative debugging.

You could try this:

First, remove the Config.FPW completely. Instead, put [tt]_SCREEN.Visible = .F.[/tt] as the very first line of the program. Now, watch carefully as the program loads. What you should see is the outer window appearing, and then almost immediately it should disappear. That mean that that first line has executed. Keep watching. If the outer window suddenly appears again, it means you have some code somewhere that is making the screen visible.

So the next step is to identify that code. You could try single-stepping in the debugger, executing one line at a time until the window re-appears. Actually, I'm not sure if that's possible. Can you run the debugger while the main screen is invisible? I don't know. Give it a try.

Alternatively, you could quit the application at some early point in the code, say, just before creating the goMyApp object. If the screen re-appears before the application quits, that means the problem code is before that point. If not, move the quit down a bit, say, to the point where you are about to launch the main form. And so on. In that way, you might be able to narrow down the location of the offending code.

If, on the other hand, the screen correctly remains invisible the whole time, it means the problem is in the Config file. Off-hand, I can't see anything wrong with it. But you could try removing everything except the [tt]SCREEN=OFF[/tt], just to see if there is something wrong elsewhere in the file. If that doesn't change anything, it would suggest that the file is not being bound into the executable.

Perhaps you could try these suggestions and report back.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[titoneon]

Thanks a lot Olaf for the explanation, Mike i will report back asap
Thanks

 

[titoneon]

Mike,
removing all the stuff you mentioned in your earlier post, plus adding _SCREEN.Visible = .F. to the top of the startup file w/o removing the config file cause i know it was fine, now i run my exe file and i get the form i need just right in the center of the desktop w/o the main visual foxpro screen, so i guess it was a combination of removing those lines from previous post plus just the magic " _SCREEN.Visible = .F." line, it was simple but i could not figure that out.
Thanks a lot Dan, Olaf and Mike

 

[Mike Lewis]

w/o removing the config file cause i know it was fine

Well, no. The config file is not fine. What you have done to prove that the problem is caused by the config file.

Think about it. You've established that there is nothing in your application that is causing the screen to re-appear after you initially made it invisible. Therefore, it must be that the config file isn't working. Either there is something wrong with the file itself. Or - more likely - it wasn't being accessed by the executable.

I suspect that either the config wasn't being bound into the executable (perhaps because it was marked as "excluded" in the project), or the executable was somehow picking up the wrong config.

You could of course leave things as they stand. The only small problem is that the user will still see the outer window flash on the screen for a moment before it becomes invisible. This happens after your program loads but before it executes the first line of code. If you can accept that, that's fine.

Or you can spend just a bit more time getting to the bottom of it - having come this far. If nothing else, double-check that the correct config file is in your project, that it is not being excluded, and that there is no other config file that the executable might accidentally be picking up. You could also temporarily remove all the other lines from the file, just in case one of them is interfering with the SCREEN=OFF command (although I accept that this is unlikely).

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[titoneon]

Hi Mike,
The config.fpw file it is included in the project and i don't have in the directory where the exe file resides the config.fpw. yes i removed all the other lines you told me, in fact the form open correctly w/o even show the outer window flash on the screen for a moment, the only problem i have is, that i included a "wait windows at row, col[message ] nowait" searching for a part no that could be in so many tables, this take a litte bit to do it, so included the "wait windows" to make sure the users knows this is still processing but for some reason the wait windows does not display at all cause now it is not a main visual foxpro screen there and i have the only form i want to show as a "2- top-level form" under showWindow property, under the IDE i can see the Wait Windows even located at the right spot in my form but once the exe run the wait window does not show.
Do you have any suggestion ?

May be i should add a txtbox to the form and use the display there the values of lnI
the code below takes a little bit to process depending of the value of lnCount, so what about if enable a txtbox that display the values of lnI to lnCount, so the user could see this until the grid display the results ?

lnCount = ADIR(laFiles, ADDBS(lc_Path) + "*.dbf")
FOR lnI = 1 TO lnCount
  lcFile = FORCEPATH(laFiles(lnI, 1), lc_Path)
WAIT  WINDOWS AT 300,15  [WAIT WHILE PROCESSING PART NO = &lcpart_no    ] NOWAIT
   If UPPER(RIGHT(JUSTSTEM(lcFile),1))="A"
     Loop && Don't process this file
  ENDIF
  If vartype(part_no) = 'U'
       LOOP && Don't process this file
    ENDIF
   
If JUSTSTEM(lcFile) == TRANSFORM(INT(VAL(JUSTSTEM(lcFile)))) && returns true if c contains only digits     
     WAIT  WINDOWS AT 300,15  [WAIT WHILE PROCESSING PART NO = &lcpart_no    ] NOWAIT
  USE (lcFile) Alias Jobs In Select("Jobs")
  * Process Jobs
    Insert Into MyJobs Select  DISTINCT Job_No, Part_No, "   " From Jobs where part_no = LCPART_NO  
ELSE && for if Juststem(lcfile)
loop    
ENDIF && for  if Juststem(lcfile) 
ENDFOR

Thanks

 

[Olaf Doschke]

Well, you didn't follow Mikes advice, which wasn't to remove the suspicious lines, but to debug your code as it is, without the config.fpw file.

Anyway, now that you removed _screen.WindowState = 2 besides some other lines and kept the config.fpw, you also don't need the _screen.visable =.f., that's just the same thing screen=off does, only that line does it later than config.fpw can do it. That's why mike predicted a flashing, but only if you remove the config.fpw. This way you would have seen which line exactly shows the screen, and if there are more than that one line.

Anyway, the config.fpw was and is fine and you already are a few steps ahead, if the screen isn't caused to appear. Just remember: Screen=Off doesn't remove the screen, it just hides it. It's always there.

In regard to wait window: It's wait window, not wait windows, VFP is very forgiving, as it compiles that, too. I wonder if wait windows depend on _screen to be visible, as they are their own separate windows positioned in the upper right of the currently active form without any AT coordinates. Maybe just remove these coordinates, they will only fit for a certain positioning, which you may have had during development. Maybe it's there and you look at the wrong place, as your main form now is maximised and the wait window appears somewhere in the middle. Don't use any coordinates and it'll float up and right to the upper right corner, if there is room and displays within left and below the upper right corner - within the form - if the desktop has no place or the form is maximised. No need to give coordinates.

Indeed you have other means of showing progress easily and I'd actually prefer anything to the wait window. You could add a status bar to your form and show a text there, or display any progress indicator anywhere, you'll get that done. A shape you change in width can be a simple progress bar, for example.

Bye, Olaf.

 

[titoneon]

Thanks Olaf for the clarifications, it is really appreciated, remember i am still learning, thanks to all your advise, yes i know it is Wait Window, don't know why i typed Windows
so i can put a shape and make it to increase it is side to emulate a progress bar ?
can you give some example of how to do during the "for... endfor" ?
Thanks

 

[Mike Lewis]

I've just done a quick test. A Wait window will be visible even if _Screen is not visible. That's true regardless of whether the Wait Window has co-ordinates or not.

But what you are trying to do - A Wait window with a top-level form and no outer window - does not look like a good user interface. That's partly because you don't know where the user will place the form on the physical monitor, and the Wait window might be in the opposite corner, and not where the user's attention is focussed.

What I would do is to place a shape on the form. Make it about 10 points high (the height of a character in the default font), and initially give it a width of 0. Give it a dark colour. Now, as your process progresses, gradually increase the width of the shape until it reaches its maximum, which would be about three-quarters of the width of the form.

In other words, do something like this:

lnMaxWidth = 600       && max width of shape, in pixels
FOR lnI = 1 to lnMax   && start your main loop
  * Do your processing here

  * Display the progress
  THISFORM.shpProgress.Width = (lnI / lnMax) * lnMaxWidth
ENDFOR

You can improve the appearance of the progress shape by placing it in another shape to serve as a border. You could also place a label within the shape to show the percentage complete - [tt](lnI * 100) / lnMax[/tt]. But get the basics right first.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[titoneon]

Mike,
Thanks so much for the explanations and for the example, will be working on it

 

[Olaf Doschke]

Mike already came up with an example. It's simply setting the width, so what was your question about really? You have to define a maxwidth as yuor goal for 100% and compute the progress relative to that max width, and that's simply lnI / lknMax * Maxwidth, as Mike puts it.

Bye, Olaf.