1. win32Lib - newUIObj bug?
- Posted by Mike777 <anon4321 at g?ail?com> May 06, 2008
- 653 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
2. Re: win32Lib - newUIObj bug?
- Posted by CChris <christian.cuvier at agricul?ure.go?v.fr> May 07, 2008
- 646 views
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. CChris
3. Re: win32Lib - newUIObj bug?
- Posted by Mike777 <anon4321 at g?a?l.com> May 07, 2008
- 645 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
4. Re: win32Lib - newUIObj bug?
- Posted by c.k.lester <euphoric at c?lester.co?> May 07, 2008
- 636 views
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. :)
5. Re: win32Lib - newUIObj bug?
- Posted by Mike777 <anon4321 at gma?l?com> May 07, 2008
- 624 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
6. Re: win32Lib - newUIObj bug?
- Posted by Bernie Ryan <xotron at b?u?frog.com> May 07, 2008
- 623 views
- Last edited May 08, 2008
Mike777 wrote: > > 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: Have you thought of keeping your controls in a Euphoria Database ? Then you could create the screen file by selectively reading in your controls. Bernie My files in archive: WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API Can be downloaded here: http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
7. Re: win32Lib - newUIObj bug?
- Posted by Mike777 <anon4321 at gmai?.?om> May 07, 2008
- 736 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
8. Re: win32Lib - newUIObj bug?
- Posted by CChris <christian.cuvier at agricultu?e?gouv.fr> May 07, 2008
- 634 views
- Last edited May 08, 2008
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. So, the last parent newUIObj() knows about is that tab control. * 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; * 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. 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. Did I miss anything else? CChris
9. Re: win32Lib - newUIObj bug?
- Posted by Mike777 <anon4321 at gma?l.co?> May 07, 2008
- 635 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
10. Re: win32Lib - newUIObj bug?
- Posted by Mike777 <anon4321 at g??il.com> May 08, 2008
- 736 views
- Last edited May 09, 2008
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
11. Re: win32Lib - newUIObj bug?
- Posted by CChris <christian.cuvier at ag?icu?ture.gouv.fr> May 08, 2008
- 621 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
12. Re: win32Lib - newUIObj bug?
- Posted by Mike777 <anon4321 at gma??.com> May 08, 2008
- 643 views
- Last edited May 09, 2008
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
13. Re: win32Lib - newUIObj bug?
- Posted by Mike777 <anon4321 at gmai?.?om> May 08, 2008
- 638 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
14. Re: win32Lib - newUIObj bug?
- Posted by Mike777 <anon4321 at g?ail.c?m> May 09, 2008
- 621 views
CChris met me on IRC and after a few pecks on the keyboard was able to determine that it was, as expected, PBKAC. Although thoroughly aware of the issue, instead of setting BOTH the name and caption to the same string ("MySpecialWindow") I had set the name to "MySpecialWindow" but I had set the caption to "Design Window". It is much better practice to initially establish the controls (windows included) with the name and the caption set to the same thing. One can reset the caption in Code without changing the internals of the system. I am aware of this issue (I've actually ranted about it, IIRC), so it clearly was PBKAC on this one. Thanks to CChris for helping me track it down. Mike Mike777 wrote: > > 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