Is there a way to copy a QUEUE from a CLASS into a procedure to make LIST boxes easier to setup?

So I have a class, with some Type’d queues and referenced Q’s with the data. I’d like to display them in a list box, but there doesnt appear to be an easy way to create a list box control which populates the class q fields to columns in the listbox control.

Am I missing something or do I have to create a copy of the q in the local procedure in order to then be able to populate the fields in the list box control?


The thing that matters is making sure the fieldno of the queue column matches the FieldNo property of the listbox column.

The notion of populating a field is more for appgen stuff where the queue itself is generated.

In your case, you have a pre-built queue. What field you select for populating in the listbox formatter is kind of irrelevant. Just make sure your fieldno of the listbox column matches that of the queue field.

Hi Richard,

The list box control can be assigned to any queue using prop:from

?CarsList{prop:from} = WorkQueue

Once you have the queue assigned to the list, then it’s a case of formatting the columns for the list control to match the fields. You can be as simple, or as complicated, as you like here. In the simple case all the columns can just be simple, showing a value, same width and so on.

In the more complicated case you can change the field order in the queue, the picture, deal with icons, styles and everything else. It’s all settable at runtime (see property.clw, proplist: equates )

1 Like

I am aware of this, because the built in/shipping templates add 4 additional fields to hold the info for things like colors and the list box formatter is usually set to auto instead of the fieldnumber of the q.

Thats what I’m doing at the moment, and because my q’s start off from a Type’d queue, I have one list box switching between multiple queues which have been spawned from one of the Type’d q’s but I want them to have their own listbox in the app

?CarsList{prop:from} = MyQ1
?CarsList{prop:from} = MyQ2

I have a few Type’d queues in this class and from an appgen user perspective, it would be nice I think, if there were a quicker way to utilise these class q’s in the appgen. I know we can easily do hand code in the appgen, but it would be nicer if the appgen could link up with classes a bit more, pulling in info from the classes, like displaying the class variables in a way they can work with screen controls.

Another example, in the appgen, if I Esc out of a procedure, it pops up and asks me if I want to save changes. If I’m writing a class and have edited a method, and then build and compile an app with that class, it would be nice if the appgen could work with the ide and other instances of the IDE when spread over multiple monitors, to recognise a source code file has changed but not been saved, because that would save some unnecessary posts :grinning:eg How to access class properties from a parameter prototype without &reference assigning it but Assert fails!?! - questions / tips - ClarionHub

Anyway I thought I’d ask…

Thanks all!

I don’t understand what you mean here - sorry, my bad, but I’m not following…Perhaps try again?
like, I’m not sure what assigning 2 different queues to the same list control (?carslist) is supposed to do?

agreed. The window designer does not go into the class. So assigning a class property to a list box is done at runtime. I usually put that code into the class, and then just call in a method with the control number;


Then in SetList set the prop:from and the properties and so on.

In a single IDE instance it notices, and saves the file, but there’s no communication between IDE’s. Might be nice, but it ain’t gonna happen I don’t think.

So currently for brevity, testing & laziness reasons I have one listbox in the appgen on a window I can control in the window designer.

I have two buttons which swap the source for the ?listbox{prop:from}. This is just to make sure the data was in the queue without having to use the debugger.

Ideally for end user reasons, I’d have two listboxes and format them in the same way I format browse class list boxes that use views of files from the dct. I am aware I can create views in the dct, but I dont want to fill up the dct too much, especially when thinking about the number of views and stored procedures that can be imported into the dct from db’s like MS SQL server and I have to bear in mind I wont be developing these apps in the future, someone else has to do that, so I have to make their life easy in order to get them up to speed and thus usefulness.

Now I’ve already built a procedure extension template which makes it easy to builds views at the procedure level instead of defining views in the dct which then appear in the procedure file schematic window, but I think I’ll need to do something similar to bring any variables & queues defined in a class source code file into the file schematic window so they are all in the same place in the appgen, instead of hunting for them in source code files. I hate memory tests… :wink:

Ok so thats how you are doing it, which is a different way to the way I was thinking of doing it, ie using the file/table schematic window in the appgen. There is no right or wrong way here, but when I think about having to hand over the apps for someone else to maintain, I think my way would be easier and quicker to get them up and running, but I could be wrong because I am well aware the education system loves their flat file notepad programming ways of teaching. Its a cheap form of teaching imo.

I think some of this is the difference between those who want to hand code and those who want to use the appgen. I like the appgen because it enforces rules and reduces mistakes and provides a degree of structure and uniformity to the generated code, which makes future changes quicker, easier and simpler, and that equates to a higher hourly wage, which my fixed price jobs that have equated to as much as to £5k per hour using this method has already proven. Months of work condensed into hours and you yourself do say, work smarter not harder… :wink:

So, first things first- you can’t declare “views” in your dictionary. If you are developing against SQL, then server-side-views can be added to the dict as tables.

Secondly, the number of tables in the dict would not scare me much when taking over an app. custom templates scare me a lot more :slight_smile: . Understanding that the dict contains 20 tables or 200 or 2000 tables takes no effort. Reviewing custom templates is a lot harder because first I need to know the template language (which, granted, I do) but also because reading and debugging templates is harder than zero.

There are other reasons to keep the number of tables in the dict sane - but I would argue comprehensibility is not one of them.

But let’s not get distracted from your actual point;


These are client-side Views you are generating. Things you declare in the dict would only be server-side views. The two are quite different, despite having the same name. so this isn’t an either-or situation, it’s different things to achieve different things.

yeah, it’s a slippery slope. You solve one problem (reducing number of tables in the dict) by creating what is effectively a custom “browse”. So you create a class that replicates all the features of the browse class. But you want the queue to be “internal” - but then you have another problem where the IDE can’t see your Internal queue.

so you have to expose your queue to the Data pad, so the user can select fields for the list box formatter.

At this point I would suggest adding the Queue TYPE to the data pad. Then select the list formatting from that. As long as the TYPE matches the Queue in your list box, and you set the Prop:From, you’re fine.

I’m not sure this really solves the problem for the person who is maintaining this, but since you are already off the beaten path, which means the new developer has a lot more to learn anyway, I’m not sure it matters. Ideally if you are wanting to make it “easy for someone else to maintain” then I’d recommend doing pretty much everything (as much as possible) with the standard Clarion tools, and common, well understood, accessories. As backwards as it sounds, the more clever code of yours that you add, the harder it is to maintain.

It’ll depend on their skill level. Clearly the easiest hand-over is;
“Here’s a bog standard Clarion app, nothing special, off you go.”

It also depends on what sort of changes they’ll need to make. Saying “the list is formatted by the class” means they can ignore it - unless they need to change the format. (At which point something like RunScreen makes more sense - back to nothing for them to do.)

If they are needing to change list formats, then either they’ll need to learn your technique, or learn how to override the class.

As you say, there’s no right answer here. You don’t know who will maintain it, or what they’ll need to change.

100% . But it’s not really “appgen” doing this - it’s that the user is working with a “known template set”. It’s the templates that provide this uniformity, not “appgen”. (seems like the same thing I know, but consider that a Legacy programmer may struggle with the ABC template set or vice versa.)

Well no because template that generates views in the procedure that appear in the file schematic window can work with the standard clarion ABC viewmanager, so Im being lazy here by not having to reinvent the wheel. Its written so I can roll my own code to process the view or I can bolt it into the viewmanager and then take advantage of what is already built in.

I havent finalised what route I’m going to take yet, mirroring the queues in the local data declarations is an option I am currently considering, but I’m lazy, so I’m thinking can I use #RunDll that will call a dll which will read the class and bring the class queues into the local data declations for me, in such a way I can still use the ABC viewmanager if I dont want to roll my own code as another clarion developer.

I’ve worked on a few different systems in the past beit other sole Clarion developers, or teams of clarion developers who have handed a project over in its entirety to sort things out for them. “It all varies” is probably the most politically correct way of defining different ways requirements have been met, but like you say, I have to recognise and work with these different styles of coding whilst also trying to get management to understand problems and risks in ways they understand.