Re: win32Lib - newUIObj bug?
CChris:
I've got the trace window up and can give you any information about whatever
variables you want to see, if that will help narrow this down. I'm on IRC if you
have the time to chat real time.
The trace is definitely in an infinite loop within creeateex.
Thanks
Mike
Mike777 wrote:
>
> CChris wrote:
> >
> > Mike777 wrote:
> > >
> > > CChris wrote:
> > > >
> > > > Mike777 wrote:
> > > > >
> > > > > I am using Judith's IDE. I establish my main Windows through the IDE.
> > > > > All
> > > > > other controls are built using newUIObj.
> > > > >
> > > > > It doesn't appear to me that the id's of the defined windows are
> > > > > available
> to</font></i>
> > > > > the newUIObj procedure. When I set trace on and find myself in that
> > > > > procedure,
> > > > > when I type a ? and then enter the name of a window, I get a message
> > > > > saying
> > > > > that it is undefined.
> > > > >
> > > > > In my program, when I get to the Owner portion of the newUIObj
> > > > > procedure
> at</font></i>
> > > > > around line 2081 of w32forms.ew I find that none of my window
> > > > > variables are
> > > > > available to set the parent. The parent is therefore set to be zero,
> > > > > and
> I </font></i>
> > > > > end up with a race condition when the program executes the CreateEx
> > > > > function
> > > > > at around line 2400. My line numbers may not be exact because I've
> > > > > peppered
> > > > > the procedure at the moment with message_boxes.
> > > > >
> > > > > When I force the lOwner variable value to be "110" with the following
> > > > > code,
> > > > > the createex works just fine:
> > > > >
> > > > > if compare(lData,"MySpecialWindow") = 0 then
> > > > > lOwner = 110
> > > > > end if
> > > > >
> > > > > Is it a bug that the newUIObj routine doesn't seem to be able to
> > > > > execute
> the:</font></i>
> > > > >
> > > > > lOwner = getNameId(w32trim(lData))
> > > > >
> > > > > line and get back a valid id (it always returns zero)?
> > > > >
> > > > > Thanks
> > > > >
> > > > > Mike
> > > >
> > > > I just ran the rebar.exw demo, and that line 2083 returns quite a few
> > > > nonzero
> > > > values, as you can check by adding "?lOwner" to it..
> > > > I think I need to see some code sample of yours.
> > >
> > > Thanks for the quick reply.
> > >
> > > It doesn't surprise me that the rebar.exw demo doesn't hit the nail on the
> > > head.
> > > There are (at least) two characteristics of my routine which are not
> > > present
> > > in that very short demo.
> > >
> > > First, I am attempting to create tab controls directly off of a window
> > > control.
> > > That is, the window control is the parent to the tab control. The rebar
> > > demo
> > > doesn't build any tab controls.
> > >
> > > Second, I am doing so after destroying a previously built tab control.
> > > Again,
> > > no destroy commands are found in rebar.
> > >
> > > I end up with a race condition when the CreateEx is executed when
> > > attempting
> > > to (re) create the tab control after the first time around was destroyed.
> > > The
> > > first time around it is named myTabControl1, the second time
> > > myTabControl2,
> > > etc.
> > >
> > > If I force the parent to be the id of the Window the CreateEx which is
> > > supposed
> > > to build the tab control runs without fail.
> > >
> > > Since I'm using newUIObj directly there is quite a bit of code that goes
> > > into
> > > creating the string that is passed to newUIObj. But the result is a loop
> > > that
> > > does the following:
> > >
> > > 1. Add a tab control to the window
> > > 2. Add tab index to tab control
> > > 3. Add a series of controls to the tab index
> > > 4. Destroy the tab control (which theoretically should destroy the tab
> > > index
> > > and all of the controls on the tab index)
> > > 5. Add a tab control to the window
> > >
> > > Step five gives me a race condition on the CreateEx even though it uses
> > > the
> > > exact same text that was used in step 1, except the name of the control
> > > would
> > > have a "2" in it where it previously had a "1" (e.g., myTabControl2).
> > >
> > > Step file does not give me a race condition on the CreateEx if I force the
> > > parent
> > > to be the IDNo of the window.
> > >
> > > I'm not terribly good at reducing the code down to a manageable level in
> > > order
> > > to replicate the problem.
> > >
> > > But if the above isn't enough I'll certainly give it a shot.
> > >
> > > My next step is to go through the CreateEx routine and attempt to find the
> > > code
> > > where the loop is. So far, I've found that the loop exists because the
> > > variable
> > > SP is set to 2, then 3, then back to 2. It has to do with the stack. The
> > > idStack
> > > is changing between {3,113,90,34,0,0,0,0,0,0} and
> > > {3,113,110,34,0,0,0,0,0,0}.
> > > When we get to the pushSelf procedure the value of the third element is
> > > changed
> > > as indicated and SP changes to 3. The corresponding popSelf changes SP
> > > back
> > > to 2.
> > >
> > > Don't know whether the above helps at all.
> > >
> > > Thanks again.
> > >
> > > Mike
> >
> > If I got it right:
> > * at step 3, you create controls with the initial tab control as parent.
>
> Slight modification. I create controls that have the tab index as the parent.
> The tab control is the grandparent (parent to the tab index). The main
> window
> is the great-grandparent.
>
> MySpecialWindow
> --- myTabControl1
> ------myTabIndex1
> ---------myGroup1
> ------------myGroup1Option1
> ------------myGroup1Option2
> ------------myGroup1Edit1
> ---------myEditControl1
> ---------myGroup2
> ------------myGroup2Option1
> ------------myGroup2Option2
> ------------myGroup2Edit1
>
> > So,
> > the last parent newUIObj() knows about is that tab control.
>
> The last "parent" that newUIObj knows about is the last parent of the last
> control inserted into the tab page (tab index). In fact, I might have 2
> groups
> on the tab page, each of which have 2 options (checkboxes or radiouttons) and
> a multi-line edit control. If all I'm interested in is the last parent, it
> can be two or more levels down from the tab control being deleted.
>
> > * at step 4, you destroy it. newUIObj() has no way to know. You may have
> > done
> > it by calling the API, or another process did it;
>
> As mentioned below, I could (should?) have provided you with an example line
> so you would see that it is destroyed using win32Lib's destroy command.
>
> destroy(getNameId("myTabControl1"))
>
> > * at step 5, you create a tab control without giving a parent. So the parent
> > is the destroyed tab control, its id is either invalid or, from getNameId(),
> > 0.
>
> Again, the actual line would have shown that I am giving it an explicit
> parent:
>
>
> newUIObj("TabControl,myTabControl2,myTabControl2,0,0,1200,950,parent=MySpecialWindow")
>
>
> > Create the second tab control (step 5) with an explicit OWNER= directive. ?
> > It makes sense that you have to tell newUIObj() that the world had changed
> > between two contiguous calls.
>
> I certainly agree and I have always done that.
>
> > Did I miss anything else?
>
> Depends on your point of view. I think so, but then again I was probably too
> cryptic. You certainly missed what I didn't provide (how could you not
> have?).
> In other words, if I had shown you the precise coding you would have
> immediately
> seen that my newUIObj command includes parent=MySpecialWindow so I already
> have
> an explicit equivalent to OWNER=.
>
> I had thought I implied that with my coding in my initial post:
>
> if compare(lData,"MySpecialWindow") = 0 then
>
> in that lData does, in fact, have "MySpecialWindow" as its value so when the
> parent portion of the routine is executed my test for that "works" and I can
> insert 110 as the owner. I remain baffled why, at that very moment, a
> getNameId("MySpecialWindow")
> returns 0 when I know it is 110. I know the mechanics of *how* it returns
> zero:
> it is because MySpecialWindow (the name of the window) returns a Not Defined
> on the trace window. Whereas other times through the same routine (newUIObj)
> getNameId("MySpecialWindow") will return 110.
>
> With the IDE, the main windows are all built when the program is initialized
> and the id's are set from that point forward. I thought.
>
> Thanks for sticking with me on this one. I know it is a tough one to hunt
> down.
>
> Mike
|
Not Categorized, Please Help
|
|
