Hi Everyone,
*** UPDATED: Version 1.70 is attached (Oct 3, 2013)
- Fixed: Not being able to selecting Object name from popup F4 list and insert directly into code editor.
- Fixed: Incorrect popup list of properties/methods for a Form could display. That is, the list for the Form object would show properties/methods of a different Form object.
If you are interested, you can download and try out the attached FireFly beta that includes the new FireFly Object Framework. This is basically the object "dot" syntax that we talked about in another post. The Framework is not totally complete but it will give you a very good idea of the power and convenience it provides.
To use the framework here is what you need to do:
(1) Make a copy of your existing FireFly installation.
(2) Unzip the attached FireFly beta archive (preserve directory structure).
(3) Read the pdf called FireFly_ObjectFramework.pdf
When you create a new test project, don't forget to enable the object framework for the project by going into "Project Properties" and enabling it.
The beta also includes many fixes and new features that have been added to FireFly since the last FireFly update. Using this beta will not harm any of your existing projects and you can easily switch back and forth between the beta and your existing FireFly installation.
Here are the changes:
- 0000845: [New Feature Request] FIREFLY OBJECT FRAMEWORK (Paul Squires) - closed.
- 0000840: [New Feature Request] Allow SLL option as well as DLL for external controls (Paul Squires) - closed.
- 0000843: [Change] Enable TBSTYLE_AUTOSIZE style by default for new ToolBar Buttons (Paul Squires) - closed.
- 0000839: [Bug] Form not set to dirty when only Custom property changes (Paul Squires) - closed.
- 0000844: [Bug] Cancel property of CommandButtons getting reset to False when Form closed and opened inside FireFly (Paul Squires) - closed.
- 0000842: [Bug] StatusBars not resizing on multiple instances of the same Form (Paul Squires) - closed.
- 0000841: [Bug] Correct Control ID numbering in code generartion for multiple toolbars in rebar control (Paul Squires) - closed.
- 0000832: [Bug] Duplicate message handlers created if control name changed and source file not saved (Paul Squires) - closed.
- 0000837: [Bug] WebBrowser code generation error if 'Custom' property not accessed prior to first compile (Paul Squires) - closed.
- 0000836: [Bug] Font handle not deleted when control destroyed (Paul Squires) - closed.
- 0000835: [Bug] Correct client offset calculation when Toolbar exists (Paul Squires) - closed.
- 0000834: [Bug] Code generation for TabCtrl_SetItemSize and TabCtrl_SetPadding not scaling in DPI > 100% (Paul Squires) - closed.
- 0000833: [Bug] Code generation now keeps UNION and TYPE declarations together (Paul Squires) - closed.
- 0000831: [Bug] Fonts in 3rd party external controls not scaled per DPI setting (Paul Squires) - closed.
- 0000830: [Bug] GDI+ controls failing to load in DLL's (Paul Squires) - closed.
Please try the beta and provide your comments, criticisms, and ideas here. I greatly appreciate your help.
Trying it right now. :)
Oh, this is so cool!!!! Been fiddling with a bunch of things, and I can't wait to get more time to do some serious stuff (won't be till the weekend, drat!)
Thank you!!!
Two quick questions:
1. Will it be possible to copy a property name from the F9 workspace for pasting into code?
2. How to tell what kind of parameter the property is expecting?
For example, I don't have the proper syntax for frmMain.Show
Function FRMMAIN_CMDOK_BN_CLICKED ( _
ControlIndex As Long, _ ' index in Control Array
hWndForm As Dword, _ ' handle of Form
hWndControl As Dword, _ ' handle of Control
idButtonControl As Long _ ' identifier of button
) As Long
frmHelp.Show = %TRUE
End Function
-John
All code that I have changed to the dot syntax in an existing project works great. I noticed that my executable grew from 3,248,128 bytes to 4,255,744 bytes on my first test which consisted of no changes other than enabling the Firefly Object Framework. Thanks for the great new feature, Paul.
Thanks Carl. That is a pretty big project you have there so it is nice to see that the Framework co-existed correctly in your program. That is a substantial increase in size though. FireFly now dynamically generates an object for every Form and Control in your Project (eg. CODEGEN_PROJECT1_FRAMEWORK_CLSAPPFORMS.inc). I wonder if it would be advantageous for FF to scan your code and only output objects that are actually referenced similar to the way FireFly only outputs the FF functions that are referenced. Makes sense.
Quote from: John Montenigro on October 02, 2013, 07:26:22 PM
Oh, this is so cool!!!!
:) Lots to work on to make it even better but I am impressed with the overall direction so far. Thanks!
Quote
1. Will it be possible to copy a property name from the F9 workspace for pasting into code?
I assume you mean, F4, but yes that should be done however it looks like the object name is not being pasted. Other references in that popup are being pasted though. For example, frmMain is not, but frmMain.hWnd is. I will have to fix that.
Quote
2. How to tell what kind of parameter the property is expecting?
A tooltip popup should have displayed when you pressed the Space bar after typing .Show. Eventually I will expand the intellisense functionality better. Likewise, I plan to add descriptions of all the properties and methods to FireFly's "Reference Charts" located at the bottom of the screen.
frmHelp.Show [ ( hWndParent As Dword, ShowModal As Long, Optional nValue As Long ) ]
I have loaded and recompiled my most complex project, and it works as befrore.
The EXE-size changed just fropm 4.23 MB to 4.24 MB.
On closing FF i got this Error (attached), WIn7/x64.
Also my FF-Project still crashes in Windows 8, while no problems in Windows 7 or below.
I could never find out, why. The crash happens when Listviews enter the game, even if they are from an System-Open Dialog.
@Elias ... you know that project.
I fixed that F4 popup selection problem per: http://www.planetsquires.com/protect/forum/index.php?topic=3406.msg24711#msg24711
I also found a more significant problem whereby the popup selection list for an Form object would should the actual properties/methods belonging to a different Form. That is, it would show in the list the Control Objects belonging to a different form. This is fixed now and I will update the Beta download later today (may find more problems as the day goes on).
Quote from: Theo Gottwald on October 03, 2013, 09:15:44 AM
I have loaded and recompiled my most complex project, and it works as befrore.
The EXE-size changed just fropm 4.23 MB to 4.24 MB.
On closing FF i got this Error (attached), WIn7/x64.
Hi Theo - that error will show when FireFly attempts to save your config file to a Read Only area on your computer. FireFly first attempts to write a random file to the folder and if it fails then it will display the message. Are you sure you installed FireFly correctly? For example, the config file can not be saved to the 'Program Files' folder/subfolders.
Paul, i did not install it new, just replaced the working files with the one in the update.
I would say that I did not get these messages with the original version.
Also my FF-Project still crashes in Windows 8, while no problems in Windows 7 or below.
I could never find out, why. The crash happens when Listviews enter the game, even if they are from an System-Open Dialog.
@Elias ... you know that project.
Quote
frmHelp.Show [ ( hWndParent As Dword, ShowModal As Long, Optional nValue As Long ) ]
If I'm reading this syntax correctly, the params appear to all be optional, but it won't compile with just: frmHelp.Show
However, it compiles and works fine with: frmHelp.Show (0,0)
I didn't mean to put the square brackets there. hWndParent and ShowModal are required. nValue is optional.
eg. If you have a main form (frmMain) and want to show a modal popup form (frmOptions) then you would do this:
frmOptions.Show frmMain.hWnd, %TRUE
Thanks for the clarification!
All's well in this part of the sandbox!! :)
-jhm
Quote from: Theo Gottwald on October 03, 2013, 09:34:43 AM
@Elias ... you know that project.
I imagine it is the one i worked with. :) I still remember it very well, even though 3 years have passed.
First post updated. New upload, v1.70 of the beta Framework uploaded.
Paul, any examples on how to convert Menu items (Top Menu Items) and Status Bar Items code?
Hi Andy,
I don't have the menu or statusbar objects implemented yet. I wanted to make sure that the core framework was working okay and that users were comfortable with the way that it all works. It seems from the feedback that I am receiving that the framework is setup okay syntacially so adding new objects like menus and statusbars should be okay for me to start to add. If you think of other areas that would beneficial to add then please let me know.
Quote from: TechSupport on October 04, 2013, 09:17:44 AM
Hi Andy,
I don't have the menu or statusbar objects implemented yet. I wanted to make sure that the core framework was working okay and that users were comfortable with the way that it all works. It seems from the feedback that I am receiving that the framework is setup okay syntacially so adding new objects like menus and statusbars should be okay for me to start to add. If you think of other areas that would beneficial to add then please let me know.
Paul,
Can You added the objects "ScrollBar" and "Trackbar" I will this testing. :=)
I just try.
Very good Paul. Congratulations!
Great Stuff.
This is similar to a process I am working on.
One idea, if possible, add a me.control.text = ? syntax where me is converted to the current form.
This will allow better movement of code. Form name changes or moving code to a new form. FF could pre process the
me to the form it is referring to.
I'm really liking it! Amazing work under the hood Paul. I've been looking at the generated code, slowly wrapping my head around it. It's very elegant. I was wondering how you do the DOT syntax several levels deep. Very enlightening.
I hope someone writes a class-builder-app (I've been thinking about it for at least an hour) that would help create complex class interactions like that. I was constantly switching between tabs in JFP, trying to see how they are meshed together.
It will be necessary to point out in the documentation that control names cannot match any of the properties or methods of controls and forms(in the Object Framework). The compiler message, when it fails, is not so obvious. I had a textbox named "Name" in one project that made the compile fail because there is a "Name" property.
David
A standardized naming convention could help in those cases David. For example, I use the following prefixs for my controls to avoid confusion...
lbl - Label control
edt - Edit Box
rec - Rich Edit Control
cbx - Combobox
lbx - listbox
tvc - Treeview control
lvc - listview control
btn - Button control
res - Resources
img - Image control
frm - Frame control
The list goes on and on, I have one for each control type. So for example, your GUI asks for a users name and that consists of a label and edit box surrounded by a Frame, you wind up with the following control ID names...
frmName
lblName
edtName
And I can easily tell which is which in code and there is no confusion by the compilers. I've yet to run into a conflict this way.
I use a similar syntax approach that George does. Kind of a habit I developed back in the Visual Basic days. I use "txt" for edit boxes, "rtf" for rich edit, "cmd" for button controls. I use "frm" for Form rather than Frame.
I also use frm for Form, fra for frames.
I just returned from the US this morning and could not wait to try the new framework out. I used it on a few projects and I must say it works like a charm. It adds a lot of comfort to FireFly. I just had to do some work on some older VB6 projects and noticed that I really prefer FireFly. And now with the dot framework there is no doubt that FF is a lot more comfortable than VB6.
Great job, Paul!
Rolf
coming from DDT frm was Frame and dlg was Dialog (a form).
I've yet to come up with a consistent name for form in FF3 yet as I haven't truly used it in anger.
Right you are guys. I wasn't willing to test one of my projects. I used a test project. Either one I threw together to test something or one from the forums.
I like to use a suffix on my control names.
All the same, I still think it needs a mention in the documentation. :D
David
Added: The reason it needs a mention is that the code the compiler flags as bad is FF generated. Not user code.
Right now, you can create a valid DOT object (with manual typing, cut & paste, find & replace) - in that it will not fail to compile. But will not do anything useful at run-time.
CustomerFrm.NameLbx.DeleteAllItems()
It looks ok at first glance. While the DelteAllItems method is available for all controls, it only removes items on ListViews and TreeViews. The Clear method is the one that should be used for Listboxes.
This could be caught by FF just before the compile, with a quick scan of all DOT objects - generating a FF Warnings report? There are other ways of course. Just suggesting my preference. Squiggly lines under the DOT object would be just as good, but isn't currently supported by FF (AFAIK).
I should mention that you are immune from this problem if you use the codetips to help build the DOT object.
David
Omission report:
In the Control Class:
The Refresh method is declared to return a long, but doesn't have a "method =".
The InserItem method has a "method =" for the Listview case, but not the Treeview.
David
Quote from: Brian Chirgwin on October 04, 2013, 03:05:52 PM
One idea, if possible, add a me.control.text = ? syntax where me is converted to the current form.
This will allow better movement of code. Form name changes or moving code to a new form. FF could pre process the
me to the form it is referring to.
I like this idea. I have been trying to use the Framework in a project that I am working on and typing out the Form object name is a bit of a pain (especially when it is long). I will look into this idea a little further.
Quote from: David Kenny on October 06, 2013, 04:19:22 PM
This could be caught by FF just before the compile, with a quick scan of all DOT objects - generating a FF Warnings report?
I created a generic Control object that all types of controls use. I used that approach rather than creating specific control objects for each type of control. A generic control object allows you to iterate all controls on a form via a loop if you want. Maybe that type of flexibility is not overly important to most people but at the time I thought that it might be useful. The side effect is exactly what you described - you can use properties/methods that do not belong the control. I like the idea of generating a warning or something. That should be easy to do.
...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
The technique which allows fewest errors sounds good. However, in what situations do you see control iteration being useful?
Quote from: David Warner on October 07, 2013, 06:20:21 PM
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.
Quote from: TechSupport on October 07, 2013, 06:35:30 PM
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 (http://msdn.microsoft.com/en-us/library/office/aa210667(v=office.11).aspx)
Quote
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 (http://msdn.microsoft.com/en-us/library/office/aa210660(v=office.11).aspx)
Quote
For example, you can enumerate the Controls collection of a particular form and set the Height property of each control to a specified value.
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.
QuoteWM_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
Quote from: David Kenny on October 10, 2013, 01:27:04 PM
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).
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.
I didn't get the email. I wonder if I now have my spam filter too high.
Quote from: TechSupport on October 09, 2013, 11:23:42 PM
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.
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.