The Story of a Homegrown Clarion Template

The simplest template in my arsenal is the one you’d find most in the code.

I discovered early on it was a good idea to send the (offending) Procedure Name through to the error logging.

_AddError('MyAwesomeProcedure','Stupid Error Subject','Stupid Error Body');

After too long, I decided to do something about always having to string type as a parameter to the error logging function.

But what to do? You’ve probably already seen what took me at least 2 years.

changing_strings

I wrote a little template that places a local var (_:ProcedureName) into every procedure in the app (globally added). This var is populated with the Procedure Name, and now i never have to change that parameter.

#!=========================================

#!= Logging Template

#!=========================================

#TEMPLATE(SA_Logging,'Stus Templates: Logging, Errors and Otherwise'),FAMILY('ABC'),FAMILY('CW20'),FAMILY('Legacy')

#!

#!

#!-----------------------------------------------

#!-----------------------------------------------

#EXTENSION(Global_GetProcedureName,'Global Template to add the GetProcedureName template to each procedure'),APPLICATION(Local_GetProcedureName)

#DISPLAY('==========================================')

#DISPLAY('Global Template for GetProcedureName functionality')

#DISPLAY('==========================================')

#PROMPT('Disable GetProcedureName Code',CHECK),%NoGPNCode,AT(10)

#AT(%DataSection)

#IF(%NoGPNCode)

#ELSE

_:ProcedureName string('%Procedure')

#ENDIF

#ENDAT

#!-----------------------------------------------

#EXTENSION(Local_GetProcedureName,'_:ProcedureName == the Procedure Name'),PROCEDURE

#!-----------------------------------------------

Simple. Sweet. Saves me heaps of time.

Drop-Down Listbox vs Select Window

The first System I wrote on my own is still alive and moving forward.

The problem I face (which most of you would have), is that my own methodologies have matured far beyond where they were 4 years ago. Actually, even 1 year ago, but that’s beside the point.

When I wrote the bulk of this System, I didn’t know about the Select Button/Window paradigm for getting a field value. I only knew about the DropDown Listbox/Combo.

Both have an argument for use.

The Combo gets to be right there, on the same window. This is a powerful thing, too often underestimated. The User (in my experience) likes that the information is at their fingertips.

The problem is (in Clarion) that large record numbers make this a daunting task for much of the data we look at. Of course, that’s why I wrote an Autocomplete template (Requires Subscription) to make sure a set number of records were put into the buffer at one time (and fixing a couple of other things too).

The Select paradigm is cool. I like it, because it flows in my brain a lot better (this is most often not actually what makes sense to the User, even though sometimes the functionality is better). You type the value into the entry .. if it doesn’t exist (on tabbing off, or pressing the select button) a Select window is brought up. The way I’ve learned it, you can then have further Insert/Change/Delete functionality on the Select window, giving he User full access to that particular (and others) file. Back on the entry, when opening up an existing file, it’s easy to change the value either by typing, or lazily (better sometimes) by mouse-clicking on the Select button and then finding the value in the listbox.

Of course, the same problem that plagues the Combo is the problem here. Large record numbers make it harder to navigate. Of course, there are ways to push through this. Just requires some clean and clever thinking about the interface, searching, and selection functionality.

Phew. What started out to be just an Aside post has turned into something a little longer.

The question I have this morning is this .. which do you prefer? Drop-Down Combo/Listbox or Select Button/Window? Is it situational, or do you consistently use one or the other?

Cheers,