Hi Everyone,
I plan to drop support for PB/DLL 6 from the new FireFly 3 that I am working on. If any FireFly owner has any major objections to this then please let me know as soon as possible.
The reason for dropping PB6 is that it lacks many of the features that I would like to use in the FireFly code generator (as well as the more advanced DDT commands that I will need for DDT code generation).
Sounds OK to me.
No problemo
Marc
I even have begin to drop support for PBWIN 7.x in the wrappers for DirectX 9.0 that I'm writing. The ability to make several declares for the same function alias is very useful for not to have to duplicate functions wrappers for inherited methods of other interfaces.
We have to wait two or three years to see a new version of the compiler, only to be forced to not use any of the changes and new features to maintain compatibility with older versions.
I am on board with that. I only use 8.x anyway.
I hope to simplify a lot of generated code through the use of Macros (which were introduced in Version 7). Also, at times, I need to use the "/C" compiler command which only became available in Version 7. Also, the whole issue of COM support.... Also, the different ways that a sub/function can be called in code when the "Call" keyword is omitted.... As well as the passing of certain parameters as byVal.... In addition, the wealth of new string handling functions.... blah blah blah.... It would just be easier for me to be able to output code not having to ensure that it adheres to a lowest common denominator, PBDLL. :)
Go for it. If it makes your job easier then I, for one, don't have a problem
with it.
But I hafta wonder, how many times are you going to re-write the guts
of FireFly? Surely you won't do this on each major version, right?
Quote from: Paul D. ElliottBut I hafta wonder, how many times are you going to re-write the gutsof FireFly? Surely you won't do this on each major version, right?
Trust me, rewritting the guts of this beast is not something that I wanted to do but I am soooooo happy that I did. The first FireFly used an XML linked list to handle the internal data. Pretty cool, but it became brutally slow when many forms and controls were involved. FireFly 2 improved on the XML stuff by converting to an array based solution. Still, better, but a bit wasteful with resources and not as flexible. FireFly 3 is now 100% pointer based with manually allocated memory held in linked lists. Everything I have coded since switching to this format has been incredibly easy. Also, using FireFly to create the actual FireFly 3 forms makes re-writing the menu, statusbar, toolbar editors (etc...) very easy.
Granted, hopefully I won't be eating my words for FireFly 4 by admitting that I am re-writing again! ha ha ha ha :)
So how many levels of recursion are you doing writting FF with FF? Each revision improves FF which can then improve itself which can then compile a better FF that can improve itself, etc...
Quote from: Roger GarstangSo how many levels of recursion are you doing writting FF with FF? Each revision improves FF which can then improve itself which can then compile a better FF that can improve itself, etc...
To be honest, by the time FireFly 3 is ready, my hope is that it will be used to compile itself. Right now I am still using 2.65 to compile version 3. I still need to add code to handle the external 3rd party controls and the actual code generator itself but most of the really hard stuff is done (famous last words).
Paul
Can you support the DDT toolbox
Thanks
Stephane
Dear Paul
I'm very happy that I bought FireFly SDK Designer but I have tree important questions:
1) Can you please add more worked samples as examples with full worked code for all the standard components like textbox, combobox, listbox, dialogs, canvas etc....
2) Can you added 2D drawing FF functions like drawe lines, bars, boxes, circels, ovals because I would like programmming applications for the electronics en its important graphs en mathematics
FF_DrawLine()
FF_DrawCircle()
FF_DrawOval()
FF_DrawRect()
FF_DrawFillCircle()
FF_DrawFillRect()
FF_DrawFillOval()
FF_DrawPixel()
FF_DrawCanvas()
FF_DrawBgColor() etc.....
Can you added graph functions into the FF functions list
3) Can you added for ease transfer from variables that store numeric converts into string format and virsa?
FF_ParseInt() ==> convert string into integer
FF_ParseDouble ==> convert string into double
FF_IntToString
FF_DoubleToString
Kind regards
Stephane
Hi Stephane,
DDT... yes. It is on the FireFly 3 to-fo list. Graphics commands... yes. It is on the FireFly to-do list.
Personally, I don't care..
But from a business/professional stand point I think you should keep support for PBv6. But limit the compile to .DLLs only. A simple trigger to turn off all the controls & form stuff. (And hey, if possible allow the 16bit compiler to work.)
I'm saying this because its clear that Microsoft has abandoned Visual Basic. I think that PB & FF have the potential to "save the Visual Basic World." Keeping things clean & maintaining integrity for backward compatibility for v6, and possibly 16bit could make your product *shine*. (not that it doesn't already.) :)
But clearly, this could be a long ball home run if you implement & market it with the intent to capture all the "lost" VB developers.
Just my 2 cents..
Tye
Hi Paul.
I am very happy with FireFly and I am eagerly awaiting for Version 3 (I hope as soon as possible...), because I see it as a product with still enormous potential.
I would just ask you if any of the following improvements will be added in this release:
1) when you select more than one control, show only the Properties that all those controls share. If you change any of these Properties, all controls change their Property according to the value you entered. If the controls have initially different vales, just do not show anything in the value (thus indicating that there are several values for that property).
2) please add the syntax control and formatting. If I declare a variable as MiXeDCase, then each time I write mixedcase the Editor will change automatically to MiXeDCase. You can take the most significant declaration (i.e., check if there is any Local declaration in the same procedure, otherwise proceed up one level) to choose the correct case. And when the declaration itself changes, just change all occurences of that variable along the text where it does not collide with any local variable with the same name. The same goes with functions and subs.
3) Likewise, the Editor should add spaces automatically to clarify the synytax, as in VB. A blank space before and after the = sign, after the function/sub name, and so on.
4) Finally, I would really like to see a Grid control built in in FF :D. It would be great to see, for example, EGrid32 shipped with FF for a reasonably small increase in price. This way all users who buy FF also buy EGrid32, and you will simple give the difference to Egrid32 developer, who would benefit from all FF sales. Of course the grid author should agree with this kind of agreement. You may also offer two distinct versions, with and without the grid control...
Anyway, keep up the good work, and thank you for the fantastic support you are giving to your product.
Emiliano
FireFly already has demo versions of EGRID32 and SIGRID that you can use. You can access these controls from the "Tools" pallette.
Hi esciarra,
Your suggestions have appeared on this forum from time to time over the last couple of years - especially from FireFly users who have done a lot of Visual Basic programming. To be 100% honest, I have no plans to implement the type of code fixups and automatic spacing that you have suggested. The amount of overhead to implement such a feature is just not feasible. I am also dedicated to using the Scintilla code control and that edit control does not have those features built in.
I do appreciate your suggestions :) I am also looking forward to getting version 3 completed. It will be a while yet but it is progressing slowly but surely.
#2 sounds alright. QBASIC used to do that. That combined with an autocomplete would be the biggest improvement. Something like VB with a popup listbox for variables within a type, etc too.
Can't say I like #3 though. Over the years I've come to use spaces differently on equals. When assigning I use a= 2 and when comparing I use IF a = 2 then... That way I know when either case is used. It kinda happened over time from languages that assigned by a:= 2 and comparing was a == 2, etc.
I don't like the spaces for functions either. I like the C++ look since a function is like a variable- MyFunction(firstParam, secondParam, thirdParam) with only spaces after the commas in the param list. Spaces are for Subs- MySub firstParam, secondParam, thirdParam
Paul,
Put me down as a vote to implement AutoCapitalization, this is really a nifty way to prevent boneheaded coding errors.
JR
Hello Paul,
Haven't heard much about FF 3.0 the last couple of months... I and other customers of FF are anxiously waiting it's debut. Can you share with us the statis of it's development?
I was a bit slow in coding this summer. A fair amount of the FireFly conversion is complete. Actually, all of the hard stuff has been converted. The user will not see much different in the user interface because I want to keep it consistent with FireFly2.
There is a new code editor (Scintilla) and a new ToolBar Editor.
The code generator is all new and greatly improved for speed.
Lots of internal things are new that will allow me to more quickly build in new features and enhancements.
I hope to start work on the new code librarian for FireFly that will allow users to seemlessly add subs/functions to a library of pre-built code (much like using the FireFly Functions FF_). This way, users can create a set of routines and easily have FireFly include only the needed ones in their project and automatically generate their declares. It will also allow an easy way for fellow FireFly users to share code amongst themselves.
Before you ask... I have no idea when FireFly 3 will even be ready for beta testing. :) I really don't want to hype FireFly3 in these forums or the PB forums because I know how anxious people get and disappointed when a planned release date (or even an approximate date) is missed. I am following my 3 page roadmap for new FireFly 3 features.
I am just one person and FireFly is so huge and the planned new features are vast. Just the tutorials and documentation alone will be a struggle.
:)
Paul,
.. I know when it is ready, FF 3.0 will be a stellar product. You know you can put me down as a customer for FF 3.0 when it is ready.
.. I will put it on my Santa Claus wish list.
Keep up the great work !
I think re-usability will be of great importance too especially in this new FF_Functions type thing and in reusing forms. Will there by some type of markup used with something like <FormName> and such so when the routines or Forms are loaded the values are replaced with the current Project/Form's name and allow reuse. That is my biggest annoyance right now is bringing a form or code from a form into a new project from an old and having to manually edit all the code and control names, etc. It would be really nice to have some type of linking, so when changing a control's name the code is adjusted too, etc.