Well, the weird thing was that these were forms that have been in existence for a long time and worked fine and recently stopped working (in the sense that the combobox or listbox was not being properly populated). I still have not determined why it worked before but won't now, however I just moved the creation of the array from Init to Load (which is really my std. MO these days) and that fixed it.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ken Dibble Sent: Thursday, September 28, 2006 9:39 PM To: [EMAIL PROTECTED] Subject: RE: oop data entry form >Ken (or anyone) - > >Why did you ask that question about the combobox and using arrays to >populate them? I suggested loading the array in the Load method, which >works fine. The reason I ask/mention this is that I've suddenly been >getting odd behavior from my listboxes and comboboxes that are populated >with arrays. I have, at times, also loaded the array in the Init method and >it worked fine. But the other day I had a customer report that a listbox >that previously had multiple entries (field names from a table to use when >sending data to Excel), now only had one entry. I had not changed that code >in quite awhile. Similar behavior was witnessed on another form in that >same app and today I've noticed it in another app (two entries in a combobox >that previously had 12). All of these arrays were defined in the Init. >Moving them to the Load will fix the problem, I know, but I'm trying to >figure out how this got broken and why is it partially broken (why do one or >two entries get recognized instead of none). It would seem I made some >change to my framework and unknowingly broke this, but I can't imagine what >and I'm only making occasional changes to the framework and base classes >these days. Certainly none in recent memory to the combobox and listbox. >It's curious that you had trouble when you loaded the arrays in the Init, >yet some of my code that worked fine in the past is now broken. >Coincidence? My fault? I don't know, but it's rather odd. It wasn't me who posed the original question. I think it was Andy. I just described some of my process in learning how array RowSources work and why I found that confusing initially. I don't think I'm confused any more. I typically define array form properties at design time and populate them from methods either called from the form's Init() or from the Init() of the RowSource-bearing controls. And I set the RowSources for the controls in the Property sheet. I never have a problem with this. I was somewhat surprised to find, in testing just now, that I can even drop a combobox on a form, set its RowSourceType to 5 and its Rowsource to "THISFORM.aFoo" in the Property sheet, and then add the aFoo[1] property, and populate it, programmatically in the form Init() and everything works fine. I realize that the form event firing order is just that--the order in which the underlying C++ code calls the event/methods--and that from the beginning and through it all, the form object, and its contained controls and properties, all must reside in memory. but we're sometimes given the impression that the controls "come into existence" before the form does, which was one reason why this used to confuse me. So, all things being equal, it shouldn't matter whether array properties are created and populated in Load() or Init(). What may matter is whether the data you're pulling into those arrays is present when you need it. However, what your problem brings to mind is the possibility that you've got two listboxes or comboboxes hitting the same RowSource array and changing its contents. Or, less likely, you've got two RowSource arrays defined with the same name somewhere. Ken Dibble www.stic-cil.org [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
