1. Upcoming win32lib v0.70.4a
May 15 is a good release date candidate.
Compaatibility with xControls: things got broken in 70.1 because the semantics
of getControlInfo(id,CONTROLINFO_type) sneakily changed. This will be fixed, but
some testing is in order and the fix isn't a one liner. Additionall, xControls
has to be tweaked as well, replacing 4 occurences of WINDOW by Window, as I
mentioned earlier. validId() got fixed in the process.
setMousePointer(): I started testing and it seems to be fixed. The trick was to
have getRect() return something sensibl for menus and menu items. It now
basically does, I have to check how it deals with multicolumn menus.
By the way:
* I asked whether it would hurt if getRect() returned [0,0,0,0} for an invisible
control. I have seen o replies so far.
* Mike777 (or Judith, or anyone else who chanced upon the issue): I need some
evidence of what is going on when recreating a control and something goes wrong.
Do you have any?
CChris
2. Re: Upcoming win32lib v0.70.4a
CChris wrote:
>
> * Mike777 (or Judith, or anyone else who chanced upon the issue): I need some
> evidence of what is going on when recreating a control and something goes
> wrong.
> Do you have any?
Not too much. Here's a description. I have a main window with two combo boxes
used to select client and project. Once selected, there is a command button
which reads those two combo boxes and from the combination, understands where to
find a text file that has a whole slew of newUIObj commands. I use that text
file to build a series of controls. All works as expected. The very first
control that is built, by convention is a tab control. All other controls are
descendants of that tab control.
I have a menu item: File|New which is intended to essentially start the program
over.
It executes the following:
setVisible({cboBox1,lblcboBox1,cboBox2,lblcboBox2,cmdStartProgram},w32True)
destroy(getNameId("tabControlMain"))
When I execute the above, it works fine.
However, when I re-execute the command button (pointing to the same text file) I
get an error message with the following:
Error code 459
create():Invalid parent id.
W32Lib v0.70.4 15-Mar-2008
Press enter ....
So I comment out the above two lines and replace them with:
shellExecute("open","RerunMyProgram.bat",SW_SHOWNORMAL)
abort(1)
Where ReRunMyProgram has the following in it:
START MYPROGRAM.Exe && EXIT
Which, does what I want in that I now have my program opened, memory cleared and
my selection boxes again available. If I set the combos and select the command
button, the controls are again built without a problem.
I did some debugging and found that on the rebuild, I successfully place the
main tab control, and a series of tab items (pages). It is only when trying to
add the first control to a tab item does the program abort with an invalid parent
message.
I tried a number of controls (combos, labels, text boxes) they all abort. So
there is something about establishing the tab item control the second time around
which doesn't allow it to be referenced as a parent.
While I haven't 100% confirmed this, here are 3 lines which if they are the only
controls built should give an error when the combo is built:
Control:"TabControl,Main Tab
Control,tabMainControl,0,0,1200,950,parent=Window1"
Control:"TabItem,Client Info,tbiClientInfo,parent=tabMainControl,initialfocus=1"
Control:"Combo,cboFirst,cboFirst,100,40,60,140,parent=tbiClientInfo
Mike
3. Re: Upcoming win32lib v0.70.4a
Mike777 wrote:
>
> CChris wrote:
> >
> > * Mike777 (or Judith, or anyone else who chanced upon the issue): I need
> > some
> > evidence of what is going on when recreating a control and something goes
> > wrong.
> > Do you have any?
>
> Not too much. Here's a description. I have a main window with two combo
> boxes
> used to select client and project. Once selected, there is a command button
> which reads those two combo boxes and from the combination, understands where
> to find a text file that has a whole slew of newUIObj commands. I use that
> text file to build a series of controls. All works as expected. The very
> first
> control that is built, by convention is a tab control. All other controls are
> descendants of that tab control.
>
> I have a menu item: File|New which is intended to essentially start the
> program
> over.
>
> It executes the following:
>
> setVisible({cboBox1,lblcboBox1,cboBox2,lblcboBox2,cmdStartProgram},w32True)
> destroy(getNameId("tabControlMain"))
>
> When I execute the above, it works fine.
>
> However, when I re-execute the command button (pointing to the same text file)
> I get an error message with the following:
>
> Error code 459
> create():Invalid parent id.
>
> W32Lib v0.70.4 15-Mar-2008
>
> Press enter ....
>
> So I comment out the above two lines and replace them with:
>
> shellExecute("open","RerunMyProgram.bat",SW_SHOWNORMAL)
> abort(1)
>
> Where ReRunMyProgram has the following in it:
>
> START MYPROGRAM.Exe && EXIT
>
> Which, does what I want in that I now have my program opened, memory cleared
> and my selection boxes again available. If I set the combos and select the
> command
> button, the controls are again built without a problem.
>
> I did some debugging and found that on the rebuild, I successfully place the
> main tab control, and a series of tab items (pages). It is only when trying
> to add the first control to a tab item does the program abort with an invalid
> parent message.
>
> I tried a number of controls (combos, labels, text boxes) they all abort. So
> there is something about establishing the tab item control the second time
> around
> which doesn't allow it to be referenced as a parent.
>
> While I haven't 100% confirmed this, here are 3 lines which if they are the
> only controls built should give an error when the combo is built:
>
> Control:"TabControl,Main Tab
> Control,tabMainControl,0,0,1200,950,parent=Window1"
>
> Control:"TabItem,Client
> Info,tbiClientInfo,parent=tabMainControl,initialfocus=1"
>
> Control:"Combo,cboFirst,cboFirst,100,40,60,140,parent=tbiClientInfo
Still testing at this end. I was able to strip out all but the three lines
above and, of course (grumble, grumble) it works fine.
So, there must be something in the remaining 1000 lines or so which is
effectively poisoning the ability of the tab page to accept the role of parent.
Maybe I'll excise 50 at a time until I can find the culprit.
Mike
4. Re: Upcoming win32lib v0.70.4a
Mike777 wrote:
>
> Mike777 wrote:
> >
> > CChris wrote:
> > >
> > > * Mike777 (or Judith, or anyone else who chanced upon the issue): I need
> > > some
> > > evidence of what is going on when recreating a control and something goes
> > > wrong.
> > > Do you have any?
> >
> > Not too much. Here's a description. I have a main window with two combo
> > boxes
> > used to select client and project. Once selected, there is a command button
> > which reads those two combo boxes and from the combination, understands
> > where
> > to find a text file that has a whole slew of newUIObj commands. I use that
> > text file to build a series of controls. All works as expected. The very
> > first
> > control that is built, by convention is a tab control. All other controls
> > are
> > descendants of that tab control.
> >
> > I have a menu item: File|New which is intended to essentially start the
> > program
> > over.
> >
> > It executes the following:
> >
> > setVisible({cboBox1,lblcboBox1,cboBox2,lblcboBox2,cmdStartProgram},w32True)
> > destroy(getNameId("tabControlMain"))
> >
> > When I execute the above, it works fine.
> >
> > However, when I re-execute the command button (pointing to the same text
> > file)
> > I get an error message with the following:
> >
> > Error code 459
> > create():Invalid parent id.
> >
> > W32Lib v0.70.4 15-Mar-2008
> >
> > Press enter ....
> >
> > So I comment out the above two lines and replace them with:
> >
> > shellExecute("open","RerunMyProgram.bat",SW_SHOWNORMAL)
> > abort(1)
> >
> > Where ReRunMyProgram has the following in it:
> >
> > START MYPROGRAM.Exe && EXIT
> >
> > Which, does what I want in that I now have my program opened, memory cleared
> > and my selection boxes again available. If I set the combos and select the
> > command
> > button, the controls are again built without a problem.
> >
> > I did some debugging and found that on the rebuild, I successfully place the
> > main tab control, and a series of tab items (pages). It is only when trying
> > to add the first control to a tab item does the program abort with an
> > invalid
> > parent message.
> >
> > I tried a number of controls (combos, labels, text boxes) they all abort.
> > So
> > there is something about establishing the tab item control the second time
> > around
> > which doesn't allow it to be referenced as a parent.
> >
> > While I haven't 100% confirmed this, here are 3 lines which if they are the
> > only controls built should give an error when the combo is built:
> >
> > Control:"TabControl,Main Tab
> > Control,tabMainControl,0,0,1200,950,parent=Window1"
> >
> > Control:"TabItem,Client
> > Info,tbiClientInfo,parent=tabMainControl,initialfocus=1"
> >
> > Control:"Combo,cboFirst,cboFirst,100,40,60,140,parent=tbiClientInfo
>
> Still testing at this end. I was able to strip out all but the three lines
> above and, of course (grumble, grumble) it works fine.
>
> So, there must be something in the remaining 1000 lines or so which is
> effectively
> poisoning the ability of the tab page to accept the role of parent.
>
> Maybe I'll excise 50 at a time until I can find the culprit.
>
> Mike
When controls are recreated, they have ids that bear hardly any relations to
what they were. As a result, I assume you store the ids into integers.
I wonder whether marking the ids as invalid whle the controls are destroyed (for
instance, assigning them -1) wouldn't help. Judith uses this technique in IDE.
Also, I'd appreciate some ex.errs from your tests. Please email them to oedoc
hat free doubt fr, if at all possible.
One more thing: does (re)creating the controls using newUIObj() or plain
createEx() statements make any difference? It shouldn't but the lib shouldn't
crash either...
CChris
5. Re: Upcoming win32lib v0.70.4a
Mike777 wrote:
>
> Mike777 wrote:
> >
> > CChris wrote:
> > >
> > > * Mike777 (or Judith, or anyone else who chanced upon the issue): I need
> > > some
> > > evidence of what is going on when recreating a control and something goes
> > > wrong.
> > > Do you have any?
> >
> > Not too much. Here's a description. I have a main window with two combo
> > boxes
> > used to select client and project. Once selected, there is a command button
> > which reads those two combo boxes and from the combination, understands
> > where
> > to find a text file that has a whole slew of newUIObj commands. I use that
> > text file to build a series of controls. All works as expected. The very
> > first
> > control that is built, by convention is a tab control. All other controls
> > are
> > descendants of that tab control.
> >
> > I have a menu item: File|New which is intended to essentially start the
> > program
> > over.
> >
> > It executes the following:
> >
> > setVisible({cboBox1,lblcboBox1,cboBox2,lblcboBox2,cmdStartProgram},w32True)
> > destroy(getNameId("tabControlMain"))
> >
> > When I execute the above, it works fine.
> >
> > However, when I re-execute the command button (pointing to the same text
> > file)
> > I get an error message with the following:
> >
> > Error code 459
> > create():Invalid parent id.
> >
> > W32Lib v0.70.4 15-Mar-2008
> >
> > Press enter ....
> >
> > So I comment out the above two lines and replace them with:
> >
> > shellExecute("open","RerunMyProgram.bat",SW_SHOWNORMAL)
> > abort(1)
> >
> > Where ReRunMyProgram has the following in it:
> >
> > START MYPROGRAM.Exe && EXIT
> >
> > Which, does what I want in that I now have my program opened, memory cleared
> > and my selection boxes again available. If I set the combos and select the
> > command
> > button, the controls are again built without a problem.
> >
> > I did some debugging and found that on the rebuild, I successfully place the
> > main tab control, and a series of tab items (pages). It is only when trying
> > to add the first control to a tab item does the program abort with an
> > invalid
> > parent message.
> >
> > I tried a number of controls (combos, labels, text boxes) they all abort.
> > So
> > there is something about establishing the tab item control the second time
> > around
> > which doesn't allow it to be referenced as a parent.
> >
> > While I haven't 100% confirmed this, here are 3 lines which if they are the
> > only controls built should give an error when the combo is built:
> >
> > Control:"TabControl,Main Tab
> > Control,tabMainControl,0,0,1200,950,parent=Window1"
> >
> > Control:"TabItem,Client
> > Info,tbiClientInfo,parent=tabMainControl,initialfocus=1"
> >
> > Control:"Combo,cboFirst,cboFirst,100,40,60,140,parent=tbiClientInfo
>
> Still testing at this end. I was able to strip out all but the three lines
> above and, of course (grumble, grumble) it works fine.
>
> So, there must be something in the remaining 1000 lines or so which is
> effectively
> poisoning the ability of the tab page to accept the role of parent.
>
> Maybe I'll excise 50 at a time until I can find the culprit.
Things are pointing to win32Lib's garbage cleanup routines. Me thinks.
After paring down the newUIObj commands, I found a new bug. AddItem's are
failing because the object appears to be destroyed. I'll try to confirm, but it
looks like getNameId("myBuiltControlName") returns an invalid response after
myBuiltControlName has been destroyed and rebuilt. It is probably the old id,
but I haven't confirmed that just yet. I'll try to do that on the next
iteration.
Mike
6. Re: Upcoming win32lib v0.70.4a
CChris wrote:
>
> When controls are recreated, they have ids that bear hardly any relations to
> what they were. As a result, I assume you store the ids into integers.
> I wonder whether marking the ids as invalid whle the controls are destroyed
> (for instance, assigning them -1) wouldn't help. Judith uses this technique
> in IDE.
> Also, I'd appreciate some ex.errs from your tests. Please email them to oedoc
> hat free doubt fr, if at all possible.
>
> One more thing: does (re)creating the controls using newUIObj() or plain
> createEx()
> statements make any difference? It shouldn't but the lib shouldn't crash
> either...
I'll try to do this a bit later on today.
Mike
