[blugs] Re: Assorted Bugs and more... (and 1.2d4 announcement)


> 1.2d4 is up online as of today, I just uploaded it. Be kind :-)
I'll attempt to slowly integrate it into my app and report any problems 
I have.

> But first, my dirty little secret... I am migrating to Cocoa. Yup, I
> finally scaled the emotional barriers to discarding 10 years of
> accumulated Classic/Carbon experience. I realized at this point it's 
> all
> diminishing returns; the amount of "working around Apple's bugs" is so
> enormous compared to "using cool technologies" that it's just not worth
> trying to develop Carbon apps, IMHO.
Awesome, I have decided my next app will be in Cocoa as well... Carbon 
is just too slow and finicky.

> I haven't used any of the Cocoa table classes yet, but it may be that I
> will end up writing a Cocoa Blugs! (Clugs? eeugh :-)
A Cocoa version would be AWESOME. I haven't used any Cocoa tables yet 
either, but writing Blugs content handlers is so easy that I think the 
power would be hard to duplicate with the built-in classes.

>> 1. In the Checkbox handler and the ColorPopup handler, clicking the
>> respective control temporarily whites out the cell hilite and looks
>> quite ugly. I have browsed through the code but cannot find an easy 
>> way
>> to have it redraw the hilite for the cell during the click handling.
>
> I wrote a routine for 1.2d4 to help fix this; you can use:
> BL_PROC OSErr BLDrawCellMinusContent( BLCell inCell, const Rect* 
> inRect,
> BlugsRef inList );
> if you encounter a similar situation in a content handler. With Aqua
> transparency it is sometimes insufficient to just overdraw, so this 
> helps
> you redraw correctly in the middle of something like a content handler
> tracking loop.
Excellent, I will experiment with it.

>> 2. I am not sure if this was fixed when you fixed the other
>> blRowSelectAll bugs, but hitting Return to end an inline edit session
>> in a row with blRowSelectAll enabled does not re-select the entire 
>> row,
>> only the one cell.
>
> Because there have been massive changes (hopefully amounting to
> optimizations) via the new "dirty regions" for lists, I think issues 
> like
> this will be resolved. We'll have to check and make sure but even if
> there is a problem it should be easier to fix now.
Yep, I will see if it works correctly with the new version.

> Absolutely! All contributions are more than welcome.
I'll put together a package of code I've written and send it to you. It 
may take a week or two to clean up and make sure it works with 1.2d4.

>> Currently, tabbing to the row selects the first of the four fields, as
>> desired. But hitting tab again moves it to the next row. 
>> Unfortunately,
>> as you note in the BLKey code, tabs are not passed to content 
>> handlers,
>> so I have no way of advancing the tab to the next field and overriding
>> Blugs' default behavior. My request is that some sort of system is
>> implemented so tab hits are passed to the content handlers so they can
>> optionally override the default behavior and handle tabs. Of course,
>> they should also be able to order Blugs to advance it to the next row
>> (if, for example, the user has reached the last of the four fields in
>> the row).
>
> Yup, I definitely understand that. Lemme give it some thought. The
> simplest way: just have BLKey always pass the tab, and if the handler
> responds "nope" then process it. Otherwise consider the matter settled.
> This is quite like Carbon Events. The same approach could be applied to
> return and enter. I would always rather have an intelligent protocol
> rather than a bunch of flags, so this might be an opportunity to also 
> get
> rid of the handler "wants inline edit return/enter" feature flag. One
> less thing to clutter the API :-)
>
> What do you say? This should be quick to implement if it sounds 
> workable.
That, I believe, would be the ideal way of doing it. Pass everything to 
the content handler and then only process it if the handler returned 
eventNotHandledErr or something similar.

Jeffrey

Other related posts: