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

 

[GriffMG]

Thank you - I will look at including the exit log idea.

** edit **
Crikey, that link is 14 years old...

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]

...14 years...

I realized that SLEEP within the batch file should be replaced by timeout /t 10 or similar alternatives.
But ExitProcess parameter comes through to a bat file as ErrorLevel.

Chriss

 

[Mike Lewis]

Crikey, that link is 14 years old...

I see I posted the preferred solution:

DECLARE ExitProcess IN Win32API INTEGER nExitCode

Not only don't I remember posting that, I didn't even know that I knew it.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[TamarGranor]

I tend to do my testing from the Command Window. One issue I sometimes run into is when I inherit programs that use SET PROCEDURE. I'm not sure of the exact steps, but sometimes, I find I have to rename or delete the EXE to have changes in the procedure file take effect in my testing.

Just another reason I hate procedure files. I've wasted so much time over the years on this annoying thing.

Tamar

 

[GriffMG]

Hate is a strong reaction.

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

 

[Mandy_crw]

Thank you everyone for your help... yes i have set the date earlier for testing the project.... but everything works as normal now... after i have recompiled it... i am overwhelmed and thankful by the answers you have given me, i will try to study them... thanks again everyone... god bless

 

[Chris Miller]

Tamar, I work with the feature of compile before saving, which I think prevents such a problem, as I never came across suc a situation.

A build can't replace an EXE that's still running, more common a DLL that's still used. And restarting VFP also is the sure way of closing any explicit and implicit file handles VFP uses. I usually also test by starting main from the command line, not by build and DO EXE. EXE debugging has some advantages, not needing SET PROCEDURE is one of them, but it helps less with component tests.

As Mike pointed out CLEAR, the help topic also suggests that it's not SET PROCEDURE which hinders PRGs to compile, but classlibs, classes and PRGs in memory. There are more advantages of single PRGs thatare more important than that. I still like to rely on explicit SET CLASSLIB and SET PROCEDURE than just on SET DEFAULT and SET PATH during development.

I think there are many things which can be solved by being strict about something, but I dislike the categorization of wrong and right camps. There are combinations that make sense and overcome single problems in other ways. For example in another thread about the VFP C++ compiler and its obfuscation feature it turns out Chen uses the beforebuild of a project hook to create a full shadow project with modified code. He's not the first one with such an idea, but that's another topic you can do a lot more than what VFP offers with precompiler options that way, even if you introduce possible quirks in these copies, the advantages outweigh the disadvantages.

Chriss

 

[TamarGranor]

Hate is a strong reaction, but I've had so much grief working with procedure files that hate is the word. Since FoxPro 2.0 introduced the Project Manager, there's been no reason to use procedure files.

Now that I use Thor a lot, I have another reason to dislike procedure files. Unless you've SET PROCEDURE, the Find Definition tool doesn't find stuff in them.

Procedure files were a work-around created for a world that didn't know anything about projects. There's simply no reason to use them today.

Tamar

 

[Rick C. Hodgin]

We use procedure files for code shared across our suite of apps, and stored procedures for code unique to each app.

20+ years. Zero issues.

We do compile them into EXEs, so that does make it easier. But even in our dev environment, DO main.prg and all of the code we have works fine.

--
Rick C. Hodgin

 

[Steve Meyerson]

I agree 100& with Tamar. I used SET PROCEDURE before Foxpro 2.0 and haven't used it since.

Each app I create along with the project pjx etc. goes in its own main folder. Every procedure is written as a new method in that project manager.

Am I missing something?

Steve

 

[Rick C. Hodgin]

Am I missing something?

Yes. You're missing a powerful coding feature that allows you to share code between applications.

There are other ways to do it, but there's nothing wrong with using PRG files and SET PROCEDURE TO ... setup once in your main.prg function, and then everything's in place.

--
Rick C. Hodgin

 

[Steve Meyerson]

Hi Rick,

Point well taken. My "excuse" is my heavy use of copy&paste.

Steve

 

[Mike Lewis]

These last few posts demonstrate something I have seen several times in this and other forums: SET PROCEDURE is something that developers either love or hate. There are clearly pros and cons on both sides. I know that Tamar has often strongly strongly argued against. I've also seen many arguments in favour.

Personally, I prefer to use one or two procedure files rather than multiple individual files. But that's my my personal preference. In my case, it's partly a habit: a lack of incentive to change what I have been doing for 25 years or more. I am also aware of the arguments on the other side.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[GriffMG]

Snap with Mike.

I seem to only use SET PROCEDURE TO for access to WestWind stuff.



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

 

[Rick C. Hodgin]

We have a handful of procedure files that we use. They are grouped by functionality / commonality. We've also added things like ZIP functionality to our apps (using 7-Zip), for example, and we use common shared classes for things like that. So, we use both.

For generic code, we typically have a small number of separate PRG files with many functions contained within. We probably have 150 separate custom functions we use that are shared. Ways to process a messagebox() and log it to our logging system. Determining if a value is KB, MB, GB, or TB, etc. All kinds of things.

I can't see why anyone would hate SET PROCEDURE TO. At any point in source code, even foreign source code you're debugging, it's easy enough to know what all is in scope with SET("PROCEDURE"). Pass the output through a beautify function (in one of those procedure files) and it can be a nice list if need be.

In any event, there are definitely strong views on both sides. I look at things as being tools in the toolbox. Some people are partial to a certain set of tools, others to other tools, but all of the tools are there and all of them work. VFP is truly amazing like that.

In the company I work for, I use more XBASE than other people do, because I grew up in FoxBASE+ 2.x. I learned how to do everything using that tool, and those deep roots still permeate my code. There are some tasks where a SET RELATION TO is the right solution. Others where it's not. But having the ability to do the same task in multiple ways ... just an amazing feature of mighty VFP.

Microsoft committed a sin by killing it. They removed from the world a most powerful system, and they did it because it is a tool of freedom and not as much revenue as what they've evolved into over times. They harmed the people of the world by what they've done with regards to VFP.

--
Rick C. Hodgin

 

[Chris Miller]

I know someone who maintains some backward and forward compatibility procedures/functions all in one file, which I think has no #IF VERSION blocks that exclude unnecessary parts, but I wouldn't care so much as to split this up. It's convenient, even though it's not necessarily bundling to just one topic, as changes, for example additional flags for STRCONV or IIRC APROCINFO() are on totally different topics.

I do neither really prefer single PRGs nor bundles, but it's very okay how single proc/func PRGs are included into a pjx when you call them in any code and have the shared PRG path in the project. And regarding cross-reading source code, Tamar mentions Thors' feature to show the definition of something and if that works with SET PROCEDURE I'm fine with a project hook that iterates all project files which are classlibs and SET CLASSLIB to all of them, that also enabled intellisense when you just declare Local objectvariable as class name without specifying the VCX the class is in.

I never had the problems you describe, so I guess there's something else that's not working well with each other, but I don't know if I'm motivated enough to find out what exactly produces the problem.

Chriss

 

[Rick C. Hodgin]

On our build computer, on some of our legacy apps, we've setup a scanner that goes through and automatically adds references to every PRG included. We call it xyz_code, and it basically makes sure that every folder is in the path, and the set procedures are setup.

For our main apps that are still undergoing active development, they share the common cores and it's a nice efficient design that's really been integrated nicely in recent dev cycles.

There's a joke-not-a-joke in our dev group: Now that we everything working so nicely and is debugged, integrated, really quite smooth, we're all expecting Microsoft to stop supporting 32-bit apps or VFP specifically or something in a future release of Windows.

--
Rick C. Hodgin

 

[TamarGranor]

I wrote about all the reasons I hate procedure files here:

http://www.tomorrowssolutionsllc.com/Articles/Splitting a Procedure File.PDF

Tamar