by Unlicensed Unknown user
First, some housecleaning. Mike Hanson pointed out that I needed a couple of additional lines of code (5 and 6) in my TakeAccepted handler:
...
But there's another problem with the original method - I'd neglected to return a value, yet the Register function docs specifically say you must return one of three values from the function:
Level:Benign | Calls any other handlers and the ACCEPT loop, if available. |
Level:Notify | Doesn't call other handlers or the ACCEPT loop. This is like executing CYCLE when processing the event in an ACCEPT loop. |
Level:Fatal | Doesn't call other handlers or the ACCEPT loop. This is like executing BREAK when processing the event in an ACCEPT loop. |
I always want processing to continue normally, so I'm returning Level:Benign.
...
to the Conditional Compile Symbols in the project properties:
This probably isn't something you'd do with your own classes; in fact there's a good chance that when you write classes you'll compile them for each app. That's how I started using classes also, but eventually I ran into problems when sharing classes between apps (usually DLLs) in a large, multi-DLL system. You can read more about the ClarionMag Library compiling approach in Look Ma! No project defines!
...
The second is the Long field following the field that will be used as a checkbox. So I did have to go into the list box formatter for the browse and add a local variable and configure it as having a checkbox:
In my simple hand coded test I defined the queue myself and added the extra Long field. In the ABC browse, enabling the Icon property caused the templates to generate that extra field.
...
I found the cause in the browse's SetQueueRecord method:
The available icons are determined by the class's Initialize method, using PROP:IconList assignments. A value of zero indicates no icon at all.
...