Converting FF2 Project to FF3

[Fraser Portwood]

Hi Paul
Had an issue Last Night when attempting to compile a project not in Firefly, it came back with a missing include file in a shared folder. Could not understand it as the include file is shared across a number of application.
Then I relised that I had converted part of the application which had been written in FF2 which include the same module file.
During conversion from FF2 to FF3 the shared include file had been moved from its shared location into a Local Folder.
The New File was only a include module which was untouched by FF3.
Can you do anything about this, if nothing else leave behind files that are not actually in the FF3 Project Folder.
In this case the file was moved from \devfolder\global\shared into \devfolder\FFProject\Modules and then removed from \devfolder\gloabal\shared
which was most annoying, as it would appear that common files will now have to be duplicated.

Regards
Fraser

[Paul Squires]

... as it would appear that common files will now have to be duplicated.

Hi Fraser,

Sorry for the aggrevation.   In this case, the best approach would be to manually insert an #INCLUDE into your application rather than have the file in your application as a Module. The best place to #INCLUDE the file would be the FF_AppStart (Special Function) found on the FireFly Workspace (Explorer tab).

FF3 does like to have all of its code in certain folders related to the project. The use of shared/public code does not fit in well with this approach as you have seen. I guess that it could be viewed as a design limitation but the #INCLUDE approach fixes it.

I will post in the Bug/Workaround forum this message in case others run into the same problem.

[David Kenny]

Paul,

You have FF3-on-the-brain.  (See your subject line on the above referenced Bug/Workaround) 

And referring to "additional parsing slows down the compiling a little bit".  You are joking right?  I might have comparatively small projects I work on, but I can't tell any parsing is going on at all.  The PB compiler seems to start"immediately". So any parsing of an extra file or two might add milliseconds.  Not enough time for me to tell. Your routines (and PowerBasic programs in general) are blazing fast.

BTW, in FF2 I never had a problem with #include statements at the top of just about any module or form.

David

[Paul Squires]

You have FF3-on-the-brain.  (See your subject line on the above referenced Bug/Workaround) 

Right you are - I made the change. I'm just happy that I can type FF3 and everyone knows what I'm talking about! Granted, FireFly3 is not many more letters but it's cumbersome when you are writing about FF subjects all day.

And referring to "additional parsing slows down the compiling a little bit".  You are joking right?  I might have comparatively small projects I work on, but I can't tell any parsing is going on at all.  The PB compiler seems to start"immediately". So any parsing of an extra file or two might add milliseconds.  Not enough time for me to tell. Your routines (and PowerBasic programs in general) are blazing fast.

he he he he, yeah, FF3 is pretty darn fast! I employed much better algorithms for FF3 over FF2. Actually, there is much more parsing that happens in FF3, yet the overall code generation time is much less. I can credit most of that speed to the hash lookups that I use now when parsing.

BTW, in FF2 I never had a problem with #include statements at the top of just about any module or form.

Usually it is not a problem. However, if one Include depends on another include or TYPEs/Equates from another include then the ordering of the includes makes a difference. Also, depending on which Form/Module that you put the #Include reference in, it may not be output in the final code generation in the right place.

[Nathan Durland]

I've converted a couple projects at work.  Traditionally I was using the "common file as a module" approach, and decided to "get with the program".  I added the files instead as #INCLUDEs in FF_APPStart and discovered a couple things:

- I have FF3's compiler environment set to use the "PB include files".  On my system, this points to two paths, FF3 could not find the included files until I addd the path to them

- Removing a module from the project deletes it from the source folder, no matter where it is.  Understandable now, but quite a surprise when it happened to me.  Thank goodness for NetWare salvage.

[Paul Squires]

- Removing a module from the project deletes it from the source folder, no matter where it is.

Really? That doesn't sound right. Selecting "Remove from Project" simply removes the file from the project - it does not delete it from the disk. How did you remove the module from the project?

- I have FF3's compiler environment set to use the "PB include files".  On my system, this points to two paths, FF3 could not find the included files until I addd the path to them

What do you mean? In the path settings you have two paths separated by a semicolon?

Maybe I am not understanding your current setup.

[Nathan Durland]

I did some experimenting and discovered what was happening.  At work, we have a folder on the network where we store projects.  One of the folders is G:\PROJECTS\INCLUDE, which has the "common" include files that we use.  Generally, in FF2 we were adding these includes to the project as modules -- that way FF was generating the declare statements and so forth.  This was in the PB8 days, when there was no forward referencing.

What's happening is that when a project is converted from FF2 to FF3, the conversion process moves the modules from their current home to the <project>\modules folder.  Removing the modules doesn't remove the file; I was just looking in the wrong place.  Now that I know, it's not hard to adjust to.

For the path thing,  I added the .INC files (that were modules) to the ff_appStart function as #INCLUDES.  Trying to compile yielded a "compiler file not found" error, until I added the explicit path to the file name.  In the PB compiler set up, the include path is "G:\projects\include";"C:\PBWin90\WinAPI"  Again, not a real big deal.

Today I converted one of our projects so i could do a small code change, and the size of the executable went from 760K to about 720K.  Nice!

[Paul Squires]

Thanks Nathan - I have also logged a ticket to deal with being able to specify multiple include paths.

A 40K savings on a 760K program is pretty good!