Set the PAGELIST propertly on a dropdown combo, with the style set to 'Dropdown List', to a value of (-1).

Set up some contents in the list, eg AAA,BBB,CCC

Make the form into a multipage form, keep the vertical scroll bar.

Enter 'A' in the dropdown, as you would if you are entering a new code.

Change pages via the scroll bar, as you would using a tab folder.

The contents of the control changes to the first match in the list.

We have a number of screens like this, eg staff names.

The code is initials.

If you enter a staff of say SMN, and then try to enter another with initials of just SM, then it changes the code.

It seems like a nasty bug.

Does anyone know of a way around this.

Colin,

I've setup a little form based on what you have told me. I'm not sure I'm seeing anything I shouldn't be seeing though. Can you give me a little more information on what you see and what you would like to see? I just want to be sure I'm doing this correctly.

Thanks…

Blaise

All I had was one control, being a dropdown list combo.

Ensure the middle radio button is set on the properties, for Dropdown List.

Set up some text, making sure it at least two characters long.

Make the screen have two pages.

In the create event set pagelist to -1.

When you run it, enter part of a valid code in the dropdown, eg first letter.

When you page down it changes.

Hope this helps, if not please advise Email and I will send form.

Maybe Blaise is confused because Colin says

Ensure the middle radio button is set on the properties, for Dropdown List.

At least in 3.61 the middle radio button is "Drop down" and the bottom one is "Drop down list". Blaise - Colin means the one marked "Drop down".

Well, of course he does, because what Colin wants is the kind of box where the user can choose between selecting from a list or to write in a new value.

And that particular case where he has a problem is when he writes in a new value that matches the beginning of a value in the list.

I.e, the problem occurs only if he has a multi-page window and the combo box occurs on every page (PAGELIST=-1). I've tried it here, Colin, and I get the same problem, if it's any comfort.

- Oystein -

Thanks for explaining my problem for Blaise, and spending the time trying.

Any ideas of how to resolve…

Colin,

It seems the problem is with that PAGELIST -1 setting and nothing else. Until today I assumed it was that in combination with one particular other thing. But I assume that you've been aware of this all the time. The problem shows itself when you change from one page to another, no matter where the focus is (in the combo box or elsewhere) and no matter how you change page (I tried with a PAGE message instead of clicking the scrollbar).

I think you should ask the boys who know what's under the hood. So what about it RevSoft guys - isn't this a bug? What's the workaround?

If I had to fight this alone I'd consider

(a) having distinct copies of that combo box on each page and program the stuff to keep them in synch. I don't know if only one of them should be data aware, so I'd experiment a little with that.

(b) building a drop down combo from scratch - I think perhaps from an edit line, a push button, a simple list (that must start out being invisible) and some programming. And then set the PAGELIST of all to -1. And promise not cry if it failed.

© redesign and use MDI with maximized children instead of a multi-page window. I know that sounds like a radical move, but at least in the new app I'm starting to write now I'll use that approach. I discussed the interface with Carl Pates at Sprezz and he convinced me.

I've never really tried (a) or (b), but I'm sure there are other developers out there who have.

- Oystein -

Colin and Oystein,

I'm sorry for such a delay with the answer – this was not an easy thing to trace. What I found out is that the bug is in the Windows –COMBOBOX control itself changes the text when processing WM_MOVE message. To prove this you can do very simple experiment: place the combobox on a form and make the following code to execute

  .COMBO_1-]SIZE=.COMBO_1-]SIZE

which is to say

  set_property(@window:".COMBO_1", "SIZE", get_property(@window:".COMBO_1", "SIZE"))

You will see the same effect that you reported earlier.

The explanation why this happens with PAGELIST is that when you change the page in a multi-page form, what really happens is that the client area of the form scrolls but all the controls don't move(relative to the client area). The only controls that do have to be moved area are the ones that we want to appear fixed on a form – the ones with the PAGELIST property set.

I considered intercepting the WM_MOVE and WM_SIZE messages for the combobox control and restoring the text afterward, but I don't feel comfortable putting this logic to such a generic layer (at least at this moment, when we are going "gold" with 3.7). For now, the workaround I would suggest is to intercept the PAGE event on your forms with "fixed" comboboxes, save the text, forward an event and restore the text.

Gene

View this thread on the forum...