Quote from Forum Archives on March 23, 2022, 12:14 pm

Posted by: maxetaylorjr <maxetaylorjr@...>

Hello,

Because I create my FB Projects using “Counterparts” they have to have different file extension because all counterparts have the same file name. As such FB does not recognize the files as belonging to FB, thus double clicking on them will not open a file in Finder, only if they are in a Project.

Therefore I’m requesting the simple addition of two new file extensions to be included in the next FB file extension list.

These two file extensions requested are “.fbh” and “.fbm” in staying with the “.fb” new FB file extension convention.

<array>

<string>fb</string>

<string>fbh</string>

<string>fbm</string>

<string>glbl</string>

<string>main</string>

<string>incl</string> // No longer needed. Use "fb"

<string>bas</string>  // No longer needed. Use "fb"

</array>

Thus the “.fb” extension is for any non-counterpart file. Since it basically replaces “.incl” and “.bas” of the old school those would remain only for historical compatibility with the top five file extensions in the list above covering everything.

With more new FB users that may come into the fold in the future a newer standard or file conventions should take us into the future and help to establish very usable conventions for FB as it progresses.

The “.fbh” files contain only “header” information related to their counterpart “.fbm” (source) functions (think NS source files).

This arrangement allows us to closely mimic in and FB Project somewhat how NS Classes are set up. The “header” files only contain information like “Constants, Enums, Globals, Records, Definitions, and function Prototypes”. These definitions only relate to their counterparts source functions.

Using this approach it allows me, or anyone, to consolidate a group of related source functions (.fbm — think like  NS Methods), and the header information those function may need to operate with them into a header ( .fbh) file as shown in the included project image below. This consolidation vastly increases the ability to maintain an application IMHO by keeping all related information together in same named files with only differing file extensions showing their relationship to each other.

This allows all the header (.fbh) counterparts to be included in a Project group I name “Interface Files” (sound familiar) ahead of all “Implementation Files”. As such, FBtoC and the compiler sees all the header information well before any of the functions are seen. Using this approach also completely eliminates any and all forward referencing problems because all source function prototypes are known ahead of time allowing any function to call any other function within its group, regardless of where it’s located in the file or Project.

The two counterpart files are also always displayed together in any Finder window and for the most part can be transported to other projects with little or no code changes required allowing for the creation of portable semi-class like FB files.

This also allows you to find all related information required for a group of related functions without having to find header information that may be scattered all over a project. That information will most always be found in the “.fbh” side.

Below is an image of one such Project assembled in this manner. Those files shown with the “.incl” file extensions will eventually be converted to the “.fb” file extensions in staying with the current FB conventions.

Also, any file with an “.fb” files extension can not be counterpart related.

I also have a small “Counterparts” starter Project that I’ll share with anyone interested to see how this works.

Thanks for listening and feedback is requested from all.

—————————

by: Max Emmons Taylor Jr. ©

FB 7.0.12

OS 12.2.1 Monterey

Xcode 13.3

4VFK20629

—————————

--
To unsubscribe, send ANY message to: [email protected] To access the list archives, go to: http://freegroups.net/groups/futurebasic/