I’ve probably got > 50 in one app.On Mar 2, 2017, at 12:54 PM, Brian S <fblistserve@...> wrote:On Mar 2, 2017, at 12:41 PM, Mark Chappell <chappell@...> wrote:This truly makes my day — every UI in my code is based on HandleEvents.
Thanks Ken. This will work nicely with the revisions I've already made to Appendix A in anticipation of FB's next release. One comment if I may:
Maybe a little early for this discussion but depending on an FBer's future plans it might be more appropriate to use FB's 'HandleEvents' and not Apple's Carbon 'RunApplicationEventLoop'(RAEL). The reason is 'HandleEvents' is translated into whatever the FB runtime provides while RAEL is a toolbox call and that's what the FBer gets. 'HandleEvents' can potentially be updated to use non-Carbon but RAEL cannot.
Brianthanks, Mark CWhat we actually do ( if anything ) with FB's event runtime is unknown, so thanks are definitely premature. Whether HandleEvents or another approach is used is unknown and certainly what it does and whether it could be used the same way it is today is also unknown. Current FBer code that sprinkles one or multiple HandleEvents ( I've seen more than 50 in one app ) will potentially require the FBer to change their code. What that is, how much, when etc. is unknown.
Understood. But overall, probably less work to go from HandleEvents —> whatever replaces it than to undertake HandleEvents —> RAEL —> replacement code…. which was (I think) your original point.My only point in the previous post is HandleEvents has a better chance of surviving any event code update while RAEL has almost no hope because of its inherent nature ( a Carbon call ).
To unsubscribe, send ANY message to: futurebasic-unsubscribe@... To access the list archives, go to: http://freegroups.net/groups/futurebasic/