Re: win32Lib - newUIObj bug?
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
> > 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
> > 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
> > 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:
> >
> > 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
|
Not Categorized, Please Help
|
|
