Andrew MacNeill - AKSEL Solutions

Just about every FoxPro application has a need to store settings. Whether it be the startup folder or various application preferences, they have to be stored somewhere. Of course, that begs the question "where"? Back in the DOS days, many developers stored settings directly in a DBF table. This sometimes created a table with one record and lots of fields which was immediately useless once you had more than 255 settings (many applications continue this tradition today). When Windows started becoming popular, many started to follow the INI approach, creating settings like [application] suppresslogin = true name = george [timezone] This approach is still used and has support in the FoxPro Foundation Classes (and in the Solution Samples). Developers have also embraced the Windows Registry (especially with Win XP). It's very handy because you would easily separate out MACHINE level settings from USER specific settings.  Problem these days is that writing to the Registry is pr...

According to Craig, Sedna Release Appears to be Imminent... This is, of course, great news for FoxPro developers as they have been waiting (im) patiently for it since October when they released SP2. I had noted it on an earlier post and asked around, finding out that Sedna got put behind VS2008 and SQL 2008 in the "release" queue. (Good to see that Craig is providing more details on it, although an updated EULA from Legal certainly isn't something I hoped to see - what new things could they have possibly put into it from June's CTP?) But since then, a few regression bugs were found in SP2. I can appreciate wanting to close the door on new VFP development - but with some of the fairly major bugs that were introduced, I hope that either: a) Sedna includes some fixes for it in the xBase apps (I'm not sure how that would work but if the report Preview engine controls how data is displayed, maybe it could) b) Sedna includes some hot-fix DLLs One can only hope. I am de...

Looks like Craig Bailey got the first link up on this but every FoxPro developer needs to see it here What does it all mean? Well, yes - no more "Microsoft" VFP after Sedna and SP2 - although it is supported through 2015. But perhaps more importantly - all of the Sedna code is being released into Codeplex - so we can all extend it further. This is a very strong point as it means we, as FoxPro developers, can continue to expand on the tool and make it better. There will always be areas that we might gripe and complain (for example, why can't we get a pre-processor at compile time?) - but we can find ways around it. Myself, I would love to see them release more internals to the code under a similar license but I don't think that will happen. However, if you've read the other Craig's blog of late, you'll see that Microsoft is now switching whole-heartedly over to a 64-bit platform , which VFP was never going to support. Whether this is a good move for Micro...