OpenEuphoria

1. win32Lib - newUIObj bug?

• Posted by Mike777 <anon4321 at g?ail?com> May 06, 2008
• 651 views

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

3. Re: win32Lib - newUIObj bug?

• Posted by Mike777 <anon4321 at g?a?l.com> May 07, 2008
• 643 views

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

5. Re: win32Lib - newUIObj bug?

• Posted by Mike777 <anon4321 at gma?l?com> May 07, 2008
• 622 views
• Last edited May 08, 2008

c.k.lester wrote:
> 
> Mike777 wrote:
> > 
> > 
> > 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
> 
> I hope we get to see this program someday. :)

This particular piece I'm working on right now is what might be called a
mini-IDE in the context of a visual editor for the newUIObj instructions.  That
is why I'm in a position of having to remove controls and put them back.  That
is, I don't want to just move a control on the screen, I really want to delete it
and re-paint it from scratch so that I'm sure the command is actually working.

I'm not sure I will ever have the time to make it publishable, since right now
it uses hardcoded names for many of the files and presumes a directory structure
that I'm sure nobody else has or would want.

But I really need this tool because hand editing a 2000 line text file to change
the layout of a particular screen is getting quite tedious.

Mike

7. Re: win32Lib - newUIObj bug?

• Posted by Mike777 <anon4321 at gmai?.?om> May 07, 2008
• 734 views
• Last edited May 08, 2008

Bernie Ryan wrote:
> 
> Mike777 wrote:
> > But I really need this tool because hand editing a 2000 line text file to
> > change
> > the layout of a particular screen is getting quite tedious.
> > 
> 
> Mike:
> 
>   Have you thought of keeping your controls in a Euphoria Database ?
> 
>   Then you could create the screen file by selectively reading
> 
>   in your controls.

Thanks for the suggestion, Bernie.  It has, indeed, crossed my mind.  I think I
need to get the basics working first, though, including the editing feature
(which I'm working on now) before I upgrade the backend, so to speak.

mike

9. Re: win32Lib - newUIObj bug?

• Posted by Mike777 <anon4321 at gma?l.co?> May 07, 2008
• 633 views
• Last edited May 08, 2008

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
> > > > 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
> 
> 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

11. Re: win32Lib - newUIObj bug?

• Posted by CChris <christian.cuvier at ag?icu?ture.gouv.fr> May 08, 2008
• 620 views
• Last edited May 09, 2008

getNameId() was changed in 70.4a. Please paste this to replace the current body
of getNameId(), and tell me if it gets you going:

global function getNameId(sequence pName)
    integer p

    pName=makeStandardName(pName)
    p=find(pName, ctrl_Name)
    if p=0 then
        return 0
    end if
    while not validId(p) do
        p=find_from(pName, ctrl_Name,p+1)
        if p=0 then
            return 0
        end if
    end while
    return p
end function

CChris

13. Re: win32Lib - newUIObj bug?

• Posted by Mike777 <anon4321 at gmai?.?om> May 08, 2008
• 636 views
• Last edited May 09, 2008

An interim report here: I have found that using the trace window is
fundamentally inconsistent with the message_box function.  It, in itself, creates
an infinite loop.  I need to eliminate that loop before I can get back to the
main issue at hand.

Mike

Mike777 wrote:
> 
> CChris wrote:
> > 
> > getNameId() was changed in 70.4a. Please paste this to replace the current
> > body
> > of getNameId(), and tell me if it gets you going:
> > }}}
<eucode>
> > global function getNameId(sequence pName)
> >     integer p
> > 
> >     pName=makeStandardName(pName)
> >     p=find(pName, ctrl_Name)
> >     if p=0 then
> >         return 0
> >     end if
> >     while not validId(p) do
> >         p=find_from(pName, ctrl_Name,p+1)
> >         if p=0 then
> >             return 0
> >         end if
> >     end while
> >     return p
> > end function
> > </eucode>
{{{

> 
> I wanted to take the time to do this, although I sort of knew it wouldn't
> help.
>  At the point in CreateEx that the program attempts to assign the parent, it
> has the value for the parent per the token (MySpecialWindow) but when I
> interrogate
> the trace window for the values of all of my windows, they are not there. 
> Hence,
> getNameId("avariablethatdoesnotexist") will always return a zero.
> 
> Something appears to be wrong with my scoping (which is truly bizarre),
> because
> at this point, no matter how explicitly I set the Owner in the newUIObj
> instruction,
> the createEx routine won't be able to assign the parent if the ids are just
> not there.
> 
> I'm going to run this again and go through the procedure in detail for a
> control
> where the parent IS set properly.
> 
> I'll post after that.
> 
> Thanks for trying.
> 
> Mike