Visual FreePro

[foxmuldr2]

I am an advocate of free software. In late 2010 I began working on a free software project (currently unreleased) called Visual FreePro.

Visual FreePro was to be a VFP9 follow-on (since Microsoft killed it). My idea was to have 75% support directly in source code (up to 75% VFP commands would run without any source code changes), to have 15% of VFP code needing slight modifications, and the remaining 10% would be thrown out and replaced with other code I would like to see. I was also going to provide full (true) backward compatibility support from the DOS-based versions of FoxBASE+ on through the FoxPro for Windows versions, allowing those apps to run 100% without any modifications.

I am wondering if anybody here would like to participate in such a project?

I have the application started in Linux, written in GNU's C++ compiler. I have the class structure setup (which allows everything else to work with dot references, including _vfp, _screen, etc.), part of the source code parsing engine completed (for an unrelated project I worked on), and in terms of "the next thing to do," am ready to start working on that part of it (source code execution).

I have considered continuing this project but have not worked on it much since early 2011. The time may be for this project to take off again.

Best regards,
Rick C. Hodgin

 

[foxmuldr2]

I would be looking not only for developers to write Visual FreePro, but also people to test it and document each function.

I remember Fox Software's FoxBASE+ coming with a very simple black and red 3-ring binder which had each function and command in alphabetic sequence, with an explanation on each page, some source code examples, and see other tabs.

I'd like to make a literal simple help file like that. Would prefer a wiki.

I can set all of this up and get it started if anybody would like to help out.

Best regards,
Rick C. Hodgin

 

[craigber]

Several people and companies have tried to do similar things and failed. I'm not going to hold my breath on your efforts, but good luck.

Craig Berntson
MCSD, Visual C# MVP,

http://www.craigberntson.com/blog

 

[foxmuldr2]

Craig,

I'm not sure why you posted any comment here at all, except to be discouraging. Thanks?

Best regards,
Rick C. Hodgin

 

[craigber]

My point was, it's a HUGE job. Much bigger than you think it is. Companies that supposedly were well funded have tried and failed. Individuals with good intentions to do an open source project on this have tried and failed. I think that's why VPFX has worked. The projects are small and managable, yet add great value.

Don't get me wrong, I wish you success.

Craig Berntson
MCSD, Visual C# MVP,

http://www.craigberntson.com/blog

 

[foxmuldr2]

Good luck ... I wish you success.

Thank you.

Best regards,
Rick C. Hodgin

 

[Mike Lewis]

Rick

I'm curious about the ten percent that would have to be thrown out.

You say you aim to provide "full (true) backward compatibility support from the DOS-based versions of FoxBASE+ on through the FoxPro for Windows versions, allowing those apps to run 100% without any modifications." If that's the case, wouldn't you need to keep 100 percent of the language?

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[craigber]

VFP sill carries baggage from the Mac and Unix versions. Surely that won't need to be in there.

Craig Berntson
MCSD, Visual C# MVP,

http://www.craigberntson.com/blog

 

[Mike Lewis]

VFP sill carries baggage from the Mac and Unix versions.

True. I'd be surprised if that consituted the ten percent. But what do I know?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[foxmuldr2]

I'm curious about the ten percent that would have to be thrown out ... If [100% backward compatibility with FoxBASE+ and FoxPro for Windows is required], wouldn't you need to keep 100 percent of the language?

It's been over a year since I considered any of this stuff. I don't remember all the details.

There were a lot of features added post VFP6 that I'd throw out. Some probably common use features (like ActiveX/OLE support so it would work on other platforms -- though I would provide similar support through supplied DLLs which handle common things, allowing also for developers to code and contribute their own extensions back to the community), some of the reporter abilities (though I would replace the reporter with something far more WYSIWYG and flexible to use), some SQL engine enhancements, several things I can't remember off the top of my head.

I would add:

SET FREEPRO TO [FB,FW,V3,V6,V9]

* Emulate FoxPro at these levels:
*    FB = Multi-User FoxBASE+ 2.1
*    FW = FoxPro for Windows 2.6
*    V3 = Visual FoxPro 3.0
*    V6 = Visual FoxPro 6.0
*    V9 = Visual FoxPro 9.0
* (no support for 5.0, 7.0 or 8.0)

This would allow certain functions to behave as they did in those particular versions. These can be set while the code is running.

I would alter the way some things are done today so they aren't quite as obtuse. For example, ICASE(). Having a sequential series of parameters is obtuse. Instead, I would devise a definition which allows for the test conditions and then multi-line code snippets to be created (similar to way DEFINE CLASS works today, but it would be DEFINE ICASE name), which then would be referenced by name in the ICASE() statement.

DEFINE ICASE myicase
[LPARAMETERS lxTest]
[RETURNS lcReturn
* Whatever value lcReturn has at the end is what's returned]
* Can have explicit RETURN clauses at any point
    CASE condition1
        * code goes here
    CASE condition2
        * code goes here
    OTHERWISE
        * code goes here
ENDDEFINE

* Use in code:
k = ICASE(myicase[, variable])
* the ", variable" portion is not needed as myicase will
* inherit the current data environment plus variable state.
* Double-click on "myicase" in the ICASE() statement to
* edit its definition.

In source code the GUI editor would present it as a popup or tooltip (similar to the way memo fields pop up with Ctrl+PgUp in a browse window). That way the code can be multi-line, vertical, spread-out, formatted, easy to observe, easy to line debug, and with full support of multiple commands per case condition, etc., with the end result being a complex case condition able to be used easily as an immediate.

Things along those lines are mostly what I mean by throwing some things out and adding my own stuff, though some of my own stuff would include tables as objects. Records as objects. Fields as objects. Memory variables as objects. Basically everything as an object, able to have objects added to them, method code, event responses, including triggered global and local user events.

All of this is in addition to supporting the standard syntax used today.

A new data storage format would be added to explicitly indicate what type and size I want to store my variable as, such as integer, unsigned integer, floating point, character string, unicode string, etc., and I would provide full conversions between types.

* Store 1234 as a native type without explicit form
foo = 1234
* Store 1234 explicitly as a 32-bit unsigned integer quantity
* Note:  This now allows over-/under-flow events to be
*        thrown (see addEvent() below).
foo.u32 = 1234
* Store 1234 as a 64-bit floating point quantity
foo.f64 = 1234
* Store .t. as a text string
foo.c = .t.
* Store "hello world" as unicode
foo.u = "hello world"
* Store current contents as unicode (if not already)
foo.u = foo.as(u)

Other such options.
Objects make it possible:

foo.alltrim         && same as foo = ALLTRIM(foo)
foo.release         && same as RELEASE foo

* Add an object to a variable
foo.addObject("Name", "Data tag to go with it, can be anything")

* Add method code to a variable
foo.addMethod("name", reference to code when called)

* Specify that this variable should respond to an event
foo.addEvent("event name", reference to code when called)

* Create multiple clones of itself, which for mere data is
* only of mild interest, but if objects, events or methods have
* been added to a variable, can be more powerful (see below)
foo.clone(newvar1, newvar2, newvar3)
* And of course
foo.saveAsClass(...)

Assignment within use:

* Today:
foo = 1234
sam = foo * 4

* FreePro:
sam = foo.(1234) * 4

The object nature of everything makes a lot of possibilities.

Other additions are synchronous debugging between two machines, remote debugging, real-time variable monitoring (debugger doesn't have to have code paused to examine variable contents, but continues to examine variable contents while running).

Lots more. Can't remember them all right now. Visual FreePro was well thought out. I may push the code to github in the near future regardless. The object/class structure and program stack I've developed may be useful to another project anyway.

Best regards,
Rick C. Hodgin

 

[foxmuldr2]

One other huge one was wide multi-threading support. Threads are spawned by a setting for global or local events (so they execute in parallel, or suspend execution until they are completed -- which is VFP's model today):

DO whatever WITH parameters NEWTHREAD

* And for function references
k = some_function(parameters).newthread(tag)
* Execution will continue here in parallel
* Then you can use a join clause:
_threads.join(this, tag)
* Code execution will not continue here until
* some_function(parameters) completes.
* Multiple tags can be used so several spawned-
* in-parallel things can be joined at once.

* The same can be done with DO:
DO whatever WITH parameters NEWTHREAD(tag)

Best regards,
Rick C. Hodgin

 

[Mike Lewis]

Rick,

I must say it sounds very ambitious. You'll need a lot of time - and a lot of helpers - to make it work. I wish you luck with it.

Personally, I would favour a version that abandons FoxBase and Foxpro 2.x compatibility in return for a lighter language. I'm thinking of things like the old UI commands (@ / SAY, @ / GET, READ, etc), as well as the commands that no-one ever uses (FIND, INSERT, JOIN, etc) and perhaps the old window commands (DEFINE WINDOW, etc).

I would say get that working first, before trying to add radically new features like object-oriented records. But that's just my opinion. You've obviously thought about this in great depth, and a more aware of the issues than I am.

By the way, you wrote:

I remember Fox Software's FoxBASE+ coming with a very simple black and red 3-ring binder which had each function and command in alphabetic sequence

I still have that binder.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

In my oppinion the time has passed for such a project, if you want to make it a commercial success. Your name for it suggests not so, at least not for the language itself. Even disregarding that, the german in me warns me about legal issues. Even if reimplementing the language fully yourself, this hurts rights. reminds me of replicates of brand articles.

As a foxpro guy I would like such a resurrection, even if only compatible partly. For any private programming that would be sufficient, already.

Also there are good chances to make the most wanted changes: Unicode support, specifically for the native controls and no 2GB limitation. In my oppinion the 2GB limitation is none, as it's impractical for working the xBase way anyway, you should go the client/server route with that much data anyway. There are other things to fix with DBFs, eg the mechanisms of locking table or record shouldn't make use of file system trickery. The file structure and file access should be changed to avoid problems with the SMB protocol, oplocks and leases, especially where multiple client access is likely the developer should be able to decide when caching would be an advantage and when not.

Bye, Olaf.

 

[foxmuldr2]

Olaf,

xBase was ruled to be a non-exclusive dominion of dBase in the Ashton-Tate / Fox Software case. So, any free offering would not be in rights violation. And since it would be written entirely from scratch, entirely of new source code, all free software ... it would be out there.

I have no plans to make it commercial. Although, I wouldn't mind having a lifetime of work working in VFP (Visual FreePro) development.

One thing I would like to add is more native integration between client/server and VFP's inernal abilities. I don't like the idea of coding for complex remote SQLEXEC() statements. I'd rather see that handled by a converter and allow native VFP code to be written, when then executes the commands on the server.

I have two paths for this. One is here (a native relationship between VFP (Visual FreePro, perhaps called VFrP from here out), which relies upon an interface on the local machine to "behind-the-scenes" handle client / server natively:

http://www.youtube.com/watch?v=EM56J1QRS-I

The other is through add-on modules which are plug-ins to VFrP which would allow these kinds of interfaces to be handled directly as an extension of the VFrP app itself, without the need for something like InDisk.

Best regards,
Rick C. Hodgin

 

[foxmuldr2]

A couple fixes. I've noticed myself making these particular states recently. Odd.

One thing I would like to add is more native integration between client/server and VFP's inernalinternal abilities.

I'd rather see that handled by a converter and allow native VFP code to be written, whenwhich then executes the commands on the server.

Best regards,
Rick C. Hodgin

 

[foxmuldr2]

I remembered another big one. It was the ability to edit any user class code used on any form in the traditional way (bringing up the code and changing it).

Such changes then propagate through all open instances of the class, and changes made to any of them are reflected in all of them in real-time.

This would allow a form to be opened which includes code from twelve separate user classes. Each of those classes could be altered, as well as native form code, from the one instance of the form. And if multiple instances of a class are in use, or if multiple forms are open and each form uses some of the same classes, changes made to any of the open form editor windows goes to all.

It's the way it should've been all along.

Best regards,
Rick C. Hodgin

 

[foxmuldr2]

Another big one was a "quit.force" option, which would remove the "Cannot Quit Visual FreePro" type messages.

It's all starting to come back to me.

Best regards,
Rick C. Hodgin

 

[Olaf Doschke]

>Such changes then propagate through all open instances of the class, and changes made to any of them are reflected in all of them in real-time.
If I understand you correctly, that would alter parent classes? Or all equal instances of classes? In both cases I don't see this as good or wanted or elegant. If you want to override class behaviour, you can do at the last instance level in foxpro, eg at a control put on the class. If you want that change in all instances, you better change the class, not the instance. I would like that to stay that way, besides discouraging such things.

I agree what you said in the other threa, OOP can be an overhead for very small or even medium sized apps, but then you should build a set of classes (framework) over time, which pays very soom after the third or fourht project, even small ones. And this way of propagating code would only be welcome, if you can specify, whther you want that propagagion or want it to be a local change. Any such change propagation would resemble search&replace within copy&pasted code, which is not a good way of programming, is it?

Good reasons to propagate changes would be the change of a table field name or anything having a more or less public scope.

Bye, Olaf.

 

[foxmuldr2]

Such changes then propagate through all open instances of the class, and changes made to any of them are reflected in all of them in real-time.

If I understand you correctly, that would alter parent classes? Or all equal instances of classes?

Yes.

In both cases I don't see this as good or wanted or elegant. If you want to override class behaviour, you can do at the last instance level in foxpro, eg at a control put on the class. If you want that change in all instances, you better change the class, not the instance. I would like that to stay that way, besides discouraging such things.

All overrides would still be in effect. What I'm proposing would save you doing this:

(1) Open the form which has some user classes on it.
(2) Edit, in the process realize you need to change some parent class code.
(3) Close the form.
(4) Open the class.
(5) Edit.
(6) Close the class.
(7) Re-open the form.
(8) Continue editing the form.

In Visual FreePro, the sequence would be:

(1) Open the fom which has some user classes on it.
(2) Edit, in the process relalize you need to change some parent class code.
(3) Change the parent class code.
(4) Continue editing the form.

The changes made to the parent would propagate through all open instances of the class, but all overrides would remain in effect.

Best regards,
Rick C. Hodgin

 

[Olaf Doschke]

One other thing: I personally know Christof Wollenhaupt, the author of guineu:

http://guineu.foxpert.com/.

He only implements what he needs to make some smaller apps run on mobile platforms via this runtime, he also has little time to move forward, like you he stopped developing this, even though the latest release is from end of june. Anyway, he might be open for some idea and code exchange.

He also knows former developers of the former foxpro team at Microsoft, so he had a bit of insider info on the legal stuff. Like me Christof was an MVP, even much longer than me, up to the last year Microsoft gave that Award in that competence.

I can't say what's true about the xbase code, it sounds plausible, as Fox Software also reimplemented and extended dBase/Clipper, still I think one reson for Chrstof to stop promoting this and making it a product was the legal stuff, might just be some brands, he sure can tell you more.

You can contact him via the guineu homepage, or via foxpert, but I might personally make contact, if you like. We just met yesterday at our monthly meeting (regional microsoft developer roundtable, former foxpro roundtable).

Bye, Olaf.