Hello all:

I have an EDITTABLE in which I have created an OPTIONS quick event. The quick event calls a stored procedure that passes a series of parameters to that stored procedure.

Can someone tell me how I can access those parameters during a GOTFOCUS or POSCHANGED in that EDITTABLE? I can xlate out to the compiled window and I see the parameters buried pretty deeply

in the record, but even using the SENL on window structures I just can't seem to grab it. Is there anything similar to ORIG_STRUCT that might store this?

Thanks much,

Mike O.

Mike,

I see.

Hmmm. There's only one OPTIONS thing for the whole edit table. Your procedure cannot know which columns in the edit table that OPTIONS is meant for unless you as the developer tells it so. You say you somehow stored that information in the quickevent parameters.

I'm certain somebody (like Sprezz or Mr Bakke) can tell you how to get at that information. But I think I would solve the problem in a different and simplistic way: I would make a new, invisible companion control (edit line or box) with a name derived from the edit table's name in a systematic way (e.g ET_INFO for an edit table ET), and put the information in the text of that companion control - at design time. (If there were many edit tables in my window I'd tag each piece of info and have them in one single control.) The procedure must simply check if there is an _INFO companion to the edit table and get the info from there. (If no companion were found the procedure might default to no buttons or buttons for all columns.)

- Oystein -

Hello Oystein -

I believe your method would work quite well… just wish I would have thought of it three years ago! We'd have to go back and update dozens (if not hundreds) of edittables at this point.

Mike O.

Hi Oystein - thank you for the detailed response.

The problem is that I need to know the parameters in *advance* of the stored procedure actually being called. This lets me turn a button on (or off) so that an end user knows there is an OPTION available in that column. In an edit line the code is basically:

ss=get_property(ctrlentid,"ORIG_STRUCT")

events=ss

opts=index(events,'OPTIONS',1)

if opts ] 0 then

*** turn button on, we have found an option event

etc…

In an edit table, the system thinks there is an option for every column in the table with the code above, so the button always stays on. In the parameters I'm passing the column numbers with OPTIONS to the stored procedure (basically so that a correct pop-up is called). If I can get to those parameters during GOTFOCUS/POSCHANGE, I can turn the buttons on and off accordingly.

Make sense?

Mike O.

It's in the appropriate ControlSemantics@ text value/sub value/multivalue/field for the control in question.

Just $Insert OIWIN_Comm_Init and explore.

The Sprezzatura Group

World Leaders in all things RevSoft

Mike,

I think I would solve the problem with some user defined properties and some code.

I have an EDITTABLE in which I have created an OPTIONS quick event. The quick event calls a stored procedure that passes a series of parameters to that stored procedure.

That stored procedure could store the parameter values in user defined properties. The way you describe your scenario it seems these values sort of belong to the edit table. The natural choice would then be to have the user defined properties as properties of the edit table. Say your edit table is called ET and one of your parameters is in variable Param. Then do

UnUsed=Set_Property( @Window : ".ET", "@PARAM", Param )

to store that parameter's value with your edit table. (You can call your user defined property something else than @PARAM if you like. Just use any sensible name starting with @.)

Can someone tell me how I can access those parameters during a GOTFOCUS or POSCHANGED in that EDITTABLE?

Now your GOTFOCUS and POSCHANGED code can retrieve the parameter's value with

Param=Get_Property( @Window : ".ET", "@PARAM" )

You might also need some code to reset the user defined property to null:

UnUsed=Set_Property( @Window : ".ET", "@PARAM", "" )

I cannot say where that code should go without more details about your scenario.

If you need your OPTIONS, GOTFOCUS and POSCHANGED code to work with any edit table, not just ET, you can pass the name of the edit table in the quickevent parameters by using the special '@SELF' parameter.

- Oystein -

Mike:

User defined properties are the way to go.

I think that if you load initial values on create of the form,

use the windows activated / deactivated events as well as gotfocus on the controls, then you will get what you want.

For your existing windows,

have a naming convention for your User define propertyies, e.g

'@':Ctrl:'_':Event:'_Params'

then, during the create event of the window, get the orig_struct or use the windows common, parse the quick events to load the User defined properties. Have all your other event logic use the values from the user defined properties loaded at create.

IDE Support for user defined properties is something we want to do.

OI 7.0 has some cool logic in it to support object oriented setting and getting properties, but the visual tools to support it are not ready yet.

You can make our own property manager with a table named control_properties, keyed by window*Control, with AMV fields for property name, property value. Have the create event of the form walk the controlmap, xlate the property records, set the properties.

Bob

Mike,

I have met the same problem in various guises. One has a general procedure that needs to find out something about particular controls, or about the window as a whole. The desired information is static, so in prinsiple it can be set at design time, but there is no suitable place to put it. Or the information is present, but not available without special knowledge.

My suggestion will work of course, but it is sort of cheating. A different kind of cheat is when you put information in the name of the controls. E.g, in your case you could name a 5 column edit table ET_10100 to indicate that the 1st and 3rd columns have options (1=options, 0=no options).

Hey! Do you know what we really need? User-defined properties that we can set at design time! Hope the Revelation guys are reading this.

- Oystein -

View this thread on the Works forum...