Quote: "I use Indigo as my editor and simply adding .DBA files to the project is sufficient enough to include them. I haven't had to use the #INCLUDE command ever. "
But then you have to go and re-add them through a file dialog on every project no? This would get tedious, with #INCLUDE you can just comment/uncomment an #INCLUDE line to manage which files are linked and which are not.
Quote: "By using the #INCLUDE command, does that allow me to dynamically attach .DBA files to my project? "
Sort of. I set the module loader up with a similar thought in mind, the intention being that if I didn't execute a call to require a module it wouldn't get included, but I believe it ended up attaching any #INCLUDE that wasn't commented out even if the flow of execution didn't actually process the command. Simply being uncommented in the source anywhere is enough to get it compiled in. Like if I never made a call to require a given module, the source was still compiled in, but it's initialization routines will not run until/unless the require call is made.
If you truly don't want a module included at all, the #INCLUDE line and following gosub have to be commented out, otherwise it will be included but remain inactive until required. The framework_require is mostly useful for managing the initialization routines and in preventing a module that is required by multiple other modules from initializing multiple times.
I also really wanted the ability to include files based on dynamic concatenation, something like #INCLUDE "modules/guiDocs/" + reqDoc$ + ".dba" I always found this handy in php, but unfortunately DBpro can only include literal file strings.
One major change I plan to make are the TODOs listed here:
type moduleUpdateData
ignorePause as boolean `if true, update will continue to run when gameplay is paused.
ptr as integer `pointer to function
mark as integer `timestamp of last update call
cycle as integer `ms after last timestamp before calling an update again. used to determine which updates get processed in a given loop.
priority as integer `used to determine the order in which the updates being processed this loop are handled.
`note: Be carefull when using cycle delays and dependant priorities that the settings for linked updates work with each other as expected.
` for example updateA (priority 2, cycle 0) needs the results of updateB (priority 1, cycle 5000), updateA will fire every loop but will only get new data every 5 seconds due to reliance on the slower updateB
` thus updateA will effectively have an apparent cycle of 5 sec, but it will continue to tie up much more processing time, reusing old data every loop.
`TODO: instead of priority, use a comma delimited string of other required updates.
`TODO: add 'processed' flag which gets reset at top of main for all updates on which timer() - .mark > .cycle (ie ready to run update)
`TODO: if a required update has not processed, defer current update and re-attempt similar to how gui elements get resolved.
endtype
managing priority values manually has proved to be problematic, with updates processing in un-intended orders at times if I'm not careful. I will be changing this so that instead of setting a priority, an update function can provide a list of other updates it depends on and requires so that if all pre-req updates have not completed for a given update, it will defer until they have. The gui element processing does something similar to this when an element's parent has not yet been resolved, it will defer until it has.
Quote: "Wah, but in further thinking, then I lose all the magic that the editor brings to the table in identifying variables, routines & functions."
Hmm, I actually use the IDE pretty much only to compile and occasionally to lookup command syntax/parameters in the help. I do virtually all of my actual coding in
notepad++ It has a lot of nice tools and plugins for text editing, bookmarks/jumps, regex, side by side diff comparison, split screen and cloning, syntax highlighting though that gets a bit limited when dealing with DBpro commands due to spacing. Attached is a language definition for DBpro that can be imported for the syntax/commands it is able to work with.
I guess I just haven't found navigating routines/functions to be much of an issue, by organizing and breaking the code up into modules, the file and function naming conventions narrow the search to reasonable sized collection in most cases, and all functions / notable variables are summarized in the file headers for quick searching and explanation. In a large module like the UI, I work on the left side, clone it over to the right side and keep the clone on the header for reference.
