FireFly 3 and PB/DLL - any concerns?

[TechSupport]

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

[JR Heathcote]

Sounds OK to me.

[Marc Van Cauwenberghe]

No problemo

Marc

[Jose Roca]

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.

[Mark Strickland]

I am on board with that.  I only use 8.x anyway.

[TechSupport]

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.  

[Paul D. Elliott]

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?

[TechSupport]

But 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

[Roger Garstang]

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...

[TechSupport]

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...

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

[Anonymous]

Paul

Can you support the DDT toolbox

Thanks
Stephane

[Anonymous]

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

[TechSupport]

Hi Stephane,

DDT... yes. It is on the FireFly 3 to-fo list. Graphics commands... yes. It is on the FireFly to-do list.

[Tyrone Lee]

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

[esciarra]

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

Code Select Expand

MiXeDCase, then each time I write

Code Select Expand

mixedcase the Editor will change automatically to

Code Select Expand

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  . 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