Nothing happens to program 4

[Mandy_crw]

i everyone... i dont know what happen to the project i am working with... no matter how much edit i have done, nothing is happening or changing... even if i put error on the program when i run it, it just continues to run the last no error output... please help... thanks...

 

[Chris Miller]

Build with the "recompile all" option checked and that should go away.

Chriss

 

[Mandy_crw]

hi Chris... it worked!!!! Thanks so much Chris....

 

[GriffMG]

It is unlikely but there is a chance that your changes have been timestamped earlier than the existing ones... so just compiling won't change anything
unless you have followed Chris's suggestion... or perhaps the executable you are running is not the one you are compiling to.

Check the time and date stamp on the executable that you are actually running.

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. ​

 

[Mike Lewis]

The other thing that sometimes works in this case is to delete your FXP files. That will force VFP to recompile the relevant PRGs when you next run them - without any further action on your part. (But that won't help if the problem is also occurring in code within a form or class.)

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

Griff, that could happen if Mandy has set her system clock to an earlier date. Though Windows usually syncs with internet time-servers sh*t can happen to timestamps of files, I often see that VCT has a different timestamp than VCX, which is actually true if you only change source code but don't compile as the sources are in memos, and they're part of the VCT, not the VCX. VFPs build should look at VCT filetimes, but maybe (sometimes, depending on moon phase and holidays) does not? I don't know, but recompile all has often enough helped me out, even when I switched back to only compiling newer changes afterwards.

Another thing, Griff and Mandy, could be having twice the same PRG name or class name in different VCXes, that can easily sneak in, so expand all tree nodes and see if you have any double names. If you edit the prioritized one all is fine, if you edit the one VFP will only find second, any changes of that actually also do reflect in a build, but the runtime executes the first FXP of a certain name in the final EXE or the first class of a certain name.

That's by the way another reason to have one class per VCX, PRGs of functions instead of a set of FUNCTIONs and PROCEUREs in a PRG (with the exception of PROCEDURES within a PRG class definition, which are the class methods and can't be defined in multiple PRGs). If you have that, it becomes simple to identify double name usage within a project.

Chriss

 

[Rick C. Hodgin]

Mandy, it might be as simple as this:

? "Before: " + SET("development")
SET DEVELOPMENT ON
? "After: " + SET("development")

If it was OFF before, that would keep it from running the changed source code versions.

--
Rick C. Hodgin

 

[Mike Lewis]

Yet another possibility (although the Help says that it should rarely be necessary):

CLEAR PROGRAM

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

CLEAR PROGRAM reminds me of several CLEAR ALL debates. If you run a framework within the IDE with design time support during development, CLEAR ALL also removes that, so you at best have a fast method to re-instanciate the framework objects needed in the IDE, if you use one.

It's nice to have a PRG that you can run to clear all memory from loaded class definitions that hinder a new version to be instantiated. The simplest such tool is to restart the VFP.

Chriss

 

[Mike Lewis]

I agree, Chris. I have a program which I use in the IDE in all my projects, called CLEAN.PRG. I type DO CLEAN whenever my application crashes when running in the IDE, or if I cancel execution. The program does a CLEAR ALL, but note that this does not do a CLEAR PROGRAM.

My CLEAN program also brings back the SYSMENU and the main IDE toolbars; re-instates my (docked) IDE windows (Command, Properties, Document View and Data Session); clears any error-handler, shutdown-handler, etc.; sets SAFETY ON; restores the VFP Help file; displays my custom DevTools menu; and finally puts focus to the command window. All in all, a very useful dozen lines of code.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mike Lewis]

One other point about CLEAR PROGRAM ...

I see that the VFP Help says that one of the most common reasons to use it is if you are using "an external or terminate-and-stay-resident (TSR) editor to modify a program file".

Terminate-and-stay-resident editor: that really is a bit of ancient history. For the benefit of younger members of the audience, a TSR was a wonderful invention back in DOS days. It was a special kind of program that you could launch from the command prompt in the usual way, but which then immediately appeared to terminate, with control returning to the command prompt. However, the program remained resident in memory, and could be re-called with a pre-specified key sequence. This meant that you could actually have more than one program running at the same time, something that was previously unheard of in MS-DOS (or PC-DOS).

The most famous TSR was Sidekick, from Borland (the makers of Turbo Pascal). It had several functions, but its most useful was its text editor. I used it a lot when testing code in Foxbase and DOS versions of FoxPro. I would launch my application in the IDE. When I needed to correct a bug or change some code, I hot-keyed into Sidekick (which already had the PRG loaded); then I made the change, returned to Fox, did a quick CLEAR PROG, and carried on testing. Much faster than closing the whole thing down in order to launch a separate editor.

I even wrote a couple of TSRs myself, using Turbo Pascal, one of which I ended up selling to several hundred customers.

Does anyone else here remember Sidekick? Or any other well-known TSRs?

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

No, I never used that mechanism, though I worked with MSDOS, I wasn't a developer at that time, I knew things like memmaker, but I didn't use the original Foxbase and FPDOS.

Regarding clean.prg the simplest way to get to a clean environment is a restart, I have this PRG in Home()

_Screen.Tag = On("Shutdown")
On Shutdown VfpRestart()
Quit

Procedure VfpRestart()
	On Shutdown
	cCommand = _Screen.Tag
	cHere = Sys(5)+Sys(2003)
	If !Empty(cCommand)
		&cCommand
	Endif

	nRestartBegin = Seconds()
	oVFP = Createobject("VisualFoxPro.Application")
	oVFP.Visible = .T.
	oVFP.DoCmd('_Screen.WindowState=2')
	oVFP.DoCmd('CD "&cHere"')
	oVFP.DoCmd('Public nRestartBegin, nRestartEnd')
	oVFP.DoCmd('nRestartBegin= '+Transform(nRestartBegin))
	oVFP.DoCmd('nRestartEnd= Seconds()')
	oVFP.DoCmd('? "Restart took", nRestartEnd-nRestartBegin')
	oVFP.DoCmd('Release nRestartBegin, nRestartEnd')
	Quit
Endproc

I also have VFP on a RAM disk I load on system start, for that I made a RAM disk image (depends on what RAM disk software you use), that loads as drive F: and has F:\VFP9. I linked the original Home() to F:\VFP9 via mklink.
To do that start cmd.exe as Admin, CD into system32 and then do mklink /J "C:\Program files (x86)\Microsoft Visual FoxPro 9" "F:\VFP9" (or whatever is Home() in your case).

Before you can do that junction the original home folder has to be renamed to "Microsoft Visual FoxPro 9 Backup", for example. It will now not be used any more, but you might want to keep it to go back to it, though the RAM disk image also makes each restart a reset. You'll have foxuser.dbf in your user profile and other settings in the registry, so changes you make are still set as defaults and there is almost no difference to how VFP works. If you do changes to sample data in the samples folder, that will get reset at a Windows restart, for example.

My RAM disk only needs about 256 MB and I sized it to 320MB to have a little wiggle room when VFP writes something into Home() like an fxp at build of something.

The mklink makes it transparent to anything else, you can use a shortcut you made to VFP9 as is without changing anything, as access to the old home() folder is redirected by the junction.

You can adapt this to your needs, like I did by keeping the current directory from the current to the next VFP session. You can also RUN \N vfp9.exe instead of using the VisualFopro.Application class, then you have the opportuniity to use command line parameters.

The code posted records timing of the restart and from nRestartBegin = Seconds() to oVFP.DoCmd('nRestartEnd= Seconds()') takes 0.2 to 0.3 seconds on my system. I don't have the section after CD cHere in my usual PRG, that's just for demonstration purposes.

Restarting VFP and QUITting the current ID session ideally would be done by first quitting to write flush changes to foxuser.dbf, etc. But the VFPREstart procedure executes whatever you or a framework forsees as last VFP session action by ON SHUTDOWN and also a QUIT runs through any objects Destroy() event, etc. You might even stop quitting VFP, but you'll still get a new VFP session. That might then fail to load a project or get exclusive access to other files, but in the usual case that shouldn't be a problem and if you need to do any special calls you can embed them in the VFPRefresh() procedure.

I guess you won't even need a RAM disk to do this, you can also use the Windows Disk Management to create a vhd or vhdx (at least in Win10 that's on board). With which you don't put VFP into RAM, necessarily, but a virtual disk drive that also profits from filesystem write buffering, so if you let that always start empty and copy HOME() into it after you attach it, VFP should mostly be cached. You could also have almost all of VFP in the vhd(x) image and at start only copy over vfp9.exe as that needs to be cached to start faster. It's a bit of a hack and means your first start takes longer.

But then there are several advantages: You start from always the same image. If you run VFP as admin, that elevation is kept for the new VisualFoxpro.Application instance without the need to confirm a UAC prompt again. You can do whatever you want in the VFPRestart() routine, before anything of the current session unloads through the final Quit command. If you care much for tidying code that saves and then also verifies saved data, that could be done in Destroy() or here. And since you have access to anything you can transport not just the current directory but anything else you want to forward to the new VFP session except objects themselves. But the idea is to refresh all memory and restart any framework, remove any classlibs, classes, prgs and such stuff from memory.

Also, you can manage user licences with such a VHD or RAM Disk image and keep it in the hands of the developer. In that case you also would like to migrate several things into the Home() folder that becomes the RAM disk or vhd image, of course: The VFP runtimes in Microsoft Shared and the msvcrt71.dll from SysWow64, to name two things. Anything that needs to be done to the current Systems registry and establishing the junction with mklink could also be done at the step of attaching the image.

And now, you obviously could ensure SET DEVELOPMENT is set ON within the VFPRestart procedure or do other things. What you don't need and what only matters in terms of getting file access to unclosed handles is to do any CLEAR, RELEASE, USE, etc. as that's all done by a successful QUIT. I never had any need to have the same _VFP.ProcessID or _VFP.ThreadID, those are two of very few things that have to change by starting the new session.

Chriss

 

[Chris Miller]

I just experimented to see when VFPREstart actually happens. For example, if native shutdown behaviour already closed forms. Well, it does not, VFPRestart runs first, but you can use a tier to inverse it:

oForm = Createobject('form')
oForm.Show()

Public oTimer
On Shutdown oTimer=Createobject('restart')
Quit

Define Class restart As Timer
	Interval = 10
	Enabled = .T.

	Procedure Timer()
		This.Enabled = .F.
		Messagebox( _Screen.FormCount)
		cVFP = _vfp.ServerName
		Run /N "&cVFP"
		On Shutdown
		Quit
	Endproc
Enddefine

So you can also combine these mechanisms and do something before VFP behaviour closes forms, file handles, tables, clears class libs and classes, etc and after that's done, by calling a procedure and creating a timer within that.

The timer event could care for any form that's still not closed at that point, or just log what's still in memory to identify problematic things that don't release gracefully in bad cases.

I tried whether the public var is released if you set the interval to a higher value, it's not, so you can decide to give quit 1 or more seconds, if you like. oTimer is not automatically released and so the timer event does run, even if other things like forms are already released and cleared.

It could be interesting to check what's still in memory and what TXNLEVEL() you may still have or how modal forms behave, database connection handles, etc...
Several functions have interesting info, like ASTACKINFO(), AUSED(), ASQLHANDLES(), LIST DLLs, LIST OBJECTS and more. I wonder if varying the timer interval would enable you to get several snapshots of quit or whether the single threaded nature of VFP means the timer event will only be processed when VFP goes back or would go back to READ EVENTS and so QUIT has done its native behavior.

Chriss

 

[GriffMG]

Maybe that is why VFP stays resident after it has quit sometimes for me - making it impossible to update .exe files

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. ​

 

[Chris Miller]

Griff,

do you mean VFP itself or an EXE you built and ran, ie your application? If that can't be rebuilt because the EXE still runs, that's very likely a problem of not quitting. By the way: QUIT isn't necessary. At minimum, you reach the end of main.prg or the first PROCEDURE/FUNCTION or DEFINE CLASS. Otherwise, also a RETURN (somewhere) after the READ EVENTs is enough, or CANCEL. But often enough the problem is getting to CLEAR EVENTS or to let CLEAR EVENTS actually continue after READ EVENTS.

For example modal forms don't need READ EVENTS and even if your main.prg has one but the main form is modal, then trying CLEAR EVENTS in form Unload and or Destroy means you didn't yet got to READ EVENTS, so CLEAR EVENTS has no effect.

In detail, if your main.prg does

DO FORM mainform
READ EVENTS

And you have CLEAR EVENTS where it matters, perhaps also as menu item, that all looks okay, but if the main form is modal you'd only get to READ EVENTS after the main form unloads and so even from mainform.Unload() or Destroy() a CLEAR EVENTS would be issued before you get back to the DO FORM line and READ EVENTS then follows CLEAR EVENTS. That doesn't error nor does it clear anything.



Chriss

 

[GriffMG]

Hi

Sometimes, not often, certainly not always, an exe will exit - the interface will cease - using a normal QUIT - but the process will move from being a 'live' application to being a Windows background task (according to TaskMGR) which then means I have to kill that task (which *can* seem to run indefinitely, certainly for some hours) in order to replace the .exe with an update.

This happens apparently randomly, can happen to two or more copies of the .exe - I might have a dozen running on the same server and one might be affected, the rest might exit normally.

I kill the background process, nothing seems to be damaged, I replace the exe with the new version and carry on as normal. This happens to, I think, any of three applications, on any of two or three different
Windows Server versions all with virtually no user intervention (the apps are all 'scanners' for web applications that send emails, produce reports or process images).

Through various versions of the apps going back maybe five or six years, I have asked before on here, but no-one else seems to have experienced anything similar.

And I think I have said before, I don't use 'READ EVENTS' at all, never have.

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. ​

 

[Chris Miller]

Griff,

I don't think a VFP process becomes resident, that doesn't happen accidentally, that's a sign of "Cannot Quit Visual FoxPro". I guess in your server situation, running an EXE multiple times unattended on a server can have side effects nobody else encounters. I always used task scheduler for such things, though to get an exit code from a VFP application you need to use ExitProces API, a RETURN 1 or any number from main.prg doesn't get to the task scheduler.

Chriss

 

[GriffMG]

Next time it happens I will try and post a screen shot of taskmgr

These are scanners Chris, they run 24/7 constantly looking for set things to do - make zip files, create VFP reports, open PDF files and put QR codes on them,
compare two versions of drawings, stuff like that. I shut them down from time to time to manually update them using a button with code like this:

IF MESSAGEBOX("Quit System",52,"Are you Sure?")=6
  QUIT
ENDIF

Most of the time that's fine, just once in a while it isn't.

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. ​

 

[David Higgs]

Terminate-and-stay-resident editor: that really is a bit of ancient history. For the benefit of younger members of the audience, a TSR was a wonderful invention back in DOS days.

Ah, those were the days. TSR and also using HIMEM.SYS trying to squeeze the last bit of RAM out of the machine!

Regards,

David.

Recreational Developer / End User of VFP.

 

[Chris Miller]

Griff,

Okay, how about using what you suggested doing in thread184-1347611, last post?

You surely also know, sometimes you need to End a task multiple times before it exits. That doesn't mean it has become resident, it's just not responsive.
You're (usually) not at that point, as you can click the button. The MessageBox confirms the click event fired and that shows the process currently is responsive, as it reacts to your mouse click.

If nothing happens when you click, that's the case when the FoxPro process has become deaf to any signals in the form of Windows messages like WM_CLOSE or WM_SHUTDOWN.

Maybe you could even add BindÉvent handling of such messages and see whether they get to the process at all.

One other thing you could do is

SET COVERAGE TO exit.log
QUIT

And see what, if anything, is logged there, except the QUIT line.

Chriss