I feel like I've pretty much gotten everything interesting into the WFS that I can get in there. I know there are some new features I could still add (in addition to some of the interesting features I've already got in there for the next release, like FTP support using WinInet). However, I feel like the next release needs a major structural change.
One question I get over and over again, especially from people new to REALbasic, is "how do I use this?" The project has grown so quickly, that the structure gets in the way. This is especially true because the parts are inter-connected in many places. For instance, to get the list of active processes, you need: 1 module, 5 classes and 1 class interface. Then you need to delete all but three methods from that module, otherwise you need an extra handful of classes and interfaces. YUCK!
So, here's my challenge to you guys -- you're all a bunch of smart cookies. What do you think the best way to package the Windows Functionality Suite is so that the project is easy for users (especially ones new to REALbasic) to get at the individual features? How would you want to use this project?
If possible, I'd like to keep it backwards compatible with so that there's no code breakage if someone gets the newer version. But, I'm thinking this isn't possible, and I'm not adverse to breaking code.
Granularize, granularize and granularize.
Make every single item a seperate file, document every single file.
Simple, no?
Documentation is key!
Put an example of each function in a REALSqlDatabase blobfield, add a note explaining that function, add fields to describe the used dll's etc and add this database to the IDE of RB. Generate an index for the functions and for the used dll's and you have IMO the perfect tool to both documentation and usability of the WSF. And think what all is possible if there was a REALSqlServer in respect to using it in groupdevelopment.
However i think for the Mac-user there should be something comparable to this. Maybe Charles can make such a thing?
I forgot to mention that you have an very easy job when it comes to updating this.
@Andre -- I can see how that'd be great for documentation (something which the WFS is sorely lacking), but I'm more interested in getting to the actual features. It's to the point now where you almost need to include the whole WFS just to use any part of it, which I hate.
@Bill -- I agree that docs are key, but it's a different beast than what I'm trying to get at. As for splitting everything into multiple files, it's a good idea, but not certain it's helpful. For instance, the Win32DeclareLibrary module requires so many pieces and parts, I'd still run into the same problem with organization.
Aaron, in the WFS you show an example of (i thought) most of the functions available. What i meant was , tear that example apart into fully working examples for each function a seperate example and put them in that , call it, a snippetdatabase.
Ah! The example stuff is just there for "documentation" and for testing purposes.
The difficulty I'm trying to fix is that a new user knows what they need (say... the ability to get the active process list), and they see a function which does what they want (GetActiveProcessNames), but they have no clue how to get that into their own project (because it requires 1 module containing three methods, 1 interface, and 5 other classes).
So the testing harness I don't really care about (I can document it in other ways, like how you suggest). It's the use-cases that I'm trying to get over.
IMO, you could add a field with the xml from the example that are used in the that function, so a user could import that function. Could that solve your problem?
I don't think a project reorganization is necessary.
Since REALbasic is good about only linking code that is actually used, the only disadvantage in including the entire core WFS library in a project is compiling time. Including the entire library is ideal for a beginner, and if an advanced user wants to extract functions it would be their responsibility.
The other option I mentioned a while back was to write an application which extracts the necessary classes and modules for what task. Just store the raw data as XML components and parse the Classes, Modules and Interfaces for dependances. When the user selects Feature #1, #40 and #59 and clicks export, all of the necessary classes, modules (with only necessary functions) and Interfaces are exported as XML items to the directory they select. It is a lot of work, but it would provide a simple interface that any one can use... and it can double-up as a documentation viewer. You might even be able to contribute to and extend Thomas Tempelmann's prjtool for this task.
Until then, recommend that users just import the entire library.
@Phil -- that's an interesting idea. I wonder if I could supply it as a project template, and then create a mini-installer for it? Hmm...
@Andre -- I think what you're getting at is something similar to what Phil was talking about with an export/import feature. But I'm actually digging on the idea of a template installer.
I think that's a good idea and it's the most obvious way to implement it. I always have trouble to see the obvious, i think i need a reprogramming.
I thought the compiler ignored code that wasn't called. If that's the case, why not leave all WFS code in the project?
I think that it still gets compiled, it just doesn't get linked into the built app (not part of the EXE). There have been a fair number of users (not me though) that have complained about the compile speeds, and including the entire WFS library would be a disadvantage for those users.
Perhaps it would be a good time to consider that old feature request for a "Library" folder. It would act like a plugins folder, but native REALbasic modules and objects would be dropped in and then be available to all projects. Then the user could simply be instructed to drop in the WFS classes and forget about having to manually drag them in in the future; they'd simply be always available.
The ID for the request is pvpxvtft or htwrirpz.