PB7, DLL Projects, and Console Projects - to be dropped?

Started by TechSupport, September 21, 2007, 03:08:13 PM

Previous topic - Next topic

TechSupport

Hi everyone,

I am looking for a little bit of feedback. I am planning (pending agreement from customers) to drop the current implementation of projects that include "Dynamic Link Libraries" and "Console Applications". In its place I want to include a Generic Project. (The current "Standard EXE" GUI based project would not change).

A Generic Project would be like firing up the JellyFish Editor or the PB Editor and starting from a blank slate. You would have the capabilities and freedom of a full project environment without being tied to having it either strictly a DLL or Console application. With a generic project you could easily add a LibMain if you wish or even select the PBCC compiler for a console based application. There would be far less restrictions then there is now.

I plan to drop FireFly's current implementation of the "Console Project" that simulates PBCC by using the WinAPI and modification of the PBWIN produced EXE. I venture to guess that only a very small portion of FireFly users ever use this functionality (I could be wrong but in the years that FireFly has been released I think that I have only answered one support question about it).

Lastly, how do you feel about me dropping PB7 support. I think that the time is right to finally let that compiler version go.  :)


Marty Francom

#1
No problem here... especially if that will help get FF3 to market sooner.

TechSupport


Marc Van Cauwenberghe


TechSupport

Yeah, I know it has been a hell-of-a-long time getting FF3 finished. I am very sorry about that. I am happy to report that we are in the home stretch now. All of the major portions of the program are done. It is the little things that I am fixing now.

TechSupport

Ok, PB 7 has been dropped. Likewise, DLL and Console projects are replaced by the "Generic" project.

PBCC 8 support has been added.

jthompson

I may be chiming in late, but I'll be fine if you can do these two things:

- Create a 'Window' project where there is no initial / startup form.
- Keep FF_functions for using the console.

Looking forward to FF3!

-John

Roger Garstang

What was ever decided on DDT?  Is having it a reason for dropping some of the projects?  I'm up for integrating more JFP functionality into it...maybe a project type that starts it in editor mode only, then we can do whatever we want.  Maybe even select between Win and CC compilers.  I'm still working on a better Service Template too.  DDT and FireFly Windows neither one work, so it will be a special kind of editor only project.  Building custom projects/templates would be cool.  Specifying defaults like Designer off/on, what compiler, base code, etc.  I still think Template of Services, Control Panels(.cpl files), and Screen Savers as project types would be a big plus.  As for the project types, I never used the Console types, and DLL fits more into the category of Designer Disabled...

Roger Rines

#8
I've been distracted by work so I'm just seeing this now.

I've used FireFly for Console Apps & DLLs because it was available, but I didn't like it for those task as much as I like the JellyFish/Lynx combination.  In fact, I find JFP/Lynx to be an addiction that might not be possible for me to break unless something like it appears to replace or exceed the utility that combination provides.

From the perspective of another vote, loosing the ability to build Console APPs and DLLs isn't much of a loss as long as the JFP/Lynx combination continues to be viable.

TechSupport

Quote from: Roger Garstang on November 02, 2007, 10:25:56 PM
What was ever decided on DDT?  Is having it a reason for dropping some of the projects?  I'm up for integrating more JFP functionality into it...maybe a project type that starts it in editor mode only, then we can do whatever we want.  Maybe even select between Win and CC compilers.  I'm still working on a better Service Template too.  DDT and FireFly Windows neither one work, so it will be a special kind of editor only project.  Building custom projects/templates would be cool.  Specifying defaults like Designer off/on, what compiler, base code, etc.  I still think Template of Services, Control Panels(.cpl files), and Screen Savers as project types would be a big plus.  As for the project types, I never used the Console types, and DLL fits more into the category of Designer Disabled...
Hi Roger,

I think that we're both on the same page. I have implemented a 'generic project' which is essentially a blank JellyFish type editor program. This way you can use the project to create DLL's, Console Programs, Services, etc... (basically anythin non-GUI related).

BTW, I am implementing DDT as a project type as well. I believe that it is a strong market that FireFly needs to be a part of.

Now that the wedding is over, I am starting to get my programming life back. (about time.... feels like I have been programming FireFly 3 forever!)  :)


TechSupport

Quote from: Roger Rines on November 03, 2007, 03:09:33 PM
I've been distracted by work so I'm just seeing this now.

I've used FireFly for Console Apps & DLLs because it was available, but I didn't like it for those task as much as I like the JellyFish/Lynx combination.  In fact, I find JFP/Lynx to be an addiction that might not be possible for me to break unless something like it appears to replace or exceed the utility that combination provides.

From the perspective of another vote, loosing the ability to build Console APPs and DLLs isn't much of a loss as long as the JFP/Lynx combination continues to be viable.
Hi Roger,

I hear you loud and clear about the JPro/Lynx combination. You will be pleased to know that the new FireFly has a much improved method for finding/organizing subs/functions. It doesn't go down to the level of Lynx (i.e. Select Case statements, etc...) but it is much better for jumping between the different subs/functions in your project.


Roger Rines

Good news Paul.

I find my need to keep code modular and resuable helps me get through the process of development rather quickly.  However, to keep things modular it means that each Include file ends up having specific details that I need to find like Equates, Includes, Globals, etc.  Lynx's Explorer interface makes task like that simple to see, grab, and then paste without much effort.  If you are adding the ability to look into an include so you can just click on a Sub/Function and have it appear, that will make the interface much faster than the drop-down ComboBox interface.

Wish List Items?
Will the Module section allow us to arrange the order in which the modules appear?  In Lynx I do this while working with the integration of a module by keeping that module near the top of the list, or near where I might be working in a program specific module.  By keeping things that are most active near each other in the module listing I find I don't have to jump all over the place with the scrollbar to find something.

Another feature about Lynx that makes it handy is the ability to Right-Click on a variable, expose a tool like Find Text where entered text found then creates a result jump-list allowing us to traverse the project.

Having more than one project open at a time would be a great feature.  For example, when building DLLs, I find having the ability to tweak a TestBed EXE being used to test code within a DLL project is a great time saver.

Tyrone Lee

Hi guys!

Please don't drop PB7 support until PB9 comes out. You should at least support the last two versions of the compiler. Only supporting one forces people to upgrade and/or you'll lose customers. I personally follow and "every other" upgrade model. I started with PB 1.0, and I'm on the "odd" cycle. PB9 is my next upgrade. :)

I am using FF2.86 and it seems to work much better than the previous version. Cleaner.. Well done!

Just my two cents..

Tye

TechSupport

#13
Hi Tye,

Thanks for your feedback. The only 'problem' as such is that PB7 is well over 3 years old. There have been 5 versions of the PB8 compiler since that time. I understand your reluctance to upgrade to PB8 but (in my opinion) the move to 32-bit in PB8.04 is alone worth the upgrade.

... granted, it seems like PB9 may be here by the time FF3 is ready. Sheesh, FF3 is taking waaaaaaaaaaay too long to finish.  :)