×
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Contact US

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

FoxPro 9.0 - Build .exe

FoxPro 9.0 - Build .exe

FoxPro 9.0 - Build .exe

(OP)
Hi,
I don't know how to correctly create the installation file of the project, because if I create only an exe file (see picture) and replace it in the project, it no longer works correctly.


How should I create an installation file so that the user can just install the program and it works?

I tried this procedure and it doesn't work, I just keep getting a pjx file (picture 2)

In FoxPro, you can create an installation file using the "Setup Wizard" or "Save As" tool.

1.Launch the FoxPro program.
2.From the main menu, select "File" and then "Save As".
3.Choose "Setup" as the file type.
4.Enter a name for the installation file and the location where you want to save it.
5.Click on the "Save" button and then the "Setup Wizard" window will appear or the saving process will begin.
In the Setup Wizard, click on the "Next" button and select the files that you want to include in the installation file.
6.Click on the "Next" button and set up the installation options, such as the target folder or installation preferences.
7.Click on the "Next" button and create informational pages that will be displayed during the installation.
8. Click on the "Finish" button to create the installation file.
Note: It's important that you have write access to the location where you want to save the installation file.

This guide explains how to create an installation file in FoxPro that includes all necessary files, settings, and instructions for installation.

thank you for the advice

RE: FoxPro 9.0 - Build .exe

Forget about the Setup Wizard. It is out of date and never really worked well.

Instead, use a dedicated installation program. The most popular such program (in the VFP world) is Inno Setup. Download a copy from their website (it's free). Then read the documentation on the site. It looks a bit daunting at first, but it works extremely well.

An alternative would be the version of InstallShield Express that comes with VFP 9.0. You can install it from the VFP CD. To a large extent, this version is tailored to work with VFP.

There's plenty of help on line for both programs, or come back here if you have any specific questions.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

RE: FoxPro 9.0 - Build .exe

(OP)
Cool, thanks for the advice and reply, I'll try to look into it.

I would also like to ask, if I run the program in FoxPro, it works as I need, but if I only create an exe file (as I stated in picture number 1), then everything I need in the program no longer works.

you don't know what it could be? It would be enough for me to just create an .exe file and run it.
I am sending the project in the attachment for a better idea.

In the picture "Add new record" and then the "back" button works in FoxPro, when the .exe file is created and run, the program no longer works.
Note: When starting, you need to choose the path to the "Cduseky_v1.2" file, which is also in the zip.

Thank you very much for your help, it is important for me to get it working properly and to be able to share it with colleagues.

RE: FoxPro 9.0 - Build .exe

(OP)
I do this because first I have to create the correct .exe file for it to work for me and then I can create the installation file.
Unfortunately, after creating the .exe file, everything doesn't work properly for me and I don't know why.

RE: FoxPro 9.0 - Build .exe

I'm sorry, but I can't tell you why your program doesn't work. I would have to actually run the program and try to reproduce the problem, but I don't have enough information to do that. I see that you have uploaded the project file. Other people here might be willing to download and to try to debug it, but I'm not prepared to do that.

Also, I think you have two separate problems here. Re the question of the Setup Wizard, InstallShield, etc. This is necessary if you want to distribute your program to other users (who do not have VFP installed). These users will need to have copies of several runtime components, all of which need to be installed in specific directories and some of which need to be registered. That is what the Setup program does.

But if you are running the EXE on your own computer (the one you use to develop the application), none of that is necessary, as all the required components will already be present.

But that is separate from the second problem. If I have understood this right, you are saying that the program works correctly if run from within the IDE, but not if run as a stand-alone EXE on the same machine. There are several possible reasons for that, but without either examining the code or reproducing the problem, I have now way of knowing which one applies in this case.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

RE: FoxPro 9.0 - Build .exe

(OP)
It is OK. Anyway, thanks for the reply. smile2
Exactly as you write, the program works correctly if run from within the IDE, but not if run as a stand-alone EXE on the same machine.

I always create the .exe file the same way, but I can't figure out why it doesn't work properly as an .exe file when it works properly in the IDE. Most likely the problem is somewhere in the compilation of the file, but I've been sitting on it for two days and still can't figure it out.

RE: FoxPro 9.0 - Build .exe

The differences an EXE can have over running the main program in the IDE are manifold and can have to do with pathing, wrong setting of inclusion vs exclusion from the EXE and many more things.

From what you say I assume you think there is a build problem, a compilation failure or anything like that that makes the EXE fail. No, all code can compile perfectly and as you have ticked "Display error" and don't get errors showing in the build process, the problem is not code failing to build a correct executable.

As Mike already said it's hard work to find out what's to be done, it takes debugging sessions that could need long time and nobody here can be asked to do that of not voluntarily having the time to get into it.

It can be important to SET DEFAULT into the directory of the pjx or some subdirectory depending on how the project source code is organized regaring includes and relative paths, that make compiling from the wrong directory fail. And that's just one of many problems you could get into. Is it actually your own or did you inherit this or is it source code from a customer needing an improvement. Is there any project documentation in that case?

Chriss

RE: FoxPro 9.0 - Build .exe

(OP)
I understand, thank you for explaining, it just seemed to me that it couldn't be that difficult to solve, since when it works in the IDE, why doesn't the .exe file work even after compilation. I thought maybe I had to tick something or change something so that the .exe file behaves the same way as in the IDE.
Yes, the program was historically created by a colleague who no longer works with us and I am a complete novice in FOXPro, I program in C# and C++ and I am currently developing this program in another environment, but I need it to still work, so I am looking for a solution somewhere, who could help me with this and is still interested in these databases.
Thank you for your help

RE: FoxPro 9.0 - Build .exe

The simplest thing you could try is compile the project on the computer of your former collegue, because he might have copied some part of the VFP installation folder elsewhere. The form you show seems to be done with the form or even the application wizard of VFP and uses some classes from within the VFP installation folder - HOME().

And such things can be problematic as the installation folder usually is reeadonly and code you compile, especially with the recompile all option, would cause VFP to write into the system directory of program files, which is not allowed, usually.

IIRC in XP VFP was installed so that the users in the usergroup "computer main users" could write into HOME(), and that was before Windows UAC - user access control - was introduced.

There could be the root of your problem: No write access in HOME() and all subdirectories.

Chriss

RE: FoxPro 9.0 - Build .exe

(OP)
It's been a long time since this program was created. I was wondering what could be placed in the "HOME" folder but I couldn't find anything that would be needed to compile.
How did you try it, did it also work in the IDE?
Thanks for the advice

RE: FoxPro 9.0 - Build .exe

I just see it from the looks of the buttons.

Chriss

RE: FoxPro 9.0 - Build .exe

(OP)
I see. I also tried it as an administrator and also with no result. It is interesting that the other elements work, only this part does not work properly.

RE: FoxPro 9.0 - Build .exe

Could we just clarify one point:

On the machine(s) where the EXE doesn't work, is that always the same machine where it DOES work in the IDE? Or does the failure occur on some or all of the end-users' computers as well?

If it is the former case, it might be worth trying to build the program as an APP rather than an EXE. You would then run the APP from within the IDE (using either the DO command or from the Program menu). I'm not saying that would necessarily solve the problem, but it might help to narrow things down.

Unfortunately, that won't be an option on the end users' systems, as APPs always need the development environment.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

RE: FoxPro 9.0 - Build .exe

Running as an admin doesn't solve the problem of write access, UAC still redirects. You need to give yourself write permission into the directory HOME() shows.

Chriss

RE: FoxPro 9.0 - Build .exe

(OP)
Yes exactly. Same computer.
Anyway, I'll try elsewhere.

The end user installs this program, if I change something, I just copy the .exe file to them. They don't own FoxPro 9.0 so they wouldn't be able to open it.

RE: FoxPro 9.0 - Build .exe

That's not quite right. If they don't have FoxPro installed, they should still be able to run the EXE (assuming your setup program correctly installs the required runtime files). It is the APP which requires VFP to be installed.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

RE: FoxPro 9.0 - Build .exe

(OP)
Yes, it works for previous versions. I wouldn't look for the problem there, rather I still don't understand why the .exe file doesn't behave the same as in the IDE. I also create an .exe file for other applications that we use and I have no problem there.

RE: FoxPro 9.0 - Build .exe

(OP)
I found out that probably only two buttons, which I described above in the picture, do not work for me and that is "Add new record" and the program stops working, so there is probably a problem somewhere.

RE: FoxPro 9.0 - Build .exe

Is error handling established? If a button doesn't work, does it really just do nothing, or is there a message? If you have no error handling (ON ERROR ...) you get system error handling, which tells an error, but not where it happens, and - inappropriately - gives the user "Ignore" as one of the buttons to react, which makes it seem unimportant.

Anything that's not working correctly must be reported and addressed, if you really have just no reaction from the buttons, neither an error message nor does anything the button usallly should do, then that's hard to analyze and fix.

Because pathing may be an issue, it helps to know if that's set the same in IDE and EXE. To detect that you could add a menu item or button which tells you the default path by doing MESSAGEBOX(Sys(5)+Sys(2003)).

Chriss

RE: FoxPro 9.0 - Build .exe

(OP)
Introduction of errors, I did not find there.
When you press the button "New record" (picture, number 1 red), the button changes to "Save record" and next to "return" (picture, number 2 blue) at this moment the program in the .exe file no longer works. The program behaves as if it is still functional, it does not even stop responding, these two buttons do not respond, but they can be clicked. In the IDE this works.




I added the Messagebox to the source code, the path is always the same, both in the IDE and after creating the .exe file.

CODE --> FoxPro

*I press the add button
ELSE	&& click on new "new"
	this.Picture=LOWER(cCestaProgramu)+"\images\uloz.bmp"
	this.ToolTipText="Save new record"
	MESSAGEBOX(SYS(5)+SYS(2003))
	this.parent.cmdEdit.Picture=LOWER(cCestaProgramu)+"\images\krokzpet.bmp"
	this.parent.cmdEdit.ToolTipText="Vrátit záznam"
	RecPoz=RECNO()
	APPEND BLANK					&& we will add a record
	thisform.grid1.SetFocus 
	*thisform.grid1.Refresh 
	*thisform.Refresh()
*	RecPoz=RECNO()
	thisform.Tlacitka.SetAll ("enabled",.F.,"Commandbutton")
	this.parent.cmdEdit.Enabled=.T.
	this.Enabled= .T.
	thisform.combo1.Enabled=.T.
	thisform.combo2.Enabled=.F.
	thisform.command1.Enabled=.F.
	thisform.command2.Enabled=.F.
	thisform.command3.Enabled=.F.
	thisform.combo1.SetFocus	&& sets the cursor to the first field to be filled
	thisform.SetAll ("enabled",.F.,"Textbox")
ENDIF 

RE: FoxPro 9.0 - Build .exe

Hi,

The MESSAGEBOX(SYS(5)+SYS(2003)) isn't of any value here. It simply shows the drive and the path

You may want to add a simple ERROR handler to your main program SPOUSTECI_PROGRAM e.g. (from the Help file) and see which errors are thrown.

CODE -->

ON ERROR DO errHandler WITH ;

   ERROR( ), MESSAGE( ), MESSAGE(1), PROGRAM( ), LINENO( )

USE nodatabase  

ON ERROR  && Restores system error handler.



PROCEDURE errHandler

   PARAMETER merror, mess, mess1, mprog, mlineno

   CLEAR

   ? 'Error number: ' + LTRIM(STR(merror))

   ? 'Error message: ' + mess

   ? 'Line of code with error: ' + mess1

   ? 'Line number of error: ' + LTRIM(STR(mlineno))

   ? 'Program with error: ' + mprog

ENDPROC 

hth

MarK

RE: FoxPro 9.0 - Build .exe

(OP)
Hi,
sorry, I'm an amateur in this RDBMS.
In which part of the code in "spousteci_program.prg" should I insert this code?
I put in 2 parts and it says syntax error.

Thanks for the advice upsidedown

RE: FoxPro 9.0 - Build .exe

Hi,

You may want to put both parts before the PUBLIC statement. You have to remove of course the statement USE nodatabase. Sorry for misleading you

CODE -->

ON ERROR DO errHandler WITH ;

   ERROR( ), MESSAGE( ), MESSAGE(1), PROGRAM( ), LINENO( )

ON ERROR  && Restores system error handler.



PROCEDURE errHandler

   PARAMETER merror, mess, mess1, mprog, mlineno

   CLEAR

   ? 'Error number: ' + LTRIM(STR(merror))

   ? 'Error message: ' + mess

   ? 'Line of code with error: ' + mess1

   ? 'Line number of error: ' + LTRIM(STR(mlineno))

   ? 'Program with error: ' + mprog

ENDPROC 

hth

MarK

RE: FoxPro 9.0 - Build .exe

(OP)
I'm probably doing something wrong because it keeps throwing me a syntax error.
I pasted it here:



The ON ERROR DO errHandler WITH; ERROR( ), MESSAGE( ), MESSAGE(1), PROGRAM( ), LINENO( ) statement is a command in the FoxPro programming language that sets an error handler for the entire program. This statement sets that if an error occurs in the program, instead of the program ending, the "errHandler" procedure will be run with the parameters listed after the WITH. These parameters contain information about the error that occurred.

The PROCEDURE errHandler is a procedure that runs when an error occurs in the program. This procedure has several parameters: "merror", "mess", "mess1", "mprog" and "mlineno" which contain information about the error that occurred.

In this procedure, several actions are performed:

"CLEAR" clears all errors
Using the "?" command, information about the error is displayed: error number, error message, line of code with error, line number of error and program where the error occurred
ENDPROC ends the procedure
This code serves to record information about the error that occurred in the program, and thus helps in debugging and fixing errors.

RE: FoxPro 9.0 - Build .exe

Hi,

Delete the empty line

ON ERROR DO errHandler WITH ;
ERROR( ), MESSAGE( ), MESSAGE(1), PROGRAM( ), LINENO( )

hth

MarK

RE: FoxPro 9.0 - Build .exe

(OP)
Okay, I'll try.
Logically, I would implement this code like this:

Unfortunately, that doesn't work either.
thank you for your patience

RE: FoxPro 9.0 - Build .exe

(OP)
If I removed the space, the syntax error went away, but the program didn't run, it just compiled.
It immediately gave me a lot of errors.

RE: FoxPro 9.0 - Build .exe

Hi,

That should work. However make sure that there is no empty line between

... WITH ;
ERROR(), ...


hth

MarK

RE: FoxPro 9.0 - Build .exe

Quote:

The MESSAGEBOX(SYS(5)+SYS(2003)) isn't of any value here. It simply shows the drive and the path

Mark,

That's correct. But the point was that, when you get a difference between IDE and runtime, it's often caused by some sort of pathing issue. That's why Chris suggested the message box. We can now see that it is not relevant in this case, but it's always useful to check the pathing, if only to eliminate it.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

RE: FoxPro 9.0 - Build .exe

(OP)
I removed like this:

Unfortunately it doesn't work.

RE: FoxPro 9.0 - Build .exe

(OP)
Mike,
Yes thank you, I checked in the IDE and in the created EXE file, the paths match.
There will be no problem here.

RE: FoxPro 9.0 - Build .exe

Hi,

You may want to put

CODE -->

PROCEDURE errHandler

   PARAMETER merror, mess, mess1, mprog, mlineno

   CLEAR

   ? 'Error number: ' + LTRIM(STR(merror))

   ? 'Error message: ' + mess

   ? 'Line of code with error: ' + mess1

   ? 'Line number of error: ' + LTRIM(STR(mlineno))

   ? 'Program with error: ' + mprog

ENDPROC 

after you READ EVENTS

and put ON ERROR right before CLEAR EVENTS, in order to keep the error handler active during the whole program execution

hth

MarK

RE: FoxPro 9.0 - Build .exe

...

and a demo how ON ERROR works

CODE -->

PUBLIC goForm

goForm = CREATEOBJECT("MyForm")
goForm.Show()

READ EVENTS

ON ERROR DO errHandler WITH ;
   ERROR( ), MESSAGE( ), MESSAGE(1), PROGRAM( ), LINENO( )


CLOSE ALL
CLEAR ALL 

**********

PROCEDURE errHandler
   PARAMETER merror, mess, mess1, mprog, mlineno

   WAIT WINDOW + "Error number: " + ALLTRIM(STR(merror)) + " Error message: " + mess + CHR(13) ;
		+ " Line of code with error: " + mess1 + " Line number of error: " + ALLTRIM(STR(mlineno)) + CHR(13) ;
		+ " Program with error: " + mprog
ENDPROC 

DEFINE CLASS MyForm as Form
	Width = 540
	Height = 360
	MinWidth = This.Width
	MinHeight = This.Height
	MaxWidth = This.Width
	Caption = "Sorting data in grid"
	AutoCenter = .T.
	ShowTips = .T.
	Themes = .F.


	ADD OBJECT grdNames as grdBase WITH ;
		RecordSource = "csrNames"
		
		PROCEDURE grdNames.Init()
			WITH This
				.Column1.Header1.Caption = "N°"
				.Column2.Header1.Caption = "Name"
				.Column3.Header1.Caption = "Age"
				.Column4.Header1.Caption = "G°"
				.Column5.Header1.Caption = "City"
				
			ENDWITH 
			
		ENDPROC 
		
		PROCEDURE grdNames.Refresh()
			LOCAL lcDBClick as String, lcClick as String
			
			lcDBClick = "DoubleClick header to reset order"
			lcClick = "Click header to sort by "
			
			DODEFAULT()

			WITH This
				.Column1.Header1.ToolTipText = IIF(ORDER() = "TNUMBER", lcDBClick, lcClick + "Number")
				.Column2.Header1.ToolTipText = IIF(ORDER() = "TNAME", lcDBClick, lcClick + "Name")
				.Column3.Header1.ToolTipText = IIF(ORDER() = "TAGE", lcDBClick, lcClick + "Age")
				.Column4.Header1.ToolTipText = "Sort by Gender not available"
				.Column5.Header1.ToolTipText = IIF(ORDER() = "TCITY", lcDBClick, lcClick + "City")
				
			ENDWITH 
		
		ENDPROC 
	
	PROCEDURE Load()
		CREATE CURSOR csrNames (iRNumber I,cName C(20), iAge I, cGender C(1), cCity C(20))
		
			INSERT INTO csrNames VALUES (3,'Sahra', 31, "F", "Bruxelles")
			INSERT INTO csrNames VALUES (4,'Jeoffrey', 20, "M", "Paris")
			INSERT INTO csrNames VALUES (6,'Jenny', 53, "F", "Den Haag")
			INSERT INTO csrNames VALUES (1,'Toni', 44, "M", "Rome")
			INSERT INTO csrNames VALUES (2,'Sophie', 76, "F", "Berlin")
			INSERT INTO csrNames VALUES (7,'Jeremy', 67, "M", "New York")
			INSERT INTO csrNames VALUES (8,'John', 19, "M", "Chicago")
			INSERT INTO csrNames VALUES (9,'Marie-Josée', 28, "F", "Quebec")
			INSERT INTO csrNames VALUES (10,'Karen', 62, "F", "Toronto")
			INSERT INTO csrNames VALUES (11,'Abi', 56, "M", "Zurich")
			INSERT INTO csrNames VALUES (12,'Bernhard', 42, "M", "Basel")
			INSERT INTO csrNames VALUES (13,'Christiane', 26, "F", "Marseille")
			INSERT INTO csrNames VALUES (14,'Doris', 29, "F", "Munich")
			INSERT INTO csrNames VALUES (15,'Fred', 58, "M", "Wien")
			INSERT INTO csrNames VALUES (16,'Georges', 40, "M", "Budapest")
			INSERT INTO csrNames VALUES (17,'Juanita', 36, "F", "Mexico")
			INSERT INTO csrNames VALUES (18,'Jhemp', 52, "M", "Luxembourg")
			INSERT INTO csrNames VALUES (19,'Jan', 57, "M", "Amsterdam")
			INSERT INTO csrNames VALUES (20,'Henrietta', 41, "F", "Baton Rouge")
			INSERT INTO csrNames VALUES (5,'Mark', 54, "M", "Bern")
			
		INDEX on iRNumber TAG TNumber
		INDEX on cName TAG TName
		INDEX on iAge TAG TAge
		INDEX on cCity TAG TCity
		
		SET ORDER TO
		
		LOCATE
		 
	ENDPROC

	PROCEDURE Init()
		DODEFAULT() 
		This.DoBinds()
		
	ENDPROC
	
	PROCEDURE DoBinds()
		LOCAL loCol, loObj

		FOR EACH loCol IN This.grdNames.Columns
			IF loCol.BaseClass = "Column"
				UNBINDEVENTS(loCol)
				BINDEVENT(loCol,"MouseMove", This,"GetColumnToolTipText")
			ENDIF 
						
			FOR EACH loObj IN loCol.Objects
				IF loObj.Baseclass == "Header"
					UNBINDEVENTS(loObj)
					BINDEVENT(loObj,"Click",This,"HeaderClick")
					BINDEVENT(loObj,"DblClick",This,"HeaderTwiceClick")
					BINDEVENT(loObj,"MouseMove", This,"GetHeaderToolTipText")

				ENDIF
			NEXT 
		NEXT
		
	ENDPROC

	PROCEDURE HeaderClick()
		LOCAL ARRAY laEvents[1]
		LOCAL lcOrderBy, loObject
		
		AEVENTS(laEvents, 0)

*!*			= MESSAGEBOX("Clicked: " + SYS(1272, laEvents[1]), 64, "Clicked Object", 10000)
			
		loObject = laEvents[1]

		lcOrderBy = SUBSTR(RIGHT(SYS(1272, loObject),9),1,1)

		IF INLIST(lcOrderBy, "1", "2", "3", "5")
			WITH This.grdNames
				.SetAll("FontBold", .F., "Header")
				.SetAll("FontItalic", .F., "Header")
				.SetAll("BackColor", RGB(228, 228, 228), "Header")
			ENDWITH 

			WITH loObject
				.FontBold = .T.
				.FontItalic = .T.
				.Backcolor = RGB(0, 201, 201)
			ENDWITH 
		ENDIF 

		DO CASE 
			CASE lcOrderBy = "1"
				SET ORDER TO TNumber
					
			CASE lcOrderBy = "2"
				SET ORDER TO TName
					
			CASE lcOrderBy = "3"
				SET ORDER TO TAge
				
			CASE lcOrderBy = "4"
				= MESSAGEBOX("Sorting by Gender is not available", 64, "Setting Order", 2000)

			CASE lcOrderBy = "5"
				SET ORDER TO TCity

			OTHERWISE
				= MESSAGEBOX("Call developper", 16, "Setting Order", 5000)

		ENDCASE

		LOCATE
		 
		This.Refresh()
		
	ENDPROC

	PROCEDURE HeaderTwiceClick()
			WITH This.grdNames
				.SetAll("FontBold", .F., "Header")
				.SetAll("FontItalic", .F., "Header")
				.SetAll("BackColor", RGB(228, 228, 228), "Header")
			ENDWITH 
			
			SET ORDER TO
			LOCATE
			This.Refresh()

	ENDPROC 

	PROCEDURE GetHeaderToolTipText(nButton, nShift, nXCoord, nYCoord)
		LOCAL laEvents[1]
		LOCAL loObject
		
		AEVENTS(laEvents,0)
		
		loObject = laEvents[1]
		
		This.grdNamess.cToolTipText = loObject.ToolTipText 
		
*!*			throws an error - should read This.grdNames.cToolTipText with one "s" only
*!*			you may want to correct the typo and run the program again
		
	ENDPROC
	
*!*	The procedure below AVOIDS the TTT to show when the mouse is hovering over columns	
	
	PROCEDURE GetColumnToolTipText(nButton, nShift, nXCoord, nYCoord)
*!*			LOCAL laEvents[1]
*!*			LOCAL loObject
*!*			
*!*			AEVENTS(laEvents,0)
*!*			
*!*			loObject = laEvents[1]
*!*			
*!*			This.grdNames.cToolTipText = loObject.Name

		This.grdNames.cToolTipText = ""
		
	ENDPROC
	
	PROCEDURE Destroy()
		ThisForm.Release()
		ON ERROR  && Restores system error handler.
		CLEAR EVENTS

	ENDPROC
ENDDEFINE 

**********

DEFINE CLASS grdBase as Grid 
	cToolTipText = ""

	Top = 6
	Left = 6
	Width = 540 - 12
	Height = 360 - 12
	ReadOnly = .T.
	Anchor = 15
	BackColor = RGB(0, 246, 246)
	ColumnCount = -1
	
	PROCEDURE ToolTipText_Access()
		RETURN This.cToolTipText
	ENDPROC

ENDDEFINE 

********** 

hth

MarK

RE: FoxPro 9.0 - Build .exe

Mark, you are wrong in that MESSAGEBOX(SYS(5)+SYS(2003)) aka the current path is of no value.

It can make a difference in finding files or not, all files that are outside of the EXE like DBFs and more.
And it is very common to set the default path in the main program and make it the path of the EXE, which also seems to be the case here.

But if you make that Justpath(sys(16)) and your main program is in a subfolder of the project the path in IDE And EXE can differ exactly because of that and be the reason an application works in the ID and not as EXE. I've seen this very often. Even when you then also SET PATH to a list of paths, especially realtive paths, all depends in the correct default path stting to find everything necessary.

MajklPan, can you look for the usage of SYS(16) in the code? You can make use of the code references tool for that and search for SYS(16) throughout all code in the project. I would look for it in the main program of the project first.

Chriss

RE: FoxPro 9.0 - Build .exe

(OP)
mjcmkrsr,
Thanks for the example given, I ran it and it shows me the same errors as I gave the image above.
That doesn't tell me anything is wrong.
-----------------------------------------------------------------
Chris,
In the main run of the program I found only SYS(16) here:

Then in the whole program I found here:


RE: FoxPro 9.0 - Build .exe

From the code references search result, I see your main program is in a subfolder PROG. The EXE you build will be in the parent directory, though, and this means cCestaProgramu will differ in IDE and EXE. And it will be false in the EXE.

In the next line already, that means you find the GPT_Memo.mem file or not. And that means some variables will be set or not, that explains a lot...

Put in a MESSAGEBOX(SYS(16)+chr(13)+chr(10)+cCestaProgramu) right after cCestaProgramu is set.

The value of cCestaProgramu should always be the location of the EXE (or in the IDE the HomeDir of the PJX). And this expression using RAT('\',SYS(16),2) cuts off two \ from SYS(16), which is correct in the IDE, but not in the EXE. You should use this, instead:

CODE

IF _VFP.StartMode=0
   cCestaProgramu = JustPath(JustPath(SYS(16))
ELSE
   cCestaProgramu = JustPath(SYS(16))
ENDIF 

You could always use JUstpath(sys(16)), if your main program would be in the same folder as the PJX. I'd not move it there now, though, as it might depend on being in the same folder as other PRGs, so it could mean refactoring work to get the PRG working if you move it.

I bet you, your former colleague always adjusted the RAT() expression to remove only one backslash in the EXE version and two backslashes in the IDE. But if you have no documentation about this necessary adjustment you fail to get a working EXE.

Chriss

RE: FoxPro 9.0 - Build .exe

BY the way, what does the comment mean?

Chriss

RE: FoxPro 9.0 - Build .exe

Hi,

Quote:


Thanks for the example given, I ran it and it shows me the same errors as I gave the image above.
That doesn't tell me anything is wrong.

Hard to believe. If you hover with the mouse over the headers of the grid the error handler should open a WAIT WINDOW in the upper right corner of your screen with the error messages.

hth

MarK

RE: FoxPro 9.0 - Build .exe

You put ON ERROR right after you set ON ERROR DO errHandler WITH...

That's nonsense.

You want the error handler to be set. So don't unset it right in the next line.

If you don't understand what ON ERROR sets, then please press F1 and read a little about it, it's all documented, the help has a full reference of every command and function, all classes and all their methods and events, so you also find a chapter about ON ERROR.

You're saying "In case an error happens, call errHandler with some parameters" in one line, and in the next line you say: "In case an error happens do the default system error handling". As a result of that, what do you get? Of course, you get the system error handling, that's not what you wanted. Setting back ON ERROR to nothing can be done later when you exit from the application, not right in the next line.

You just established Mark's error handling for one line of code and then reverted to the system error handling. That's not what Mark told you to do.

Chriss

RE: FoxPro 9.0 - Build .exe

(OP)
Chris,
Yes, exactly as you write, I always had to copy the exe file to the progs folder in order to run the application.
After inserting MESSAGEBOX here:

I thought it would be related to the GPT_Memo.mem file, it would make sense.

I see, thanks for the explanation.
Most likely, he just edited the RAT() exe file when creating it, as you write.
So you suggest this code:

CODE --> foxpro

IF _VFP.StartMode=0
   cCestaProgramu = JustPath(JustPath(SYS(16))
ELSE
   cCestaProgramu = JustPath(SYS(16))
ENDIF 
Insert location:

CODE --> foxpro

cCestaProgramu=LEFT(SYS(16),RAT(SYS(16),2)-1) 
Or after that.

VFP is a very complicated database relational environment bigsmile

RE: FoxPro 9.0 - Build .exe

(OP)

Quote (Chris)

BY the way, what does the comment mean?
Returns the name of the executed file

RE: FoxPro 9.0 - Build .exe

Just use that instead of the old cCestaProgramu=LEFT(SYS(16),RAT(SYS(16),2)-1). This is obsolete. The expression with LEFT up to the position of a last or next to last backslash is just a complicated way of doing what the inbuilt JUSTPATH function does. And as JUSTPATH removes a trailing backslash calling it repeatedly removes as many directory levels as necessary, one more for the IDE than for the EXE.

And you see, SYS(16) returns the name of the main program (precisely its FXP) when run in the IDE. And that is one directory deeper than the EXE, which is returned when running SYS(16) in the built EXE. Then VFP makes no fuss about where the actual PRG or FXP that executes right now was located, it just takes the EXE path for whatever PRG or class method is inside the EXE. Thus you have the problem this differs in IDE and EXE.

There are more speaking things than SYS() functions, by the way, not only on this topic:
In general PROGRAM() is the current program, but IIRC that never gives you a path just the PRG name or method/event name.
You can use _vfp.activeproject.HomeDir to get the directory of the PJX when running in the IDE - with a little catch, though: If you open more than one PJX in the IDE the one you start may not be the active project and so you get the HomeDir of another project.
And the third thing in that category is _vfp.servername. At runtime, it's the path and file name of your EXE. But within the IDE that will be HOME()+"vfp9.exe", which is not helpful, of course.

None of that is always available, too, In the EXE you don't have _vfp.activeproject, as that's only a property of the IDE. And even what is available in both situations is not the same in IDE and EXE. One thing is workable: If you move the main program into the same folder as the PJX/EXE, then JUSTPATH(SYS(16)) becomes universal for IDE and EXE within the main program.

So, in short, it's more complicated than it should be. You could also program in a way you expect the current/default path to be okay already and do nothing. That way you allow control of your EXE default path from outside, as the directory you set in a shortcut (.lnk) file executing your EXE can determine what directory is the default. On the other hand that's maybe something you actually don't want to be controllable from outside. Sys(16) is the right thing to use in the aspect that it clearly returns what currently executes, it's just that it makes a difference in IDE and EXE. That means you have to handle it depending on what state you're running in, which you get from _vfp.startmode.

And why all the fuss about the current directory anyway? Well, others may just use SET PATH and push in any paths you could find something into it. I like to have a movable base directory everything else is derived from with relative paths, and the one typical base directory you pick is the location of the EXE. Many files like local configuration or reports you want users to be able to modify or local data and of course also DLLs should be in the same dir or in subdirectories of the EXE. So the EXE path is of major interest.

It's a topic I also don't remember needing to care much for when I developed C and C++, but maybe also because you typically do stuff that has very little to do with any external file. Instead, you often work with stdin/stdout/stderr streams, or even when programming something with ODBC you rely on a DSN configuring anything correctly, that may have to do with pathing like the location of DBFs or an Access database.

Chriss

RE: FoxPro 9.0 - Build .exe

(OP)
Thanks for the explanation, I hope I got it right with my broken English.
That's what I read This code checks if the application is running in "StartMode" (variable _VFP.StartMode). If it is running in mode 0 (meaning the application was launched using a standard launcher file), it uses the JustPath() function twice on the variable SYS(16), which contains the path to the current launcher file. This gets the path to the directory in which the launcher file is located. If the application is not running in mode 0, it uses the JustPath() function once on the variable SYS(16) and this gets the path to the current launcher file. The result is saved in the variable cCestaProgramu.
So I tried replacing this path with:

This is how I compiled the file, created an .exe file and put it in the "Progs" folder. When starting the program, it immediately prints a message:

It works in the IDE.

Sorry if I misunderstood, I'm really an amateur at this. Thank you for your patience.

EDIT:
If I placed the code as shown in the image, the exe file started without error, but behaves the same as in the beginning. Two buttons do not work.

RE: FoxPro 9.0 - Build .exe

The second image is how you have it now?

You do compute cCestaProgramu in the old way there, at the bottom. No, this should not be done, this is getting the wrong path in the EXE, it only worksin the IDE.

You seem to have problems in the values that are loaded from GPT-memo.mem, but that's just guesswork. The only thing that will bring you forward is establishing error handling correctly, which you didn't manage so far.

The error handling has to be established as one of the first steps, so the ON ERROR line belongs to the top lines of your program.

So do two things:

Put the PROCEDURE errHandler code Mark gave you at the end of your main program.
Put this line at the top:

CODE

ON ERROR DO errHandler WITH ERROR( ), MESSAGE( ), MESSAGE(1), PROGRAM( ), LINENO( ) 

Chriss

RE: FoxPro 9.0 - Build .exe

Here's a slightly better version of Marks erorhandling:

CODE

PROCEDURE errHandler
   LPARAMETERS tnError, tcMess, tcMess1, tcProg, tnLineno

   _screen.visible = .T.
   Activate Screen
   Clear

   ? 'Error number: ' + LTRIM(STR(tnError))
   ? 'Error message: ' + tcMess
   ? 'Line of code with error: ' + tcMess1
   ? 'Line number of error: ' + LTRIM(STR(tnLineno))
   ? 'Program with error: ' + tcProg

ENDPROC 

This just assures a) the _Screen is visible, b) it is activated and cleared before outputting the error information with simple ? commands. There are tons of options you can add to this. First AERRR() will give you an array of more error informations than you can get from the ON ERROR parameters, you could show this in a messagebox instead, which would just be a minor change, but allows you to specif messagebox button as response. You could put SUSPEND at the end of it so you can start debugging when an error happens. You could store the error information into a log file, etc.

But for the start, the essential improvement on the usual system error is that you will get the line number and the program that errored. You only know that for the usual system error as aftermath, if you'd have this error in the IDE and have the suspend button, that's not available in the EXE.

Chriss

RE: FoxPro 9.0 - Build .exe

One thing to teach you that's best put into a separate post:

MEM files, what are they? In short a dump of all memory variables, which you then can restore.

It seems your former colleague used them to load important information into a bulkload of public variables. This is bad style programming, actually, but what you currently have to deal with. The problem you have with MEM files is unless you know what command was used to create it, you don't know what exactly is in them, as such files are binary. Embedded inside the binary gibberish you'll see, if you open a mem file in notepad (or notepad+) will be variable names, and their valules. Numeric variables, for example, will have an 8 byte long float value after the name, I think. It's not documented how exactly mem files are structured, I just know they are not compatible in all VFP versions, which is another reason they are bad style to save states you need to restore later. It is simple solution to SAVE and RESTORE, that's out of question, it's taking more code to establish a DBF or INI for keeping config data, but it has big advantages about managing data in them, or even editing them without having code access, especially ini text files.

So how do you find out what's in a MEM? Besides loading it into a text editor to see variable names, which leaves you with enough guesswork to get even that wrong, as readable portions can be variable names or variable values. the only other viable way would be to make a before/after comparison and see which variables exist after a RESTORE that didn't exist beforehand. But also, which existing variable values have changed by the restore, as that can also happen.

And how do you know all currently used variable names? When using LIST MEMORY TO FILE vars.txt you get a readable variable dump.
So do this:
Instead of just doing RESTORE FROM (cCestaProgramu)+"\GPT_Memo.mem" ADDITIVE do this:

LIST MEMORY TO FILE variables1.txt
RESTORE FROM (cCestaProgramu)+"\GPT_Memo.mem" ADDITIVE
LIST MEMORY TO FILE variables2.txt

And then compare the two files variable1.txt and variables2.txt to see what came out of the GPT_Memo.mem file. And once you know that you may be able to fix it by changing variables and creating a fixed GPT_Memo.mem file from the changed variable values. It's your only fast path to get a mem file correct.

In the long run, I'd store whats configuration in a DBF or an INI, so it's easy to read and modify even without having VFP at hand.

Chriss

RE: FoxPro 9.0 - Build .exe

One last request: Please, don't post screenshots of code, post the code itself. It's utterly dificult if we need to post a code change, to first type the code in the image that cold just be there as code itself. I dont know why you do this at all, as it needs much more steps to create an image and embed it into a post, instead of just copy&pasting code.

Chriss

RE: FoxPro 9.0 - Build .exe

(OP)
Thank you for the explanation.
I was just wondering what the GPT_memo.mem file contains and why it is created, or I think it could just be the result of the program not working.
It is a file that contains memo fields (areas for long texts) used in FoxPro tables. Memo fields allow storing large amounts of text or binary data in one field in a table. These files are typically associated with FoxPro tables and can be used to store notes, comments, or other long text data.

Can you please look at the file I sent in attachments? Can be opened in a text editor.

I followed your instructions. I still can't get the program to run.
Sorry for the pictures, I'll post them as code. Thank you for your patience.

RE: FoxPro 9.0 - Build .exe

Have you at least established the error handling? Because that would tell you (and in turn us) in which line of your code you have the error "Function argument value, type or count is invalid." In itself that error won't tell you where to mend what, but if you know in which line, that boils down the possibilities very much, usually.

I don't know what makes you still hesitate, maybe I should give you a bigger motivation: If you finally establish error handling, that will help a lot not only about this one problem you have right now, but about any error. If a build does not show errors, that's no reason there are no errors, as you saw for yourself.

We wouldn't have to guess where maybe problems are, we would have an actual known point of failure to start looking.

I can point out a whole article about the topic of error handling. That will lead you astray even more than just establishing what we already gave to you, which is sufficient to get the necessary knowledge. The code alone won't help us. It's not a compilation problem, it's a problem that only shows at runtime. We already know that much.

So here it is, if you can't establish error handling by our advice, maybe a whole article will give you a better insight into it:
https://doughennig.com/papers/Pub/errorh.pdf

Chriss

RE: FoxPro 9.0 - Build .exe

And yes, please post code and not an image or an attachment of it.

Chriss

RE: FoxPro 9.0 - Build .exe

(OP)
I see, thanks for the explanation. Please respect that I am an amateur at this. I was tasked with solving this problem and I'm glad this forum is active and the people here are helpful.
Anyway, I studied and implemented it, your instructions. When starting the IDE it gave me the following errors:

When creating an exe file and copying it to the progs folder, it throws the following errors.
Is this correct what you mentioned?


Thanks for your advice.

RE: FoxPro 9.0 - Build .exe

Now you have some more information. And it would be even more helpful, if you then follow that information. And, for example, look into the line which the error handler reported.

I see that you put your EXE into the PROGS subfolder. That's wrong, an EXE should always be built into the same folder as the PJX. That's not working out because now all your relative paths changed. You might have done that, as I told you that it's best to have main program and EXE in the same folder. Yet I also told you that doing that would right now possibly cause more pain than relief. And if you move something, then you move the main program into the folder of PJX and EXE, not the other way around. But don't do that now. The code using JUSTPATH twice for the IDE case and only once for the EXE case fixes that problem without moving around anything. Moving around files changes location of anything else in relation to that, and that can introduce more problems than you already have. Don't do that. Only do that in the long run and when you're ready to refactor code about pathing. Not now. You're alrady bogged down enough by the errors you already have.

Now about the errors:
As the first error points out a missing variable koncind, the logical thing to do is to look, whether this variable is declared and set in code previous to that line, or not. If there is no variable declaration LOCAL koncind and also no line that sets koncind to something, this code will of course error.

Here's a difference between compilation of C/C++/C# or VFP code: Foxpro doesn't care whether variables are declared or set in code, you can use code that has an uninitialized variable and the compiler will build that without reporting a compile error. One reason for it is, that there always are ways the compiler can't see or tell, that such variables will exist at the time of execution. One way this could become true is when a MEM file is restored. If the variable koncind is stored inside your GPT_Memo.mem file but this file is not found and thus a RESTORE does not happen all code that needs variables from GPT_Memo.mem fails, of course. What's bad about the IF FILE construct is that it avoids an error if GPT_Memo.mem is not found, but preventing that error, it runs into all kind of problems as the variables and their values are all not present.

We have had that in focus, already, didn't we? The essential variable that needs to be correct so GPT_Memo.mem is found is cCestaProgramu, that needs to have the path to the EXE, and the GPT_Memo.mem file has to be in the same directory, too. Since you moved the EXE inside PROGS, you now don't have GPT_Memo.mem in that folder. You're making things worse than they were.

I had a long explanation why a base path is important so all reltive paths are correct. And now you move the EXE and make all relative paths invalid that way. Please, think about the consequences of what you're doing. Not only that you move the EXE instead of the PR, I only told you to mmove the PRG and I told that in Conditionl I, in conjunctive. It's something you would do in a new project, or once you know more about the whole project. It's not iportant to only need one line of code instead of an IF with two branches. What's implortant is that you get the actual problems fixed, don't intriduce further problems.

----------------------------

The next step is to find out how koncind should be set, where it is declared and assigned its value, whether that is part of code before that erroring line or whether it would usually come from the RESTORE of GPT_Memo.mem, if that mem file is found.

Regarding the second error, it would obviously now be helpful to know the code of line 69 in spousteci_program. Then this will hint on what else to look for. Wouldn't it be logical to look into the line the error handler reports? And show it to us? Why did I stress out that knowing the location of an error is so valuable? Because then you can lookup the code.

I know you attached that prg but so you know it: While the forum scans every attachment for viruses, I don't download everything anybody here attaches, when I can avoid it, even though I also have my own antivirus protection in place, too. It's an unnecessary risk. Also, since you made some changes, I can't be sure what line 69 will be right now in your changed code.

You could really just concentrate on the essential line to post it here. Even if you're an amateur at VFP, you said you're a developer, please put just a little thought into what could be useful for us. We can't look over your shoulder, so if the error points out line 69. What do you do as a developer? You look into line 69. And then you let us look into it.

Chriss

RE: FoxPro 9.0 - Build .exe

One more thing on top of all of that, don't start an EXE with DO,
start it as an end user would also start it, double clicking on it in a file explorer or using a shortcut lnk to it.

If you DO an EXE that keeps _vfp.startmode at 0, the IDE mode. The normal mode for an EXE is 4, if you start it as an end user starts it, outside of the IDE.

Chriss

RE: FoxPro 9.0 - Build .exe

(OP)
Thanks, unfortunately it doesn't have a solution for me, I'm not familiar with it and all the things I know about programming almost don't work here.

You were right, the program works if I don't copy it to the progs folder, because as you wrote, it doesn't find the path to GPT_MEMO.mem.

I just have a problem with the fact that we have an installation file that the end user installs and then just copies the .exe file into the progs folder, because I didn't know how to create an installation. I know it's not right, but it worked for me until now, and I was giving them the adjustments I made in VFP. (Just simple, standard changes, protocol name change, etc.)

I would probably have to create a new installation, right?
Because after installing an older version, where these modifications were not present, it looks like this:

exe file is currently located in the progs folder.

But really, the program runs and the buttons also work.
The program doesn't even print any errors.
Now just create the installation process.

RE: FoxPro 9.0 - Build .exe

The code as you have it will need the EXE outside of the progs folder.

If the EXE is in the prog folder GPT_memo.mem would need to be in the PROG filder too, and all kind of location adjustments would likely be necessary for the EXE to find things. So the previous EXE would need to be based on previous code that used cCestaPRogramu+"\..\GPT_MEMo.mem". All these kinds of paths must work, there only is SET PATH that would make VFP (also the EXE) look into other locations, if a file is not found in the place first searched.

But I don't see from here, whether SET PATH has such paths so files not at the location to be expected b the code are found nevertheless.

I would not care what old code worked, I would fix this problem from the ground up and make it right. And for that, the EXE should be in the folder abovve PROGS, and the installation should not need the Progs subfolder at all, as the EXE has all progs embeddded and built into the EXE, at least that's the default for inclusion/exclusion for project items that are PRG. It seems odd, that your working installations are like that.

One question comes up:: Are you having a GPT_MEMo.mem file on that levvel AND within Progs? Maybe the old expression is intentionally computing different directories for IDE and EXE so different mem files are read and set variables in different ways for EXE and IDE mode.

Chriss

RE: FoxPro 9.0 - Build .exe

Quote (MajklPan)

...it worked for me until now...

You mean you created a new EXE and application users copied it into their installation folder and that worked?

I had the impression this is your get-go start of taking over this project and this is your initial problems. If it worked, can you go back to an earlier project state when it still worked and analyze the change that made this defunct? In fact, that's your only really viable option.

If you have a working installation of an older version, it would also surely help to get the mem file and perhaps the whole installation out of it to see what's in there that might have changed.

One thing is clear: A build without error of a VFP project is not telling you don't get a runtime problem. That's better in a strongly typed language as the C/C++/C# family. But also in such programming languages, you can have problems that only show at runtime. Anyway, the idea to let us look into the source code and point out an error the build/compiler did overlook is not getting to the root of the problem.

PS: When it comes to a setup, VFP comes with InstallShield Express to do that and you can use anything else free or commercial on the market to create setups. But that won't help. In a situation the installation already is done, updating an EXE by overwriting the EXE is a normal upgrade path to take. Of course, a user overwriting a file, even iff in the administrator group, will redirect this overwriting by UAC. So they better have permission to really overwrite the EXE.

I have done this in companies allowing such updates and they put the installation outside the system program files. But they implement a whitelisting of allowed executables, so you can't just put any EXE anywhere and rn it, only known EXEs are able to run, and that's implemented by group policies of windows and not by code which validats signatures and checksums, it's something not possible to simply override. But it then allows updates without a dedicated setup and still be safe against viruses manipulating the EXE.

Chriss

RE: FoxPro 9.0 - Build .exe

Any progress?

Chriss

RE: FoxPro 9.0 - Build .exe

Here's a short demo of how important the default path even is while you build an EXE:

CODE

#Define BASEDIR Addbs('c:\programming\tek-tips\projects\buildproblems')

Try
   Mkdir (BASEDIR)
   Mkdir (BASEDIR+"progs\")
Catch
   *
Finally
   If !Directory(BASEDIR)
      Messagebox('please assure directory '+BASEDIR+' exists. Then redo '+Program())
      Quit
   Endif
Endtry

Create Project (BASEDIR+'buildproblems.pjx') Nowait Save
With _vfp.Projects(_vfp.Projects.Count)
   Strtofile('#define CONSTANT 1',BASEDIR+'constants.h')
   Strtofile('#define CONSTANT 2',BASEDIR+'progs\constants.h')
   TEXT To lcMainprg noshow
#include constants.h
MessageBox(CONSTANT)
   ENDTEXT
   Strtofile(LCMAINPRG,BASEDIR+'progs\main.prg')
   oMAINFILE = .Files.Add(BASEDIR+'progs\main.prg')
   .SetMain(oMainFile)
Endwith

Set Default To (BASEDIR)
Build Exe (BASEDIR+'buildproblemsA.exe') From BUILDPROBLEMS
Set Default To (BASEDIR+'progs\')
Build Exe (BASEDIR+'buildproblemsB.exe') From ..\BUILDPROBLEMS RECOMPILE 

Copy&PAste that into a prg you save anywhere. Adjust the constant BASEDIR which will be where this prg code generates a new VFP project and builds two exe versions from it.
The two executables buildproblemsA.exe and buildproblemsB.exe will show 1 and 2 in their messagebox.

It shows that an #INCLUDE is not done relative to the location of the PRG it is in, but relative to the default path during the BUILD. It's not demonstrating or pointinng out you have a problem in location of header files and in their constants, but it points out the importannce of pathing, even during the build of an EXE.

I see the original expression of cCestaProgramu needs no difference in ID and EXE, when the EXE is put into the subdirectory progs of the project and in the final installation directory. But it could be important which path is current while you build, and even whether you tell the build to store the EXE directly into progs or whether you compile into the project folder and move the resulting EXE into progrs after the build.

In short: VFP is sensitive to paths. More sensitive than most people realize, as usually things are fine in that regard. When you open a pjx VFP usually puts you into the project home directory automatically. There are tools like environment manager that can influence this, and this can depend on which Windows account you use to open and compile a project, as environment manager information can be in the user profile. That's not likely an issue in your case, because up to now you managed to update the EXE.

Anyway, any reorganization of a project can cause a cascading effect. I still think the content of the gpt_memo.mem is not just texts used by the application but also contains important variables set to corret or incorrect values. If users modify this file to modify the texts, they can render it unusable for a RESTORE, as it's not just an ascii rtext file, it has variable names, and for string variables their string is in there, too, but the information about string length also is in there, binary. So extending a text you a) don't get a longer text, it's cut off at the former length b) you overwrite binary info about other variables and render the mem file unusable.

In the long run you should change from using a mem file to another file to store configuration and meta data. Template texts or text modules belong into a memo field of a dbf, for example, or simply into separate txt files you read in with FILETOSTR(). That makes many things less sensitive and easier to maintain.

Chriss

RE: FoxPro 9.0 - Build .exe

(OP)
Sorry, I was out of the office. Yes, I also tried putting GPT_memo.mem in the Progs folder together with the exe file, but it no longer worked correctly.
I also think that it shouldn't contain a Progs folder at all, but historically this is how the developer did it and I'm not familiar with it, so I kept this structure.

Answer to the question: If you are wondering where the GPT_memo.mem file is located when installing the previous developer version, then it is located in the main installation folder, and the merge file is in the Progs folder.
-------------------------
Yes, for a simpler program that we still use, I tried it like this and it worked, unfortunately I analyzed it for a long time and tried to figure out what changed and compared both source codes, but it was without result.

Quote (Here's a short demo of how important the default path even is while you build an EXE:)


Is it really important to insert this code into the prg, when the program already works for me after compiling and running the .exe file? Isn't it enough to create an installation file using "Inno Setup Compiler"?

EDIT: I didn't realize I had InstallShield Express on the Install CD, I had already uninstalled INNoSetup and installed InstallShield.

RE: FoxPro 9.0 - Build .exe

(OP)
I also noticed that the program detects the current version on the server and compares it in the Progs folder:


Here is a code snippet that refers to "KONCID".

CODE --> FoxPro

&&SET LIBRARY TO SYS(2004) + "FoxTools.fll" ADDITIVE
SET LIBRARY TO foxtools
DIMENSION aFileVer[12]
nRetVal = GetFileVersion((cCestaProgramu)+"\progs\gpt_tisk_sestav.exe",@aFileVer) 
koncInd=AT(".",aFileVer[4],1)
cisVer1=VAL(SUBSTR(aFileVer[4],1,koncInd-1))
pocInd=koncInd+1
koncInd=AT(".",aFileVer[4],2)
cisVer2=VAL(SUBSTR(aFileVer[4],pocInd,koncInd-1))
cisVer3=VAL(SUBSTR(aFileVer[4],koncInd+1))
IF nRetVal = 0
&&   DISPLAY MEMORY LIKE aFileVer
ENDIF 

RE: FoxPro 9.0 - Build .exe

Which line is 168? Sorry, I'm not really happy with having to ask everything that would be natural for you to provide. I'm not at your commputer. Please read what you're posting and think if someone not at your computer can make all of it that he needs to make of it.

I also don't speak your language, so could you translate the error message?

If konzind is missing, then likely because it would have been created by the RESTORE of gpt_memo.mem earlier in the code and the reason of that error therefore is a follow-up error of still the same problem, that pathing isn't working. You must have mangled something at some point. You only get this to work correctly again, if you go through the line that RESTOREs the mem file.

I also have the suspicion you lost some information from the mem file, likely if someone edited that file. Then you lost information you can't restore and have to find out from a healthy mem file what should be in there.

The code section you give would create konzInd, even if it wasn't declared before the line koncInd=AT(".",aFileVer[4],1), as an assignment creates a variable.

This depends on nRetVal = GetFileVersion((cCestaProgramu)+"\progs\gpt_tisk_sestav.exe",@aFileVer), which you should look into, either a function, procedure or a GetFileVersion.prg that takes these parameters and fills the sFileVer array. This line once more depends on cCestaProgramu being the parent directory of the progs folder. And if you don't have that, it's still the root of your problem. Any error you have related to not found files is just a follow up problem of cCestaProgramu not pointing at the right directory or files not at the expected location. The setup of your old version could be your referencee of that, unless you or anybody reorganized something. You need to sit down and figure out where things belong so they find each other and work together.

In regard of the progs folder, I did never said that the whole progs folder must be deleted from the installation as all programs are inside the EXE, I just stated that this would be normal. Because you only need external PRG files, if you call them but don't include them in the EXE. The expression (cCestaProgramu)+"\progs\gpt_tisk_sestav.exe" clearly expects the EXE inside the progs folder, so it is necessary for that reason. But you likely don't need PRGs in there, that are built into the EXE. Even if your developer did this to enable editing the PRGs, notice anything that is included in an EXE is taken from within the EXE, so changes made to prg files outside of the EXE won't have an effect.

The whole project cries for reorganization of everything, but your first solution should be to figure out how things really should be. Did I already say it could be important that you build the EXE and let the build create it in the project folder, but you then copy or move the resulting exe into the progs folder instead of specifing that destinaton during the build. Even that can make a difference.

The example I gave about the difference of compiling two EXEs from the same code, just once with the default folder during build being the project home directory and once the prog subfolder should make it clear I'm serious about this. I think we have too many problems with English translation, so essential things don't get over to you. Bt it should by now be clear that you have to be very precise not only in the code alone, but also in how you're building exactly. If you open a project you usually C into the project home directory. If you test your code in the IDE and it works, your current folder might have changed and then the build doesn't work the same as if you open up VFP and the project and compile while the project homedir is the current folder. All this can play a role, even if nothing changes in the code.

Chriss

RE: FoxPro 9.0 - Build .exe

One more thing to show with my buildproblems project: If you delete the project folder and restart from scratch, but this tie remove the RECOMPILE from the second BUILD EXE command, then the A and B exes will output the same value in their messagebox.

That corresponds to the "Recompile all" option of the build dialog. so that also can make a change. A helathy project should build correctly with recompile all, though.

Chriss

RE: FoxPro 9.0 - Build .exe

Heres a simple how to get to line 168 of your program.

1. open it.
2. right click anywhere to get this context menu:
3. pick Go To Line and type in the line number 168 you got from the error message.


This menu item is also available in the Edit menu:


And there's a third option to know which line is line 168 of your program, if you turn on displaying your text cursor position in the properties of the VFP code editor:


That will then be displayed in the status bar of the VFP main screen, like that:


I can't help you, nobody can help you, if you're that unable to help yourself, that you can only vaguely guess the location of the error. Common, you have been given the exact line numberr from the error handling established. Is it really that hard for you? That was a lot of words for how speechless you make me. Sorry, but if you're not able to provide the code at the exact position you now know, then at least ask how the hell you will get to line no 168 of a program. I don't even mind strong language, if you think how outdated this IDE is in comparison to Visual Studio or other IDS. But don't look out for code related to the variable name and guess there might be line 168 somewhere in there.

You have exact data, use it!

PS: one more thing, before you now get snappy and provide only code of line number 168. First of all, it would be fine, if you think about what could have failed in that line for yourself, then it also helps to show a feew lines before that line. It's okay to provide a code snipped as you did, but we can't guess what is line number 168 in that snippet. If you continue that way, I just have to remove myself from such a thread.

Chriss

RE: FoxPro 9.0 - Build .exe

(OP)
Line 168 is here:

CODE --> foxpro

cisVer3=VAL(SUBSTR(aFileVer[4],koncInd+1)) 
Error Message: Variable KONCID not found.

Unfortunately, I couldn't find GetFileVersion.prg anywhere. Anyway, I had version 1.0.2 set my predecessor had 1.0.1 set anyway when I rolled it back and rebuilt the exe file nothing changed and the error was still there. I did one such thing, I left gpt_tisk_sestav.exe in the main file and copied it once more into the Progs folder so it was there twice and the error went away.

So to confirm that gpt_tisk_sestav.exe was verifying the version in the Progs folder, I simply edited the path, deleted the Progs folder path and left the main program path. No error. The exe file also works in the IDE.

I know where they can be accessed, where the line code is, but thank you for the detailed instructions.
Thank you also for your patience and time :)

Could you still help me create the installation file in the InstallShield Express program?

thank you

RE: FoxPro 9.0 - Build .exe

(OP)
I have a problem building the setup.exe, I managed to do it twice, but it was without the application icon on the desktop.
I tried a lot of options, manually add a new icon to Applications Shortcuts>Use alternate shortuct Icon > Browse...
Unfortunately, that doesn't work either. He tried to change the icon in FoxPro as well, and he also writes a constant error. Or I generated a new Ico and also nothing. Do you know where the problem could be?
Error:

CODE --> InstallShield

ISEXP : error -6270: The record gpt_tisk_sestav.exe_E54A6EDEEE234E0DB93F85BE494C49C3_6.exe in the Icon table exceeds the limit of 57 characters.  As a result, the build will be unable to persist the database.
ISEXP : error -3204: Cannot extract icon with index 0 from file C:\Users\svrcinam\Desktop\GPT_tisk_sestav_Z_\gpt_tisk_sestav.exe 

RE: FoxPro 9.0 - Build .exe

First, fine you solved your pathing issue.

The line 168 code akes use of a name koncInd. The queston is, why this wasn't a variable at that point. And why it now is, when you made your changes.
If I would be at that position knowing that line and koncInd missing. The natural step of analysis then is to look for a declaration and setting of koncInd before that point in code. Not only in lines above it, but in terms of what code executes before that line. And that would be a debugging session very likely, but also you can then position in that erratic line, search for koncInd in backwards direction from there.

If there would be no LOCAL koncInd, no PUBLIC koncInd and no assignment koncInd=..., then this variable has to come from somewhere else. And that would likely be a RESTORE, which we already know is somewhere in your code.

If that's the case, then it's really a bad architecture in itself, using mem files on one side, but also making it optional by code the RESTORE runs, because looking at what you posted at 26 Jan 23 06:16 the RESTORE is only done IF the mem file is found. That avoids an error of RESTORE trying to restore form a non existing file. But avoiding that error lead to a much more serious problem later, as you experienced.

Such a thing belongs in documentation, which variables are stored and thus come from a RESTORE is important to know it's actually not optional to have the mem file restored. So there should be an ELSE branch using a messagebox telling the application doesn't find its mem file and therefore can't continue.

You see why I already uttered about using mem files. Their binary structure does not easily tell you what is in them, so even with a suspicion about them, you will need to dig deep to find out what's in there and why and what's necessary or what's perhaps wrong in there.

So far, so good.

Now, regarding your installshiled express issues: The version of it is very outdated, and I would rather use some other setup utility, but more important: This is a completely independent and new issue, so please start a new thread for that. In your own interest, because I bet many people here have already removed themselves from this long thread and won't realize your new question.

Chriss

RE: FoxPro 9.0 - Build .exe

Unimportant, but VFP has AGETFILEVERSION and it seems your former programmer wrapped that into a user defined function. And the 4tth element of the array created and populated with values is the file version.

So did you do changes without changing the version before? There seems to be a functionality detecting version changes in there and your change from 1.0.1 to 1.0.2 triggered a code section usually not used. If that's the case, now you know what single change you made, that you never made before.

It could be important to rather understand this mechanism and support and fix it, instead of going to a setup.exe. One thing that's making setups less favorable is, that they need to be done administratively. But if that's fine with you, you can go that route, of course. I know larger corporations use softwaremanagement assigning software to clients, which is based on MSI setups, usually.

The only thing you profit from using installshields in this outdated version is, that it can work with the merge modules that are installed with VFP that cover C++ runtime, VFP runtimes, xml3, xml4 and the different language resource DLLs like VFP9rcsy.msm for Czech and many more.

The help has a walkthrough for using installshield, by the way, which also describes in which cases to add which merge modules. And you likely don't come to an error with Installshield, if you create a setp following that walkthrough description.

Chriss

RE: FoxPro 9.0 - Build .exe

(OP)
I understand, using .mem is quite complicated, but the way you explained it to me, I understood and treated it.
I consider it as resolved, since no error is displayed in either the IDE or the EXE, so I consider it a working program smile
As a company, we have purchased 3 different versions from VF, where the InstallShield part is on the disk.
So I'll create a new thread to install.

Thanks again for your advice and especially your patience with me and your time.rednose Have a nice day

RE: FoxPro 9.0 - Build .exe

(OP)
Hi, I got very professional help here last time to solve a problem.
However, only today I found out that certain things do not work for me regarding "InfoUsek", the program displays the following message, do you know where the problem could be?

Most likely there will be a problem in granting rights in the output, but I have no idea how to fix this error :(
If anyone knows it would be very helpful.
Thank you again for your help

RE: FoxPro 9.0 - Build .exe

A error message it's very clean.

Is a table GPTINFO include in project or not?

mJindrova

RE: FoxPro 9.0 - Build .exe

It's really bad forum use to come back to a 3 months old thread and add to it, even if it was your only thread so far.
Please make a new problem a new thread.

And then do yourself a favor and not only post the error message, but the code of that button click, we are not at our computer and don't have your code at hand.

Chriss

RE: FoxPro 9.0 - Build .exe

(OP)
You are right, I will start a new thread.

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login


Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close