To all,

Let me see if I can explain this. I use ComboBoxes in many places to display a popup. To do this, during the Form Create event, I call a subroutine which destroy the ComboBox control and rebuild it to include the data values found in a Table. If you don't do this, value selected in the Popup will not display in the Control. This approach give me more flexible and shows more than the standard dropdown list.

All this works quite well. I just saw a gotcha for me however. In the context of an MDI frame. In an MDI frame #1, I call another MDI frame #2. From this MDI frame #2, I call Start_MDIChild. This child create event calls a ComboBox rebuild routine and everything seems to work. However, values which should be in the ComboBox don't display when a record in brough up. It's as the LIST did not get updated property. As as I can tell (via debug) the LIST is there and property created.

Running the form by itselt works fine. It's only when I calling the form from a differnet level.

I figure there must be something about MDIs that I am missing. My hunch is that I need to do something else when I'm rebuilding a LIST for a combobox in this context. At present, I am passing only the Control and Filename to my Rebuild ComboBox routine, e.g.,

      Control=XYZ"

FileName=CONDITION_FILE'

Build_ComboList(Control, FileName)

I am calling the Child as followed:

winname=start_mdichild(newwin,@window,patid@)

Do I need to pass someother parameters or add some more.

Any suggestions welcome. I'm hoping that it's something simple .

Thanks,

Ray

rayc@symmetryinfo.com onmouseover=window.status=imagine … ;return(true)"

Symmetry Info

Ray Chan ~ Symmetry Info

Ray,

Let me see if I can explain this. I use ComboBoxes in many places to display a popup. To do this, during the Form Create event, I call a subroutine which destroy the ComboBox control and rebuild it to include the data values found in a Table. If you don't do this, value selected in the Popup will not display in the Control. This approach give me more flexible and shows more than the standard dropdown list.

(I've taken a different approach. In general I use edit lines and edit tables in my forms, not combos and list boxes. A certain keystroke brings up a home-made dialog with a combo or list box. Popups can be more clunky than combos and list boxes, but I've tried to make my popup lean and discreet and simple to operate.)

All this works quite well. I just saw a gotcha for me however. In the context of an MDI frame. In an MDI frame #1, I call another MDI frame #2. From this MDI frame #2, I call Start_MDIChild. This child create event calls a ComboBox rebuild routine and everything seems to work. However, values which should be in the ComboBox don't display when a record in brough up. It's as the LIST did not get updated property. As as I can tell (via debug) the LIST is there and property created.

Running the form by itselt works fine. It's only when I calling the form from a differnet level.

What do you mean by "itself"? The child and nothing else, or together with frame #2?

I figure there must be something about MDIs that I am missing.

MDIs seem to have a few undesirable "features". But one common problem is the programmer not being aware of which window is the current one. Many times I've used the @Window variable in a child's handler when I really meant the frame, and vice versa. Stupid mistake, but easy to do. (And sometimes one forgets that a dialog started from the child gets the frame as its parent.)

(Also be aware if you have several instances of the same window running (e.g if frame #1=frame #2, or if there are two instances of the child running). Then you must refer to the windows by their proper instance id, and not just the name. But this has nothing to do with MDI.)

My hunch is that I need to do something else when I'm rebuilding a LIST for a combobox in this context. At present, I am passing only the Control and Filename to my Rebuild ComboBox routine, e.g., Control=XYZ" FileName=CONDITION_FILE' Build_ComboList(Control, FileName)

Could it be as simple as your Build_ComboList procedure assumes the wrong window? Should be easy to see in the Debugger. Or just change the Control parameter to include the window name.

I am calling the Child as followed: winname=start_mdichild(newwin,@window,patid@) Do I need to pass someother parameters or add some more. Any suggestions welcome. I'm hoping that it's something simple .

It usually is.

- Oystein -

Oystein,

…I've tried to make my popup lean and discreet and simple to operate.

Too bad we can't see it.

What do you mean by "itself"? The child and nothing else, or together with frame #2?

Well if I run the form in Form Designer, call it directly from the MDIFrame, it run fine. That is, the value in the combobox is displayed. If the "problem form" is called several levels down, for example, we are running MDIFrame_#1 and from here we call MDIFrame_#2 and MDIFrame#2 calls this form, the value in the combobox will not be displayed although I know that the value is there because 1) the related symbolic shows the correct description; 2) I can see the values being build in debugger; and 3) I can enter a valid entry (which I couldn't if the dropdown list didn't exist). I just don't initially see the value when the form is first brought up.

…Also be aware if you have several instances of the same window running (e.g if frame #1=frame #2, or if there are two instances of the child running). Then you must refer to the windows by their proper instance id…

I looked and looked and I don't think that multiple instance is a problem since I can only bring up one instance of the form within the MDI Frame in question. Plus, my trace thru the debugger doesn't bear this out.

… change the Control parameter to include the window name.

It does.

Any other suggestions for this small but annoying little problem .

Thanks,

Ray

rayc@symmetryinfo.com onmouseover=window.status=imagine … ;return(true)"

Symmetry Info

Ray Chan ~ Symmetry Info

Ray,

]]…I've tried to make my popup lean and discreet and simple to operate.

]Too bad we can't see it.

Well that's how lean it is. You can't even see it.

Actually, you can. See

]]What do you mean by "itself"? The child and nothing else, or together with frame #2?

]Well if I run the form in Form Designer, call it directly from the MDIFrame, it run fine. That is, the value in the combobox is displayed. If the "problem form" is called several levels down, for example, we are running MDIFrame_#1 and from here we call MDIFrame_#2 and MDIFrame#2 calls this form, the value in the combobox will not be displayed

What value is to be displayed?

]although I know that the value is there because 1) the related symbolic shows the correct description; 2) I can see the values being build in debugger; and 3) I can enter a valid entry (which I couldn't if the dropdown list didn't exist). I just don't initially see the value when the form is first brought up.

See if I got it right:

Your child is bound to a table, and the combo is bound to a field X in that table.

You seem to say field X is a symbolic field. But that doesn't fit. Why would anybody use a combo for a symbolic? I hereby assume X a data field.

Then when you run the stuff

- the CREATE handler of your child destroys and rebuilds the combo, and sets its LIST to a new list of values

- the READ handler of your child handler reads in a table row, with a value A in the X field

- this A value is a value already in the combo's new LIST.

Then, if the child is run with frame #1 only, value A immediately shows in the combo.

But if the child is run with frame #1 started from frame #2, value A does not show. You can find it manually in the combo, but it doesn't show initially.

If this is the correct description, I think you can fix the problem by having a little bit of programming post READ, explicitly setting the TEXT (?) property of the combo.

But I have no idea why that frame #2 matters.

Also I have no experience with destroying and rebuilding controls. But I assume you've managed both to destroy and rebuild or else there would be other problems too.

- Oystein -

Oystein,

Well that's how lean it is. You can't even see it. …Actually, you can. See….

Very nice. I have great appreciation for your creativity.

See if I got it right….

Your analysis is on target. You have such an excellent understanding that it tickles me. First, you have to read my English. Translate that into Norweigian (in your head - very fast of course) and then digest this, crunching out various possibilities (in Norweigian) and then spitting out a long detail explanation in a foreign language. Not only did you get this right, but your grammer and spelling was darn good. (I would say perfect, however, but my English isn't that good so I can't really be a fair judge.)

If this is the correct description, I think you can fix the problem by having a little bit of programming post READ, explicitly setting the TEXT (?) property of the combo.

There is a saying that "two heads are better than one." Fortunately, in the age of the internet, they can be across an ocean. Will this really got me thinking so I started playing with the post READ event. In looking at this I saw what was happening and made some changes to fix this problem. In my situation, whenever I was using the combobox to "display" my popup, I would create the valid values for the "dropdown list" in the CREATE event. I always thought that the CREATE event was always the first event to run whenever a form was called. This prove to not be the case. I could see that in some cases the READ event was actually fired first and then the CREATE event. Therefore, as you can see, if the READ precedes the CREATE, the value in the ComboBox would not display because it has not been defined as a valid data in the ComboBox control. Eureaka! So what I did was to modify my programs so that we would build the ComboBox values in the Create and the Read Events (when appropriate.)

So thanks a lot for your suggestion. This small problem is now behind me .

But I have no idea why that frame #2 matters.

Initially, I started playing with calling another MDI frame within an MDI frame to get over the limitation on the number of Menu items you can have. After some experimentation, I started to incorporate the use of MDI frames in other aspect of our App because I found that I could make the interface look cleaner, easier to use, and more intuitive for our users. Of course, I'm still learning. I think that it has advantages. In doing this, I stumbled upon this "gotcha" when dynamically manipulating ComboBox. BTW, I must say that the documentation (TB#2) provided by Sprezzatura was invaluable in helping me understand how to manipulate this sort of stuff.

I have no experience with destroying and rebuilding controls.

Well I know you're not asking for this, but the code below illustrate how easily this might be done for a ComboBox.

Pass it only CtrlEntId and the FileName in questions, e.g, call Build_ComboList(CtrlEntId, "SOME_FILE_NAME").

Build_ComboList:

Struct=Get_Property(CtrlEntId, "ORIG_STRUCT")

If Struct Then

XX=Get_Property(CtrlEntId,'LIST')

If XX Then

* if Values exist don't bother to do anything else.

	Null

End Else

	Open FileName to FileHandle Then

• This Builds the List so values can be used from real popup.

	Done=False$

	I=0

	Select FileHandle

	Loop

	ReadNext ID Else Done=True$

		Until Done=True$

		   I+= 1

		Struct=Id

	Repeat

End

Utility("DESTROY", CtrlEntId)					Utility("CREATE", Struct)			

End

End Else

Null

End ;* is there a struct?

Return

Again, many thanks for your input. Another problem solved thank you Dr. O.

Ray

Ray,

It is really strange that CREATE doesn't run first. It never occurred to me that this could be the problem in your case.

But I do remember now a problem I once had with the GOTFOCUS of the first control in tab order running earlier than CREATE. See . But it's the kind of thing I don't want to know. So I suppressed it.

But since your READ vs CREATE problem doesn't always occur, we might have to file it under a different label - perhaps "MDI features".

- Oystein -

View this thread on the forum...