A recent thread in the PB forums got me to thinking about implementing a "dot syntax" into FireFly. With the advent of the new PB object models, implementing a dot syntax is relatively easy. Below is a working code fragment and proof of concept of how such a system would work. As you can see, it is extremely close to the old Visual Basic syntax.
Such a model allows you do things like set or retrieve text of a control using object properties instead of FireFly Functions.
For example:
txtCustomer.Text = "Paul Squires" ' set the text of the Customer TextBox
zText = txtCustomer.Text ' retrieve the text of the Customer TextBox
Likewise, handling events would also be built into the classes.
I will play with this model to see if it is worthwhile to implement.
What do you guys think of the "Visual Basic" approach? Interested? Add it to FireFly as an additional/optional code generation framework?
#Compile Exe
%UNICODE = 1
%FALSE = 0
%TRUE = Not %FALSE
#Include "clsApplication.inc"
#Include "clsControl.inc"
#Include "clsForm.inc"
Function PBMain() As Long
Local MyApp As iApplication
Local frmMain As iForm
Local txtCustomer As iControl
Local lblLabel As iControl
' Create the Appliction (Project)
MyApp = Class "clsApplication"
' Create a Form and add it to the Application
frmMain = MyApp.Forms.Add( "Form", "frmMain" )
' Create a TextBox
txtCustomer = frmMain.Controls.Add( "TextBox", "txtCustomer" )
Prefix "txtCustomer."
Left = 50
Top = 75
Text = "Paul Squires"
End Prefix
' Create a Label
lblLabel = frmMain.Controls.Add( "Label", "lblLabel" )
Prefix "lblLabel."
Left = 100
Top = 125
Text = "PlanetSquires"
End Prefix
' Retrieve the control based on the control name and change
' properties associated with it.
' The Item method of the Controls collection allows us to
' use either the name or the numeric index in the collection.
txtCustomer = frmMain.Controls.Item("txtCustomer")
txtCustomer.Text = "Paul Squires - new"
lblLabel = frmMain.Controls.Item("lblLabel")
lblLabel.Text = "PlanetSquires - new"
' Display the newly changed text properties
? txtCustomer.Text & $CrLf & lblLabel.Text
Local iFrm As iForm
Local iCtrl As iControl
Local nFormIndex As Long
Local nCtrlIndex As Long
' Iterate through all Forms in the project and all Controls
' on each Form. We use the numeric version of the Item method.
For nFormIndex = 1 To MyApp.Forms.Count
iFrm = MyApp.Forms.Item(nFormIndex)
For nCtrlIndex = 1 To iFrm.Controls.Count
iCtrl = frmMain.Controls.Item(nCtrlIndex)
? "Form: " & iFrm.Name & $CrLf & _
"Control: " & iCtrl.Name & $CrLf & _
"Type: " & iCtrl.ObjectType & $CrLf & _
"Text: " & iCtrl.Text
Next
Next
? "complete"
End Function
The odd thing is I "like" the function method made as it makes me feel like I wasn't using Visual Basic but something different and better :D
All said and done though, I think the dot method makes stuff easier to understand, I can deal with functions if was left as that, but just don't use the PB method of writing stuff like "CONTROL GET TEXT hDlg, lID to strText". Would like to brand the person that thought of that syntax format.
I must admit that ever since objects and classes where introduced in the PB compilers, I still haven't started to use them .. :-[ Not that I don't want to, but so far, everything I needed doing I could do in the 'classic' way. If I have the time, I will start learning about classes and objects ... Or is that just an excuse ..? :o
That said, if FireFly would take care of some of the tedious and boring stuff for me, it would make the threshold to using classes a bit lower.
Just as long as the 'classic' way remains the same too.
So how do you picture this, Paul. Would the user have to set an option to have FF generate code the classic way or the object way? Many controls require sending messages to it to control them. Would this all be covered by the 'object' way?
Kind regards
Quote from: Eddy Van Esch on August 29, 2013, 07:42:42 PM
So how do you picture this, Paul. Would the user have to set an option to have FF generate code the classic way or the object way? Many controls require sending messages to it to control them. Would this all be covered by the 'object' way?
I would envision being able to use either syntax when you create a new project.
If using the new object syntax you would still be able to send traditional messages to the control. You would simply just have to retrieve the hWnd of the control from the control's object.
For example:
SendMessage txtTextBox.hWnd, %EM_SETSEL, 1, 10
The object way of doing it would be:
txtTextBox.SelStart = 1
txtTextBox.SelEnd = 10
FireFly would no longer track the hWnds of the controls and forms, but rather the objects. So, pressing F4 would bring up a list of objects (controls/forms). The biggest change would have to be in the code handlers. For example, notification event handlers would have a different syntax. I doubt that I would allow the traditional and new object event handlers to be intermixed within a project. That would be confusing for code generation. Therefore, the user would have to choose traditional or object when creating the project.
That's my initial thoughts.
As an old VB guy, I would love it.
Wow, awesome!
Quote from: TechSupport on August 29, 2013, 11:09:11 PM
Therefore, the user would have to choose traditional or object when creating the project.
I can live with that.
QuoteWhat do you guys think of the "Visual Basic" approach? Interested?
I like it.
QuoteAdd it to FireFly as an additional/optional code generation framework?
Optional is good, I'd also like the ability to choose traditional or object when creating a project.
Thumbs up from another VB guy!
Another thumbs up! To be really useful it needs to be coupled with a strong intellisense function.
Dennis
I was working with the code today and investigating how to integrate it into the whole framework of the existing FireFly environment. My thoughts are now is that we can have the best of both worlds in that the traditional and new style will be able co-exist within the same project. Hopefully my tests over the weekend will confirm this belief. :)
This is something that I'd been hoping someone would implement for a very long time, so it's a BIG thumbs up from me ;D
Martin
That sounds great Paul. It is a sort of code completion that helps a lot. You be be able to extent it to FF_ functions as well.
Marc
Awesome! I love it.
Rolf
Thumbs up!
I'll give this a thumbs up as well. My biggest concern would be for existing projects that use the "classic ff_function" can still be changed and updated. I've got lots of programs in play here at work; on some, a conversion process would be a daunting task.
Quote from: TechSupport on August 30, 2013, 01:51:48 PM
... My thoughts are now is that we can have the best of both worlds in that the traditional and new style will be able co-exist within the same project. Hopefully my tests over the weekend will confirm this belief. :)
I have not been coding much this year, and am happy to think that I could learn the new Object syntax without having to discard or re-write old code.
-JohnM
I have tested and prototyped the new object syntax in FireFly. I have it working and it seems to be pretty easy to use. It will take me some time to create all of the methods and properties for forms and all the different controls. I will post a preview/test version for you guys to play with as soon as I can.
I am really looking forward to that preview version!
Rolf
Sounds like a worthwhile addition!
David
Definitely something i would like.
The dot syntax does help a lot with finding that option/procedure and is way faster to type.
Thumbs up.
Just a quick update: Everything is progressing perfectly with the new syntax. It is called "FireFly Object Framework". It is the closest VB6 / VB.Net representation for any PowerBasic product available today. Stay tuned, hopefully I will have it completed soon and ready to upload in the next FireFly update.
I don't suppose the new PowerBasic leadership would finally open up the debugger, thereby giving FireFly the final killer feature???
We can dream...
Several years ago I asked for access to the pbd file format. At the time, Bob was not in favor of sharing that type of information. IIRC, compiling with the -d option generated the debug file.
Will the new syntax be able to work with multiple instances of a form? I have an entry form with multiple open copies. I use the GetDLgItem(hWndForm,ID_Control) to get the unique control handles.
Carl,
I was going to ask about that myself. I have done what you are in a similar way. I used to copy the handles and ID's into an array, as each one is opened. In FF, opening the next form re-uses the same variables to store the Form handles and ID's as the one before because it wasn't design to be used the way we are). The variables always contain the the last-opened-form values. I switched to using a PowerCollection to store a UDT containing the handles I need (where the hWndForm is the key) a while ago.
Additionally I was going to ask Paul if it would be easy to have Form Arrays (much as we have control arrays). Then you could use: CustomerForm(2).NameTxtBx.hCtrl to retrieve the NameTxtBx handle from the second instance of the CustomerForm. Of course you wouldn't need the handle as often if we could also do this: CustomerForm(2).NameTxtBx.Text = "Carl Oligny"
David
hmmmm.... those are very good questions. Multiple instances of forms. Not sure, I will take a look. Off the top of my head I would say 'no', but I will try to come up with a workable solution. It does seem like something that a programmer could regularly encounter.
Quote from: TechSupport on September 24, 2013, 08:39:01 AM
hmmmm.... those are very good questions. Multiple instances of forms. Not sure, I will take a look. Off the top of my head I would say 'no', but I will try to come up with a workable solution. It does seem like something that a programmer could regularly encounter.
Paul,
I look forward that FF3 is OOP based with the dot syntax very interesting for VB5/VB6 translated into PowerBasic with FF3. I love FF3 and PowerBasic.
Look to the website with the developer Larry Carliton he started all the windows controls and developed it with PowerBasic Objects. All his code is source and free for use
http://www.cur-ion.net/
Windowing Classes : http://www.cur-ion.net/classes.html
Begining of using classes for Windows in PB. Has application, and main window classes as well as most common controls. Still working on demos and some of the properties / methods for common controls.
Some of the features
"Message reflection" - Sends parent notifications to child class.
Message Bridge - Intermediary class that bridges from a windows procedure call back to classes.
Most windows common controls, still working on these
MessageExtensions - Allows injecting handling of messages. This allows an application to handle way the click event for a button without modifying the button common control class.
There are 4 common ways to insert user code into existing controls:
Add an extension to a control
Write code in the controls Proc method, use this for code common to all controls of this type
Add an extension to a window
Write code in the windows Proc method. Feels more like SDK programming.
The 1st two methods work because WM_COMMAND, WM_NOTIFY are reflected back to originating window. Also WM_SIZE is sent to child windows.
List of latest changes until it stabilizes a bit:
3/27/2012 - Merged test app and demos so each .bas file is a demo. Demo's that respond to events are shown using a control extension. Fixed a small bug with reflected messages that could recurse infinitely.
4/2/2012 - Updated Button, ImageList, ComboBoxEx, ListView, TreeView demo's and controls. Minor other changes.
http://www.powerbasic.com/support/pbforums/showthread.php?t=49849
I used VB for many years and are quite comfortable with the "dot" syntax. I use FireFly daily and had to get used to the FF functions. I miss the VB approach and welcome your trying to integrate it into a new FireFly. GOOD WORK !!!
Robert
QuoteInterested?
Late to the game â€" indeed I am interested. It increases code readability and efficiency, and I'm so about the latter. Especially since I've become a pretty serious procrastinator the last year or so. Shortcuts like this and really good Intellisense is so easy to like that I still often want Word/Thunderbird etc. to suggest the ending of my words while I type. Hey, I'd even take a suggestion for whole sentences.
Reading through the thread I've seen no evidence to chip my interest in this syntax for the mentioned benefits. Cant credit a lot of thumbs to deter the desire, so mine's up too! 8o)
Now I'm off to read myself up on the progress of the framework, in risk of being overly exited for a while.