[futurebasic] Re: [FB] HANDLEEVENS changes ?

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : January 2010 : Group Archive : Group : All Groups

From: Brian S <fblistserve@...>
Date: Wed, 27 Jan 2010 17:55:52 -0700
On Jan 27, 2010, at 5:05 PM, Robert Purves wrote:

>
> Walter Lenk wrote:
>
>> I am currently using FB5.4.3, and I am revisiting a program that I  
>> last did in April of 2008 using (probably) FB2C 1.0.7. After fixing  
>> the normal slew of compiler warnings, it has become apparent that  
>> HANDLEEVENTS now does a lot more than it did back then.
>
>> In FB5.4.3, I no longer need to use  
>> _kWindowStandardHandlerAttribute to implement the MLTE EF  
>> scrolling. And I also don't need to install a "WindowEventHandler"  
>> or a "AppEventHandler" - ON DIALOG returns the button and window  
>> close information that I need (even if I use  
>> _kWindowStandardHandlerAttribute).
>>
>> Is this behavior expected?
>
> Yes. Early versions of FBtoC had a markedly incomplete  
> implementation of the old-style 'on dialog' event handling. It was  
> assumed that most apps would need rewriting to use CarbonEvent  
> handlers. Later we found it possible to synthesise old-style events  
> quite accurately.
>
> All windows have the kWindowStandardHandlerAttribute, whether you  
> ask for it or not.

As an addendum to Robert's response: Keep in mind that by definition  
Carbon Events provides all the possibilities CE offers. FB5 runtime  
does NOT map all CE events to FB events. For example,  
_kEventClassTextField, _kEventTextDidChange does not map to an FB  
Event. Maybe consider keeping your CE code if it is possible other  
events ( possibly not synthesized by the runtime ) will be required.


Brian S