Template for generating column equates for ABC browse

Instead of using hard-coded numeric constants for column numbers in code for manipulating your list control columns, it is better to use an equate for the column number.
Hard-coded column numbers can become incorrect when new columns are added or columns deleted or reordered in the list format.
I have uploaded a small example template that automatically generates equates for the columns in your list control. Using the use equates means your code won’t need to be updated when the order of your list control columns change.
So instead of coding something like this:

IF BRW1.ILC.GetControl(){Prop:Column} = 3
  !! do something

instead use

IF BRW1.ILC.GetControl(){Prop:Column} = BRW1:FieldNo:CUS:LastName
  !! do something

You can get the template code on GitHub:


A Clarion limitation of PROP and PROPLIST is you cannot get to the #FIELD() or FROM(Q) at runtime. A template like yours could generate User Defined properties (added 10/27/2015 in C10.11975) with that information. E.g. given this LIST:


Template can generate these properties




Might need to know the Parents:


I tested the above code showing a message:

 Message(?BrowseEmpTypes{'#Field',4} &'<9>'&  ?BrowseEmpTypes{'#FldUse',4} & |
         '||'&?BrowseEmpTypes{'#From'} &'<9>'&  ?BrowseEmpTypes{'#FromUse'} ) 

The UDFs are nice because the scope is for any code that can see the Window so beyond the main any Routines and Classes. If we can agree on the {‘Names’} then any template or class code can use them. A name of {"#FIELD"} seems obvious and logical. I think we need the USE Address to be able to assign an ANY and operate on the variable.

So just an idea…


Similar to Bruce’s NAME() attribute thread.

I remember back in the 90s, there was talk on the CI$ forum about creating an EVENT repository, but managing 3rd Party folks is like herding kittens. :slight_smile:

FWIW,on a semi-related note,
I use WHERE() when writing hand coded PROP:Formats

For example (scroll to the right in the source below)

SELF.ListFEQ{PROP:Format} =                                                                                                     |         
                '11L'     &  'FIY' &                                 '@p_pB@' & '#' & WHERE(SELF.Q, SELF.Q.Tag          ) & '#' |
        &       '20C'     & '|Y'  & '~Area~'              & 'L'    & '@s4@?'  & '#' & WHERE(SELF.Q, SELF.Q.Wall_Area    ) & '#' |
        &       '37C'     & '|IY' & '~Shape~'             &          '@s6@'   & '#' & WHERE(SELF.Q, SELF.Q.Shape        ) & '#' |
        &       '145L(1)' & '|FY' & '~Wall Description~'  & 'C(0)' & '@s30@'  & '#' & WHERE(SELF.Q, SELF.Q.Description  ) & '#' |
        & '[' &  '5C'     &  '*Y'                                  & '@s1@'   & '#' & WHERE(SELF.Q, SELF.Q.Out_BoxTrans ) & '#' |
        &       '47L(1)'  & '|Y'  & '~Outside~'           & 'L(0)' & '@s11@'  & '#' & WHERE(SELF.Q, SELF.Q.Outside      ) & '#' |
        & ']'             & '|'                                                                                           &     |
        & '[' &  '5C'     &  '*Y'                                  & '@s1@'   & '#' & WHERE(SELF.Q, SELF.Q.In_BoxTrans  ) & '#' |
        &       '47L(1)'  & '|Y'  & '~Inside~'            & 'L(0)' & '@s11@'  & '#' & WHERE(SELF.Q, SELF.Q.Inside       ) & '#'

I like that a lot for flexibility in designing Q versus List.

Too bad the ## has to be numeric. An idea for you to use the LIST formatter would be to stick your #Where()# code into the Default Tip then in your final code change the Q’‘xxx’’ to #xxx#. But… the Q’’ currently breaks the window previewer, it stops generating Q fields. I have reported to SV.

 FORMAT('21C|M~Code~L(3)@n3@Q''WHERE(SELF.Q, SELF.Q.Tag)''' &|
        '140L(3)|~Employee Type~L(4)@s30@Q''WHERE(SELF.Q, SELF.Q.Wall_Area)'''     &|
        '27R(3)|*~Normal<0DH,0AH>Hours~C(0)@n4.2@Q''WHERE(SELF.Q, SELF.Q.Shape)''' &|

After S&R :

 FORMAT('21C|M~Code~L(3)@n3@#'& WHERE(SELF.Q, SELF.Q.Tag) &'#' &|
        '140L(3)|~Employee Type~L(4)@s30@#'& WHERE(SELF.Q, SELF.Q.Wall_Area) &'#'     &|
        '27R(3)|*~Normal<0DH,0AH>Hours~C(0)@n4.2@#'& WHERE(SELF.Q, SELF.Q.Shape) &'#' &|
        '29C|~Certified~@s1@'                               &|

Seems more logical to use PROPList:FieldNo rather than mess around with the FORMAT string like that.

I store a Reference to the Queue in a user defined property ‘FromQ’ of the LIST (code below). I can then use TUFO Interface, WHO, WHAT, and PROPLIST to figure out the Q and List #Fields at runtime, so there is no need to store the individual #fields.

I would like to avoid this user property if anyone knows a way to get a reference to the FROM(Q)??

Maybe a RTL export or PROP I missed. Simply using ADDRESS(Q) does not work, maybe a reference to the “group” of fields.



      FromQ &= (?List{'FromQ'})  !Get List FromQ 
      Now use WHO(FromQ,#) ... WHAT(FromQ,#) ... TUFO

      Ref.Q &=FrmQ 
      FEQ{'FromWho'}=CHOOSE(~OMITTED(NameQ),NameQ,'Queue' & Ref.L)

Try this

qRef  &QUEUE
  threadno = THREAD()
  qRef &= INSTANCE(q, threadno)

Thanks! I forgot about that.

INSTANCE() does return a &Queue reference. The help makes it clear … sort of … “internal structure = reference” is clear from the example code:

INSTANCE can be used instead of the ADDRESS( ) statement when ADDRESS( ) is not valid or available (e.g. FILE and QUEUE structures). ADDRESS(QUEUE) is a legal call, but it returns the address of the queue’s internal buffer. On the other hand, INSTANCE(QUEUE,THREAD()) returns the address of the queue’s internal structure.

For example, given the following QUEUE declarations:

SomeQueue QUEUE
 QueueRef &QUEUE

The following assignment is correct:

QueueRef &= INSTANCE (SomeQueue, Somethread)

while the assignment shown below is not correct:

QueueRef &= ADDRESS (SomeQueue)

and sets the QueueRef variable to the wrong value.

You could store the address of a named GROUP/OBJECT that has a &QUEUE as a member.

Would be nice to get at the &QUEUE in the PROP:FROM, though.

Hi Carl -

The stuff in abllist.int looks interesting. It doesn’t give you a queue reference, but you can do stuff with the listbox. It’s been around since at least C5.5, but it’s changed a bit since then.
I wonder if that could help with your window interrogation stuff. I’ve never used it.

PROP:FromPtr looks interesting too, but I’m not sure what it points to yet.

PROP:FromPtr looks interesting, but it looks to me like it returns an IMappedListContents INTERFACE which I concluded based on looking at ABLPROPR.CLW:

 IF (lFeq{PROP:fromptr} <> 0)
    SELF.From &= CreateListboxContents(lFeq)

CreateListboxContents     PROCEDURE(SIGNED Feq),*IMappedListContents

I don’t see anything useful in that interface, it looks to be for making web pages. There is also “IListboxContents INTERFACE” but nothing obvious jumps out. There is no use of that and a comment “!Internal interfaces to the list boxes - not supported”

I guess one would need to play with it to find out whether it’s useful.

It might have been created to create web pages, but oftentimes the original purpose of something doesn’t end up being the primary usage.