Hi Joseph,

I think it's caused by the way how navigation in dropdownlists are implemented:

If you hit a key, the next option starting with this character is selected.

So if you enter ABC,
the first option starting with "A",
then the following starting with "B",
and at last one starting witch "C" is selected.

Perhaps if you change the dropdown list to a combobox, you can get your serlection.

Uli,

Yep, the combobox widget works fine with the macro.

However, I'd rather not change all the dropdownlists within the application into a combobox.

Is setting the value of a dropdownlist widget via a macro not possible?

thanks,

Joseph

Hi Joseph,

but you can set all dropdownlists to comboboxes the easy way via usys.ini

[widgets]
; Logical to physical widget mapping
EditBox=ueditbox(font=editfont;autoselect=on)
CommandButton=ucmdbutton(tooltip=on;font=buttonfont)
DropDownList=udropdownlist(font=listfont;forcefit=on)
Combobox=ucombobox(font=listfont)
 

just change the DropDownList line to:

DropDownList=ucombobox(font=listfont;forcefit=on)

Uli,

We changed the widget settings before on the ini. So, I'm familiar with this mechanism.

I was more concerned about the change in behaviour from the dropdownlist into a combobox,
i.e. we might not always want to have an entry portion to a dropdownlist selection.

But I'll keep this in mind as a backup solution.

thanks again,

Joseph

Ummm, why?

If you set the dropdown list variable to the relevant value, it is automatically selected.
To fire the Value changed trigger, include the following at the top of the trigger, and then just call it.

call <$fieldname>_<$triggerabbr>

entry <$fieldnname>_<$triggerabbr>
....
your code
....
end

where you feel you need the macro, then

your_dropdownlist=relevant_data
call your_dropdown_list_valc

If you want to work from the representation rather than the id of the valrep, you can parse the valrep until the representation starts with your value, then pull the ID.

I think you missed the point, I'm trying to set-the-value-of-a-dropdown-field via the macro.

Here's some background information.

We have a "generic" list form, where the user can setup a sql to return any number of columns from any number of tables based on any condition
(e.g. list of accounts with late payments, or a list of equipments due for maintenance, etc.)

The user can then select any item/s from the "generic" list form, and call any form within the application via a [Button].

So, here's where the macro comes in. In some cases, besides passing the relevant key fields, we would want the the [Button] to do-something-more.

For example an [Approve] button would bring up the transaction screen, retrieve the relevant transaction, set the status (dropdownlist) to the "Approved" state, update the dates, update the user id who made the changes, all of which is done via a macro script parameter that is passed to the transaction screen.

The problem is that the [Approve] button macro does everything but set the status (dropdownlist) to the "Approved" state.

Note: The button themselves as well as the macro script parameter are configurable, i.e. these cannot be hard-coded from the "generic" list form.

I didn't miss what you wanted to do, per se, which is why I asked why you wanted to do it. Because the other method is good if you can do it.
You could try macro'ing the downarrow key instead of typing the correct answer, but that would be fraught with fraughtness if they change the data or the sort order in the dropdownlist.

We did try adding "^CURSOR_DOWN" to the macro, but this only opens up the dropdownlist selections.

Instead of navigating through the dropdownlist selection entries, each "^CURSOR_DOWN" re-opens the dropdownlist selections.

So, you end up with an open dropdownlist selection with nothing selected.

another option:

try activating the userkey trigger via your macro, think this may be an option, but this works only if calling the userkey is the last one in the sequence.

On the other hand; if you can separate your actions in one filling field values (getlistitems/id/field) and another stepping through the fields, it may be an option: if you alreday know the field value prior to the retrieve; wouldn't it be better to have this one hit only? Juste enter the first character and you have it selected.

Uli,

I think I see what your getting at, pass the field values into a parameter separate from the macro script.

We would have to pass the primary key fields along with the macro script, which includes ^RETRIEVE, and ends by calling the user key trigger (^USER_KEY^065^009), which in turn, completes the transaction updates by loading the "other" field values parameter.

This might actually work.

thanks,

Joseph

Ps, we might also include another "macro field" as part of the other field values parameter.
When the "macro field" is provided, it would then perform another macro command, to perform additional functions (e.g. ^DETAIL on a command button) after the transaction updates is done.