For the hand coders out there, I am curious as to why you choose hand coding over app gen/templates?
I am considering getting into hand coding myself and want to learn more.
Thank you!
If you have lots of tables that need browses and forms, itâs hard to argue with appgen, unless you build a framework yourself.
But although appgen and templates can save you time, they also can cost you time by interrupting the creative process and generally write less pretty and more voluminous code. Going in and out of template prompts can be a drag.
Just depends on what you need and what your comfort zone is at the time.
2 Likes
The templates can save a huge amount of time. Adding complex functionality can be almost trivial. (eg CS sendTo) and I think make maintenance easier.
Hand code makes sense for some things however. Itâs difficult to create classes via templates for example.
I agree it really depends on the project at the time.
1 Like
While there are a number of folk who have gone âall inâ on pure hand-coding, I think the best results are obtained by using both generated code, and hand-code together. Clarion obviously supports both, and both have a place.
Generally speaking (and Iâm being very general here), the ideal combination is to use templates for UI, and hand-code for functionality. And then for maximal use, you write templates to âglueâ the hand-code into the app.
If you have all 3 pieces done correctly then your app is maximally forward compatible. For example, as Sean suggests, by having a âstandardâ UI it becomes possible to include new UI components into your app with very (very) little effort. With a couple minutes work you might get browse-column-sorting. With a few minutes more you get SendTo (browses that print and export) and so on.
So by using templates in this way, you not only create some consistency in your application behaviour, you also make âstandard containersâ that âstuff can plug intoâ.
Of course most people donât write templates, because itâs another thing to learn. But there are a lot of 3rd party offerings, so having that plugability means you are no longer âthe only developerâ of your app, you now have a team of contractors building generic code that you can select at will.
Naturally, as with any framework, it probably doesnât match the way âyou would have written itâ. Some programmers have thus either heavily modified the shipping templates, or bypass the template completely, prefering to build everything âfrom scratchâ or by extending the classes etc. This leads to smaller code, faster compiles, and a UI which is very tailored to that specific look and feel. Thereâs nothing wrong with this per se, it just means that you need to code âeverythingâ. Some 3rd party things can be added, some easily, some less easily. But obviously youâre now plugging that generic code into a custom framework, so itâs more effort than the standard templates.
Lastly, there are implications when it comes to succession. If your program is âstandardâ then it can be easily passed to another developer. Since they know the framework (say ABC) and templates, they can concentrate on the bits that makes your app unique. This is not trivial to do, but itâs doâable. By contrast apps that are completely hand-written are usually written by smart folk. Who did smart things. And it can be hard for the new developer to understand that smartness. Basically everything has to be learned from scratch (and hopefully itâs fairly consistent.) Once multiple smart programs have had a turn with a hand-coded system, it can become more and more difficult to understand, and safely make changes.
So back to the original question. I think the maximal benefit of Clarion is in writing hand-code (ideally in classes) and then using templates to plug those classed into your UI. Generic class-plugging-in templates exist, so you donât need a lot of template language skills to adopt this approach. It also keeps your custom code âoutside the appâ and that has benefits for testing, reuse, and so on.
But this is not a âone way is best for everyoneâ question. Every programmer will make their own choices, as best fits their skillset. Every approach means you lose something. Itâs useful to know what you are losing when you choose one particular path.
8 Likes
What Jeff & Bruce said 
90% of what Iâve written in the last 10 years hasnât involved more than 1 window, and I canât remember the last time I used a dictionary or browse/form pair.
So for my needs (bearing in mind Iâm still using C6!) hand code is good enough.
Greetings -
I can agree with what has been said. I am doing both, at current employment we do things without templates. At my home development, I do things with the ABC templates.
At home, I also have written templates that write code, classes and templates starting from the dictionary. That has been, some of the most useful items for my personal development, when the need arises. It does save some time. Not trivial, but very useful.
Chunks of those techniques are available on my GitHub repo under an MIT license. For those who want to experiment and look at the examples. And there are webinars on some of those techniques.
Regards,
Roberto Artigas
2 Likes
Dear all, in my experience (since C3.0 for DOS and before that from TS-M2 1.17) with Clarion, I started developing systems solely with templates and generated applications of 300,000 lines without practically using code. The problem was the learning period, specifically knowing where exactly to place the necessary lines to achieve the desired result in the templates. Later, I started using a mix, and in more complex systems, I began using my own code and classes within the templates, and then directly code and classes.
If I were to start an application from scratch today, surely the framework and all the basic table CRUDs would be with templates, but not the reports. For performance and filter reasons, I found it simpler to do them in code via SQL and then use templates for the Previewer, Export, etc.
There are templates and templates, and there is source code and source code. A template can solve many things and establish a working framework, but not all have the flexibility, especially at the point where a template becomes obsolete or less useful, and migrating from it to another or to your own code is a problem. As always, and to conclude with a recommendation, use third-party templates that are not black boxes. Only Clarion allows you to generate applications at the speed it does with the help of templates, but at the same time, they hide the true potential of a powerful and complete language that your users will appreciate if you give it its place.
Sort of off the original topic I guess, but I would 100% agree that writing a complex report in Clarion is about ten times more difficult than writing the same report in SQL. Iâm just guessing the number because I havenât even thought about trying to do anything other than the simplest report using Clarion reports for many years. I create the view that is the report in SQL, import the view as a table into clarion, and then just get clarion to print out the table. In that view I can have aggregate sections, computed columns, conditional counts, whatever. Would be hell to do in the clarion report template: youâd probably have to store bits and pieces in queues first and grab them into the main file for the report as you get each one.
2 Likes
It would help to have an idea what you were thinking of hand coding?
Writing a new Class is all hand code. Usually Iâll write a little companion EXE to to try out the Class. If that EXE does not need to do things that are easy to do in an APP (like process files) then I like to write it as a hand coded EXE. I usually start with my Scratch Program.
1 Like
Thank you everyone for your input.
I guess technically Iâve been âhand codingâ for many years now. My original question was targeting those folks that create entire apps via hand coding.
I greatly appreciate everyone who contributed to this thread.
Great info!!!
1 Like
As many of you know, I am one of the aforementioned all-in hand coders.
I used APPs from CPD 2.0 through CW7, but when I found that the IDEâs window formatter could not handle the fact that I had equates in my window structures, I decided enough was enough and took my generated code and archived my APP/DCT. That and the annoyance where a generate and compile sometimes just refused to generate. I really disliked the wasted time of making a change, generate and compile, test, and it failed. Only much later did I realize that it never generated. Talk about a big productivity hit.
After moving away from APPs I was really surprised just how much generated code I was able to throw away. I also noticed a lot repeated generated code, so I derived a WindowManager and put all of the repeated code into one place. Reducing the noise in my code, much like many APP developers tend to focus mainly on the embeds.
As many of you have mentioned there are programs that fit nicely into the template approaches. For example browse/form crud works well. So if the templates match your needs, then by all means use templates. Maybe generate once, and move to hand code. Either way, I still encourage everyone to read the generated code, and to dive into the ABC classes to understand what is in your program, even if you just wrote it by filling in some template prompts.
Next Iâd encourage everyone to learn how to write classes. At some level filling in template prompts is directly analogous to setting class properties, and/or calling an .INIT
If youâre using ABC I strongly encourage you to learn how to write a WindowComponent, you can add a LOT of functionality to a window with just 2 or 3 lines of code.
- declare an instance of the object
- ThisWindow.AddItem( WC.WindowComponent)
- maybe a WC.Init to configure it
What I havenât heard anyone talk about yet, are the proâs and cons of day to day coding in APPs vs hand coding. No more having to walk on egg shells to avoid problems with a fragile IDE is like quitting a job where you had an abusive boss. When hand coding you get to use MUCH better editors. Iâm sorry but apart from Window/Report formatters the SV.IDE editor is not something I use or want to use, as itâs ⌠umm⌠well letâs just say it severely lacking. Reverse search anyone?
Note: I moved to ST when my wife got tired of me yelling at the IDE, lamenting hours of lost work due to lockups in the SV.IDE editor. FWIW: During a Devcon I was able to find a set of reproducible steps to show Diego the lock ups, and SV eventually shipped a fix for that particular problem, but I had moved on.
FWIW I compile directly from my editor and navigate to errors using short cut keys, or double click on the error in the output pane. The errors are nicely labeled in the source.
I used to use UltraEdit, but switched to SublimeText (ST) a decade plus ago, I also recommend VS Code (VSC). ST and VSC both have Multiple cursors, amazing navigation, HOT freakinâ EXIT, and a RICH pool of packages to enhance your experience that are quite frankly game changers in terms of pleasure and speed of coding.
Having the ability to jump to changes since your last commit speeds me up. Which brings me to GIT. With an APP IMO you can and should use GIT. The problem is that with an app the âtruthâ is in the binary APP, so weâre forced to TXAs as the surrogate, not generated source. Part of the problem is there is a lot noise a TXA (made worse by random changes by the ide). Reviewing blames and diffs is not just harder itâs downright difficult because you donât see code in itâs generated form.
Whereas GIT works so well with hand code.
Yes the SV.IDE has code completion that understands the properties and methods of classes in scope, assuming it actually works - which has NOT been my experience. Also I find the SV.IDE code completion so very s l o w that I get frustrated with it and just turn it off. Whatâs more (the last I checked) the code completion doesnât know about the parameters for the body of code youâre working on - WTF. Heaven help you when youâre crafting a new class, and things are all torn apart where they simply wonât compile yet. All of these situations are so much better with the label completion of SublimeText, it feels like itâs reading my mind, which speeds me up - which is the point isnât it? Sure, I have to know my class properties and methods, but again the navigation in ST is nothing short of miraculous, so looking them up is pretty easy.
Oh and snippets, heck snippets with multiple cursors⌠so so very handy for speeding me up, I use these several dozens of times every day.
FWIW, ST and VS Code do have the ability to provide a true code completion, but that requires someone to write something that explains the clarion language to the editor, and that has yet happen ( I doubt it ever will ). FWIW the syntax highlighting is BETTER in ST than it is in the SV.IDE. There are a few edge cases that the SV.IDE getâs wrong, that have been solved in ST.
Multiple Cursors are so amazing, itâs hard to overstate just how useful they are and how often I use them.
Navigation is a dream, both to finding files and labels inside of the files. You donât even have to know the exact filename or label, theyâre found by typing in letters in the order they occur, but you can skip some⌠so for example Ctrl+P ABW.c will provide you with a list of files that match those letters, such as ABWindow.Clw
Hot Exit⌠this means that any UNSAVED changes youâve made are right there waiting for you when you come back into the editor. Years ago I had a BSOD occur (bad ram), and my unsaved changes were right there when I reopened ST.
6 Likes
In general, I agree with what Bruce saidâŚ
However, I am intrigued by the approach presented by mark goldberg.
In my case, if I want to code a small test program, I do without the app. But I donât see the advantage of doing it in an app that includes UI. Could you please explain your method in more detail. thanks
Wow! Speed, we want speed!
A good idea for a show and tell on a Wednesdays webinar.
How to use external editors etcâŚ
1 Like
What Bruce said. Also, I will plug Capesoft here as I have purchased a lot of templates/classes from Capesoft which is why our software can do what it can do. Itâs always good when customers ask if our software can do this or that, and we can answer yes. I use the appgen for all of my browses and forms. I can handcode embeds in anything. I use the handcode to âwizardizeâ my forms sometimes. Itâs sometimes not easy to find the right embed, so when you find it, make some notes. But youâll always have to handcode if you want your app to standout or be super easy to use.
1 Like
ABC is close to 30 years. My guess is that most of what you mention could be achieved with an updated/simplified approach to classes and templates. Setting class properties in an embed is essentially handcode. I am sure most developers can do without a template prompt for each. Unfortunately, gone are the days when SV had the brains & resources and there certainly is no payback for a 3rd party.
That was a good read, thanks @MarkGoldberg !
How do you design a window without the window designer? Iâm in the process of learning Flutter and Dart, where the windows are designed in code, but the design can be viewed during this process. It must be hard without some sort of visual cue?
Also, I imagine 99% of Clarion developers rely on at least one 3rd party template, can you tell us if you use any of these and if so, how difficult is it to incorporate them into a source code project?
The short answer is âit dependsâ on the product you are trying to integrate.
Before diving into the weeds its worth pointing out that since all a template foes is generate code, anything a template does can be duplicated in a hand-code project. The question is thus not one of âcan it be usedâ but rather âcan it be used usefullyâ.
Lets consider some examples across the spectrum.
Generally speaking products that contain little functionality in the template layer integrate easily. So products which are mostly classes (StringTheory, jFiles etc) work well and often have explicit docs for handcoders.
Thrn you have products which affect just one area of the program. The template does dome work, but that work is easily copied to hand code. Iâm thinking of things like SelfService, Premiere, and so on. Its muxh more work to add these to a hand coded project than using a template, but its doable in an hour. (Basically by generating an example, then moving that to your framework.)
Fundamentally as long as the product uses a class to do the heavy lifting its likely worth the effort if it contains something you need.
(Aside: hand code programmers are often, not always, corellated with folk who dont like using external code so the question becomes moot.)
There is a third group of products which -could- technically be used, but would require more work than theyâre worth. These are things that make heavy use of information available at the generate layer that is not available at the compile layer. For example iterating through dictionary information, or extended screen information, or even information gleaned from the app as a whole.
Sure you âcanâ but why would this be an improvement? I turn on column sorting for a browse with one checkbox. Knowing all the properties to set for that would just be a waste of head-space. (And thats before forward compatibility problems, and other integration problems.)
Indeed templates dont stop you taking this approach already if ypu think its better. If the template interface is too slow for you then go ahead and do what you are proposing - you can already implement say a browse object in a window by hand.
1 Like
For the simple reason that many developers who have valuable/useful classes are not interested or do not have an incentive to also write a template that covers everything in the class. My thoughts are more toward classes from the likes that Mark, Carl etc have mentioned than those of Capesoft products. The goal is replacing a ~30 year old ABC and I am confident you agree that does not look like a profitable market.
Canât agree more about SublimeText!!!
Being a CLIPPER developer on the MS DOS age, using QEdit/TSE editor, before starting with Clarion 5.5, I can confirm all the good words about ST. I met it before the VS Code existence and never could switch to VS Code. SublimeText rocks!
But my day to day work in Clarion is made with the App Gen and Embeditor, and can confirm the problems with the SV IDE and editor. So I use ST in parallelâŚ
I remember there was the Capesoftâs Object Writer to create classes using the App GenâŚ
1 Like