Robert Covington wrote:

> Sports fans, they said it couldn't be done, and it shall now be proved wrong. :)
>
> The Window Grow in proportion is now a reality. :)  Wahoo.
>

You did it. I don't believe you...

>
> FB 3 Runtime Override, plus an EnterProc for the _dragHook, plus some mouse whacking during the EnterProc and that's a wrap.
>
> 41 points to Robert Covington, distribution of those among Derek for the original call pointers, Alain , Robert P. , and honorable mention to Tedd.
>
> Bonus Points to Alain for the mouse code at the wonderful PixMix FB site, Robert Purves for the demo basis, and honorable mention to Tedd for the On Event approach that got me thinking.

I hope someday I'll get points enough to change my name to Robert. You're in a good position to see that things regarding FB seem easier for them.

>
>
> Negative points for anyone who posts code that doesn't have DIM'ed vars or Call Required. Them's is the FB 3 defaults, and the list benefits when code conforms to that. That means me, because I don't go running just to be DIM. :)

Let me discuss that point. I'm for the DIM vars option, because it is a good habit that may save precious hours instead of kissing the death many times a day when you're coding (for the two seconds you are losing dimming a variable, you can count your gain in minutes later) . But,
concerning the CALL required option, I am against the current default settings, first can someone tell me why we must type CALL when it is not an absolute necessity? (here for one second you lose typing CALL, you just lose it), second, I believe that this option is still alive in
order to maintain a compatibility with FBII, no? But up to now, I've not understood the reason why this is a default setting, because for instance, either statements would work with CALL not required:
DiposeHandle(theH)
CALL DisposeHandle(theH)
Therefore old code can still run with that setting.
I can understand that still a lot of FB programmers need to maintain that compatibility today, but within a year or so, I bet that all of them will write code totally incompatible with FBII. There are many wonderful and terrific enhancements in FB^3 that would give an indigestion to
FBII, but that would make your life so much easier. More and more code will be posted with FB^3 in mind, besides it is already the case, try to paste some of the snippets posted here into FBII. I guess also that for many new users this preference setting is a non sense having never
heard of FBII and they may think we are all a bit crazy to activate that useless feature. My request to Staz was to get rid of that preference and force those who have compatibility issues to use the COMPILE statement to set the CALL required for Toolbox and not the reverse order.
As I see it, at the moment, we are forcing newcomers to use old habits.
The _optional_ CALL keyword is one of the features that I was dreaming of and this is a reality now. In my opinion code is easier to read and the source is lighter. Not only that compatibility is greater with other languages which don't use that idiosyncratic syntax. I personally
dislike when a foreign project changes my settings too (I used to chose systematically the project prefs for quick test).
Perhaps I have missed something important here, but could you tell me why you check that option on, knowing that you can still run your progs with CALLs everywhere in your source code even when that option is off?

Cheers

Alain