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

[Andy Flowers]

Paul, any examples on how to convert Menu items (Top Menu Items) and Status Bar Items code?

[Paul Squires]

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.

[Stephane Fonteyne]

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. :=)

[Marco Ruiz]

I just try.

Very good Paul. Congratulations!

[Brian Chirgwin]

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.

[David Kenny]

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

[George Bleck]

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.

[Paul Squires]

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.

[Rolf Brandt]

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

[George Bleck]

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.

[David Kenny]

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.

David

Added:  The reason it needs a mention is that the code the compiler flags as bad is FF generated. Not user code.

[David Kenny]

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

[David Kenny]

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

[Paul Squires]

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.

[Paul Squires]

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.