Ultimate Amiga
Network Boards => AMOS Professional Re-Development => AMOS Factory => ClassicAMOS Development => Topic started by: bruceuncle on May 09, 2013, 03:16:06 PM
-
Finally got it all finished and packaged up!
This is the DBL Editor and a load of other related stuff. As the Interface DBL language is used extensively in AMOS Pro and most of its Accessories, this should be of interest to anyone working on bug-fixing and enhancements. The DBL Editor Guide is extensive but I recommend at least following through the Using DBL Editor tutorials.
As the DBL Editor is so large and won't bl@#dy compile (why am I not surprised? :o ) there's also a Comment Stripper Accessory. So you can comment your sources to your heart's content and, if they won't compile, you can strip the comments to at least cut the size down. Saves around 50k for the DBL Editor. Useful for making small accessories where it's useless compiling them as they'll actually increase in size. (And require some fiddling with *.AMOS compiled versions to run as an accessory.) I always like to encourage commenting sources fairly extensively. ;)
There's also a very, very much work-in-progress of an AMOS Cross Reference Accessory for Variables, Labels, Fn()s and Procedures. I included it at this early stage as it's up to the point where it will list an AMOS program line-by-line showing how it's tokenised.
At lot more to do to get it to output a cross reference list! But yet another part of AMOS we need to understand for bug-fixing and enhancements.
The attached archive contains:
Comment_Stripper.info 628
Comment_Stripper\AMOS_Sources.info 628
Comment_Stripper\AMOS_Sources\Comment_Stripper_Cmnt.AMOS 22,934
Comment_Stripper\Comment_Stripper.AMOS 13,170
DBL Editor.info 628
DBL Editor\DBL_Editor.AMOS 194,547
DBL Editor\SDK.info 628
DBL Editor\SDK\AMOS_Sources.info 628
DBL Editor\SDK\AMOS_Sources\DBL_Editor_137_Cmnt.AMOS 243,299
DBL Editor\SDK\AMOS_Sources\DBL_Editor_137_Data_Cmnt.AMOS 20,205
DBL Editor\SDK\AMOS_Sources\DBL_Editor_137_Menu_Cmnt.AMOS 21,754
DBL Editor\SDK\ASM_Sources.info 628
DBL Editor\SDK\ASM_Sources\proc_mc_print_137.s 8,747
DBL Editor\SDK\ASM_Sources\proc_mc_print_137.s.info 518
DBL Editor\SDK\Banks.info 628
DBL Editor\SDK\Banks\DBL_Editor_137_Bobs.Abk 132
DBL Editor\SDK\Banks\DBL_Editor_137_Data.Abk 2,269
DBL Editor\SDK\Banks\DBL_Editor_137_Menu.Abk 7,276
DBL Editor\SDK\Banks\DBL_Editor_137_Rsrc.Abk 11,978
DBL Editor\SDK\DBL.info 628
DBL Editor\SDK\DBL\01_G_DBL_MN_137.Dbl 1,455
DBL Editor\SDK\DBL\02_G_DBL_AL_137.Dbl 4,265
DBL Editor\SDK\DBL\03_G_DBL_ER_137.Dbl 1,795
DBL Editor\SDK\DBL\04_G_DBL_PR_137.Dbl 764
DBL Editor\SDK\DBL\05_G_DBL_ED_ER_137.Dbl 1,751
DBL Editor\SDK\DBL\06_G_DBL_REQ_137.Dbl 2,446
DBL Editor\SDK\DBL\07_G_DBL_PREFS_137.Dbl 8,541
DBL Editor\SDK\DBL\08_G_DBL_IMG_137.Dbl 3,688
DBL Editor\SDK\DBL\10_G_DBL_ABX_137.Dbl 1,905
DBL Editor\SDK\DBL\11_G_DBL_PRG_NAME_137.Dbl 3,392
DBL Editor\SDK\DBL\12_G_DBL_PRG_MNG_137.Dbl 5,098
DBL Editor\Tutorial.info 628
DBL Editor\Tutorial\Empty_Rsrc.Abk 72
DBL Editor\Tutorial\Tutorial_1.AMOS 6,158
DBL Editor\Tutorial\Tutorial_2.AMOS 4,546
DBL Editor\Tutorial\Tutorial_3.AMOS 5,206
DBL_Editor.guide 121,436
DBL_Editor.guide.info 468
Tokens.info 628
Tokens\Proc_And_Var_XRef_101_Cmnt.AMOS 52,472
Tokens\Proc_And_Var_XRef_Bobs_101.Abk 132
Tokens\Proc_And_Var_XRef_Rsrc_101.Abk 2,036
Tools.info 628
Tools\List_Editor_Messages_Cmnt.AMOS 4,572
Tools\List_Resource_Messages_Cmnt.AMOS 5,666
Tools\Resource_IFF_Recreate_Cmnt.AMOS 11,176
Have fun! ;D
And don't forget to chastise me thoroughly for any bugs and omissions! Ouch!! :o
-
That's a really nice tool. I never got round to using DBL. The awkward abbreviated syntax, lack of error checking and having to embed everything in strings was just too much trouble. Having a proper editor makes it much more viable. In retrospect, DBL seems like a prototype for user forms in VBA. I wonder if it would be feasible to make a completely GUI-based interface designer that would import / export DBL?
-
I wonder if it would be feasible to make a completely GUI-based interface designer that would import / export DBL?
Do you mean something like the MagicUser Interface (MUI)? Feasible but unlikely. The only enhancement I has in mind was to incorporate the ability to add Images and Messages to a Resource Bank. The original Resource Bank Maker accessory is very clunky in the Image grabbing department!
The main reasons for writing this were to get to grips with a nice chunky AMOS program and to provide a useful tool for changing the AMOS GUI and its Accessories. I don't think many people will be using it otherwise ;) .
Did you have a look at the work-in-progress XRef program? At this stage, it will list an AMOS program alongside its tokens. Useful for understanding how tokenising works and what the AMOS file format is. It emphasises the point that we need to be very careful if we want to change any tokens. They're not tokenised using a table, it's a logic sieve! So one could radically upset things if that isn't taken into account. :o
-
I have had a look at them, my comments are below:
DBL_Editor.AMOS - I get "Variable name's buffer too small" (G_TEMP_IX_NEXT on line 213) in the AMOS Editor :(
Comment_Stripper.AMOS - Excellent accessory :)
Proc_and_Var_Xref_101_Cmnt.AMOS - Keep getting "Program not Tested!" message, despite testing (F2) and saving the AMOS program, before loading/running accessory! :(
List_Editor_Messages_Cmnt.AMOS - Excellent :)
List_Resource_Messages_Cmnt.AMOS - Excellent :)
Resource_IFF_Recreate_Cmnt.AMOS - Excellent :)
-
DBL_Editor.AMOS - I get "Variable name's buffer too small" (G_TEMP_IX_NEXT on line 213) in the AMOS Editor
A case of "If all else fails, read the manual!" ;D
It's a big program with long variable names and it chews up a lot of string space. So you need to make a couple of changes to the interpreter configuration to increase the variable and string spaces. Just look in DBL_Editor.guide under Installation. That goes through it step by step.
In all my AMOS programs, I also read the AMOS default screen's positioning and use it for positioning my screens. That guarantees that it will work on anyone's system if they've set their default screen correctly. The editor uses the same positioning values. But, as the editor's not guaranteed to be there for programs run from the CLI or compiled, the default screen is safer. The default screen's size is also used by AMOS. So if you're using a PAL system, and you find your mouse trapped to only NTSC height, the culprit is probably Resource Screen Open. No matter what you try with Screen Display and even if the Resource Bank's original IFF size was made to fit a PAL display, the mouse stays trapped. The 'out-of-the-box' default screen is 320 x 200 in AMOS Pro, so PAL system users should change it now to save hours of frustration.
Proc_and_Var_Xref_101_Cmnt.AMOS - Keep getting "Program not Tested!" message, despite testing (F2) and saving the AMOS program, before loading/running accessory!
You need to Test the program ([F2]) but NOT Save it. AMOS sets a flag when a program has been 'tested'. Any change after that point, including Saving it, clears the flag. I have to check that flag in case anything went wrong when AMOS tokenised the program during the Test process. Otherwise, there's a possibility some of the output will be garbage. The benefit is that if that flag's set, not only is it 'clean' but I also know it hasn't been saved. So I can confidently save it in the accessory (after checking with the user, of course, in case they want a different name).
As for the rest of your post, gee thanks! :-[ ;D 8)
-
DBL_Editor.AMOS - I get "Variable name's buffer too small" (G_TEMP_IX_NEXT on line 213) in the AMOS Editor
A case of "If all else fails, read the manual!" ;D
Ahh. I saw no point in reading it if I couldn't get the program to work! I have never come across that message before either (I usually get "out of variable buffer space" when coding my programs). I will go back and RTFM! ;)
Edit2: To anyone messing with the configuration - make a backup of the file first (it should be in the "S" folder as "AMOSPro_Interpreter_Config"). I suggest getting workbench to make a copy of the file and rename it to "AMOSPro_Interpreter_Config.Bak".
Proc_and_Var_Xref_101_Cmnt.AMOS - Keep getting "Program not Tested!" message, despite testing (F2) and saving the AMOS program, before loading/running accessory!
You need to Test the program ([F2]) but NOT Save it.
Thanks for the explaination, but the error message reads as follows:
"Program 'TEMP_1.AMOS' not Tested!
Please Test and Save your Program before using this Accessory."
Hence why I tested and saved it. Perhaps you should rewrite the error message? ;)
Edit: TEMP_1.AMOS is a copy of one of my programs, just incase things went pear shaped.
Edit2: Aha! It seems I have to save the file, test it and then run the accessory, otherwise it brings up one of 2 errors (the one listed above, or the file is not saved error message).
-
Hence why I tested and saved it. Perhaps you should rewrite the error message?
Well, as I pointed out in the original post, it is very, very much work-in-progress ;) .
The token listing function is just a by product of it's eventual destiny - to cross reference all Variables, Procs, Functions and Labels in an AMOS program. I added into the release at the last minute as an as-is offering. No guarantees, info only. Those messages were already written when I discovered how to interpret the flags.
-
Well, as I pointed out in the original post, it is very, very much work-in-progress ;) .
ok :)
Those messages were already written when I discovered how to interpret the flags.
Ahh, I see.
-
Ok, thanks bruce - this tool is awesome. just had to increase the variable buffer name size in the Interpreter Setup and I had to modify the code slightly to force it to Ntsc for 200 px high as it blocked the menus on my overscanned setup (the mouse limit went funny for me) - but a very good tool, I "injected" the fsel into my default abk and now the scrolly wheel works in the file selector as well. good work!