A couple of bugs

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

A couple of bugs

Steve Alan Waring
Hi Andy and Blair,

In D5.1's debugger, I have been getting the occasional walkback in
Debugger>>setVariablesList: when stepping through a frame, in which self
is an object that has an #= method that signals an error. For example
stepping into the initialization/construction of an object with an #=
method that sends a message to one of the object's instance variables.

Should an error handler be put around the send of #indexOf:ifAbsent:?

=====
View>>hasWindowEdge/hasWindowEdge is using the wrong constant;
WS_EX_TOOLWINDOW not WS_EX_WINDOWEDGE. The constants are different, but I
think it is cosmetic; there are no references to either method and it
seems that windows sets this style automatically.

=====
When mutating a view, the z-order of the view's subviews is changed.

For example, in the ViewComposer, add three buttons to a ShellView, and then
mutate the ShellView to a ContainerView.

The following fix has been working for me:

!ViewComposer methodsFor!
mutateTo: aViewClass
"Mutate the primary selection to an instance of aViewClass."
| selectedView newView prevSubView |
selectedView := self primarySelection.
newView := selectedView parentView addSubView: aViewClass new.
self copyAspectsFrom: selectedView to: newView.
"
SW Changed: If the subViews are enumerated, either the old sibling view has
been destroyed
or the new sibling is not yet added. Either way, we lose the z-order.
Instead,
use a temporary
to hold the previous z-order view ."
selectedView subViews copy do:
[:each |
| name |
name := each name.
each
parentView: newView;
recreate.
each name: name.
each zOrderAfter: prevSubView.
prevSubView := each].
self pastedView: newView context: newView parentView.
self removeView: selectedView.
"Ensure any refs to old view (such as from a layout manager) are now to
the new view"
selectedView oneWayBecome: newView! !
!ViewComposer categoriesFor: #mutateTo:!operations!public! !

=====
In String>>unescapePercents, you are guarding against the string being
"not really an escaped string" by checking that asciiVal is not greater
than 255. It is also possible for asciiVal to be less than zero, as
digitValue can answer -1. Could a guard also be added for asciiVal < 0?


Thanks
Steve
--

Steve Waring
Email: [hidden email]
Journal: http://www.stevewaring.net/blog/home/index.html


--
Steve Waring
Email: [hidden email]
Journal: http://www.stevewaring.net/blog/home/index.html


Reply | Threaded
Open this post in threaded view
|

Re: A couple of bugs

Blair McGlashan-2
Steve

You wrote in message news:b97qug$gdufm$[hidden email]...
>
> In D5.1's debugger, I have been getting the occasional walkback in
> Debugger>>setVariablesList: when stepping through a frame, in which self
> is an object that has an #= method that signals an error. For example
> stepping into the initialization/construction of an object with an #=
> method that sends a message to one of the object's instance variables.
>
> Should an error handler be put around the send of #indexOf:ifAbsent:?

Its simpler than that: The search should be comparing only the variable
names, not the name/value pairs. Recorded as #1261 for fixing in 5.1 PL1.

>
> =====
> View>>hasWindowEdge/hasWindowEdge is using the wrong constant;
> WS_EX_TOOLWINDOW not WS_EX_WINDOWEDGE. The constants are different, but I
> think it is cosmetic; there are no references to either method and it
> seems that windows sets this style automatically.

Recorded as #1262 for fixing in 5.1 PL1. We'll probably deprecate/remove
those methods in the next release.

>
> =====
> When mutating a view, the z-order of the view's subviews is changed.
>
> For example, in the ViewComposer, add three buttons to a ShellView, and
then
> mutate the ShellView to a ContainerView.
>
> The following fix has been working for me:
> [code snipped]

Thanks for the fix. #1263 for 5.1 PL1.

> =====
> In String>>unescapePercents, you are guarding against the string being
> "not really an escaped string" by checking that asciiVal is not greater
> than 255. It is also possible for asciiVal to be less than zero, as
> digitValue can answer -1. Could a guard also be added for asciiVal < 0?
>

And finally #1264 for 5.1 PL1.

Thanks again for the bug reports.

Regards

Blair