FireFly Object Framework - Open Beta (BETA PERIOD IS NOW OVER - THANKS!)

[Paul Squires]

...maybe I should use dedicated objects for each control type rather than a generic control object.

What do you guys think? Objects specific to a control type would make things easier and less error prone

[David Warner]

The technique which allows fewest errors sounds good. However, in what situations do you see control iteration being useful?

[Paul Squires]

However, in what situations do you see control iteration being useful?

I originally tried to set up the framework so that you could iterate all Forms (from a clsApplication object) and then all Controls on each Form (which we do have now of course).

Honestly, control iteration is probably not that big of a deal. We don't have it now in FF3 except for maybe Control Arrays which is probably the one case where it makes perfect sense.

Maybe I will change. I will let the idea percolate in my brain for a while before deciding. Changing would not affect any code that you have already written.

[David Warner]

you could iterate all Forms (from a clsApplication object) and then all Controls on each Form (which we do have now of course).

That does seem desirable and it reminds me of the Forms and Controls collections in Microsoft Access. It occurs to me that it might make VB and Access project conversions to FireFly easier. However, if having this capability lets more minor coding errors through then it's not ideal.

You might find some inspiration here...

Forms Collection [Access 2003 VBA Language Reference]
http://msdn.microsoft.com/en-us/library/office/aa210667(v=office.11).aspx

For example, you can enumerate the Forms collection to set or return the values of properties of individual forms in the collection.

Controls Collection [Access 2003 VBA Language Reference]
http://msdn.microsoft.com/en-us/library/office/aa210660(v=office.11).aspx

For example, you can enumerate the Controls collection of a particular form and set the Height property of each control to a specified value.

[Paul Squires]

If you try to use the Framework objects in the WM_SIZE handler then most likely you will get a GPF. WM_SIZE fires during the creation of a Form and depending when that happens, the classes for the Form and Controls may not be valid. I am investigating if there is a way to fix this. Of course, you can still use the old style FF functions and HWND_ IDC_ variables with no troubles.

[David Kenny]

WM_SIZE fires during the creation of a Form and depending when that happens, the classes for the Form and Controls may not be valid.

You (more accurately, FF) route messages to the handler we use after parsing out stuff you need.  You could interrupt size messages to our code during creation maybe?

David

[Paul Squires]

You (more accurately, FF) route messages to the handler we use after parsing out stuff you need.  You could interrupt size messages to our code during creation maybe?

Hi David, I think I have this problem solved. Actually, it is kind of solving itself based on the conversion of the current framework of one big "clsControl" to separate classes for each Control type. The new approach will initialize the control objects when the Form object is created (via the "Class Method Create" constructor). This way, there will always be a valid object reference and the GPF's will be avoided.

BTW, I now have the clsControl separated out to individual class modules. It's a lot easier to work with and was probably the approach I should have gone with from the beginning. Control Arrays are easier to code in the Framework as well. Just a few more code generation issues to finish coding and then I will upload the new version. Some property/method names have a changed a little bit (for the better).

[David Kenny]

I have sent you an email, via support, that is based on the current implementation.  But I'm sure you can apply the principles to the new one.

[Paul Squires]

I didn't get the email. I wonder if I now have my spam filter too high.

[Paul Squires]

If you try to use the Framework objects in the WM_SIZE handler then most likely you will get a GPF. WM_SIZE fires during the creation of a Form and depending when that happens, the classes for the Form and Controls may not be valid. I am investigating if there is a way to fix this. Of course, you can still use the old style FF functions and HWND_ IDC_ variables with no troubles.

This GPF issue is now resolved. The new Framework has valid Form and Control object references immediately available to the programmer so memory access violations will not occur.

[Paul Squires]

I want to thank everyone for helping test the Framework beta over the past couple of weeks. The beta period is now over. I have changed a lot about the Framework and based on your suggestions, it is exactly how I want it to be. The Framework code you see in the last posted package is quite different than the current version because I made a substantial change to it over the past few days. The biggest changes are that the Framework no longer stores controls on a form in a collection, and I have solved the Form "multiple instance" problem. Your Form objects can now be seamlessly used amongst multiple instances of the same form.

The FireFly Object Framework will be part of FireFly4, but I will be posting information soon about how you can get access to it from now until FireFly4 is officially released. Stay tuned for that.

Once again, thanks for all your help and suggestions.