Due to our stagnation in 6.3, even though we had more modern versions available like 8.1, 9.1, etc., but for various reasons, we never completed the migration, the need arose to implement intensive API calls handling with JSON.
We considered what to do: templates, third-party solutions, DLLs in other languages, etc. We looked into the libsrc of C10 and found the library we needed. Well, it was very simple to change 2 or 3 *queues in the return of the functions in one way or another, and it was done. When we finally upgraded to C10, everything worked correctly.
Of course, due to issues with that library (errors with JSONs larger than 64K), we started using Mikeās fantastic cJson. But thatās another story.
Sure. No template covers all the properties and methods (and never has). Thatās true for ABC, and just about any 3rd party one. For some, it doesnāt even make sense to have a template. So in the sense that classes operate (mostly) without templates, thereās no argument here.
But even āminimalā templates are really useful. The global StringTheory template for example takes care of the EXP file, and manages all the Internal / External conditional compiles etc. It makes using the class a lot easier than manually adding INCLUDE lines, setting conditional compiles, and so on.
Iām not sure why youād āreplaceā an ABC app. Thereās nothing wrong with the underlying idea, and itās been reliably built on for 27 years. Itās easy to add on to, itās easy to extend and so on. Iām (personally) in no rush to replace it. Itās solid and well understood. replacing it now with new code would server very little purpose that I can see.
From what I understand Mark is still using (parts of) ABC as his foundation. Heās expanded the feature set in his own classes to suit his needs. Heās been able to derive classes from it that are tailored to his preferred behaviours etc.
Itās not hard to extend ABC - Iāve been doing that for 27 years now. So Iām not really sure what a ānew ABC alternativeā would need to do that we canāt do already today, or which ABC could not be extended to do. ABC is just a āfoundationā - on top of that we can build most anything we want.
The foundation of my 100+ year house is stone. Over the years, it has supported many changes to the house above. If I were to build a new house on vacant land, I probably would not apply the same construction requirements/methods used by the Bayliss Foundation Company back in the day even if my visual desire was the same native stone.
I think Mark uses the Designer for some windows. Mark uses my Window Preview Class to adjust the live window controls at runtime. He then has the precise AT() and Justification settings to change his window code. There is also a LIST Re-Formatter to get exact column settings.
The IDE Window Designer is good but not 100% accurate. Things like SPIN() controls are way off if you are trying to fit controls tightly like below changing a SPIN to use HVScroll buttons needs Width to change from 28 to 38. Compare to the default stacked buttons used on the Year of āAnother Dateā down below. This from Date Time Tool.
A Hand Code project is often the best way to make a DLL that will contain a Function Library to be used by many APPs or other projects. These would be Functions or Classes that do not use any kind of templates.
Making this kind of DLL with the APP system will force you to include lots of template stuff you donāt need. Also you often require Export/Import things like Global Request / Response that make it hard to use in many different APPās that use different DCTās. Some of these Export/Import have been made flexible in the templates or can be removed with extension templates that rewrite the EXP. Not being an APP the DLL can be ālean and meanā.
Being a DLL the Main procedure will never get used. You can put some useful code in Main to let you do some testing when you change the Project to a EXE. This EXE Main is handy to run some DLL code under the Debugger or tests.
In some of your current work youāll see this in the 20+ EIC DLL projects that are all Hand Code. They have almost no code and simply export 1 class. This was due to the problem that C8+ cannot deal with the same File in multiple Classes causing a link error. So each class is one DLL. To test using those DLLs there are some very small hand code Projects that import them. This keeps the code as small as possible and make it easy to run under the debugger.
With just the small amount of time I have been experimenting with a āhand code onlyā project, I can see how having total control of every part of the code could be advantageous. Clearly templates have their use cases. For example, I could see where a NetTalk web server would be prohibitively hard to do with hand coding.
I have really enjoyed reading everyoneās thoughts.
Object Writer was an early template which assisted with writing classes by generating the boiler-plate syntax. It was a useful beginner tool, but once the syntax is familiar itā s easier and faster to just edit inc and clw files by hand. (There are now class-writer templates in the box for those who wantvto go that route.)
The templates im referring to are cape01.tpw and cape02.tpw. These are common code that ship with all our classes (including the free ones.) They make creating a TPL for a class, or set of classes, trivial. They cover all aspects of using a class in an app or large app system.
I still have a template which I use for single proc clw/dlls that handles all those bits of hand coding things like the exp file that way I donāt have to remember it any more.
The templates provide a framework for future additions to an app and where there is a lot of prompt filling in the template, I do some prompts then export to txa and finish the rest off in the txa sometimes, but youāll get a feel for when thatās faster than prompt filling.
So unless extensibility is never going to be needed I donāt really see the point in hand code now imo.
UI code is generally pretty simple
But even with APPs I found a lot of code that doesnāt need to be generated,
Instead it can be put into a base class.
A form is often just a window structure and a dozen lines or so of code
In the case of control templates, those can generally be written as WindowComponents
which just take a few lines to add a lot of functionality to your window.
As to screen layout, when starting out I might use a window formatter to get close
but as Carl pointed out earlier in this thread, the window formatter doesnāt exactly match runtime so I use Carls preview tool to tweak the controls (mainly AT attributes) at runtime and then copy the changes back to my code.
I can of course open the my window or report structure any time using the SV.IDE window formatter, but again thatās become pretty rare for me. It just isnāt quick and accurate enough.
When Iām moving a lot of controls, I place a cursor on each AT attribute, and press a keystroke for an addin (Inc-Dec-Value), that adds (or subtracts) 1 from the number under the cursor. If youāve never worked with multiple cursors itās hard to really understand just how simple and effective this is.
