I have a datasource stack "stkA". It contains the fields from a table in the database, 2 computed fields defined as A0, and 1 computed field defined as stack of A0 named stkA.AppID. I want to do this because on my form I'm using 1 combobox to select the the current row in stkA. Also when a particular row in stkA is selected, there is a 2nd combobox where other values can be selected for that particular row of stkA. I'd like to store those values for the 2nd combobox in stkA.AppID. I see the stkA.AppID field in Project Explorer but when I go to set the List Souce of the 2nd combobox, I only see the datasource fields and the 2 A0 computed fields but not stkA.AppID. Can't a computed field of "stack of A0" or even "stack of A15" inside a datasource stack be used as a List Source for a combobox? I know I can just declare a separate stack of A0 elsewhere by itself and not have it associated with stkA and that will work as a List Source of the 2nd combobox. But I thought it would be nice to associate the AppID field with stkA to make the code clearer. I like to go with a more OOP-like solution if possible. Am I stuck with having to use a stack variable separate from stkA? Here's some code:

infer servers.servers.SRV_NAME into stkA;
compute stkA.Contact / A0;
compute stkA.Phone / A0;
compute stkA.AppID / stack of A0;

I'd like to use stkA.AppID as a List Source for a combobox.

Thanks

A stack is only 2 dimensional, what you are looking for is a 3 dimensional or hierarchical stack.

It depends on your data source structure as to how best to achieve what you want.

A stack having only 2 dimensions is not less OOP-like, but how you link the stacks together can help the code be more readable/understandable/reusable. A separate stack of a0 will not help for you directly here i would guess, I would tend to have 2 stacks, one of SRV_NAME, one of SERV_NAME and AppID, then copy from the second stack to a stack for display, otherwise you may end up with duplicate entries.

I would tend to use a stack of a0 for single items not having a direct relationship with other data, like currency, number of items, weight, or single item selections that then cause other data to be retrieved.

I have to agree with Alan on this. There are somethings that you can accomplish with Maintain that I have never done, like adding a stack to a stack. I find that using a separate stack, and then equating the selection to a field in the first stack is just easier to follow and debug.

If you do want to persue this, look in the Maintain manual under the DESCRIBE command
(WebFOCUS Maintain Language Reference V7.1.3 > Command Reference > DESCRIBE)

This explains how to create classes, etc... To be honest, it is not something that I have done.

Mark

As Mark brought it up, classes are the most excellent way of using maintain in an OOP manner.

The DESCRIBE section of the documentation and training course does cover this, but the examples are a little weak I found when running training courses, so a little experimentation may be needed, but the benefits can be very worthwhile. I have used this a few times now and with a little patience it does come naturally.

I actually started looking at the documentation on classes today but I'll probably stick with using separate DECLAREd stacks like Alan suggested and I've already been using. I have a deadline for this application so I'll be going with the quickest solution at this point. Thanks for the responses.