RADBlog

1. My web site has moved to a new domain.  I'll be adding some new stuff to it soon.
2. Existing client work and contracting still going on (with the managing that entails).
3. List & Label work continues.  Been in talks with Combit and it will appear the pricing will be similar as in the past.  This will be part of #1 above.  But this ABC compliant version will not be the first offering.  That will come later.
4. Other former Solace products will soon be available, for the moment with minor improvements and changes.
5. A new line of commercial software is about to make its debut.

The above takes attention and effort and budgeting of time is important.  More later.

1. Remove redundant code from the templates.  A lot of template code is now gone.  When you make ABC compliant templates, a lot of the code in past versions is rendered obsolete since ABC takes care of many issues (like when to export a class, thus you will not find any template code for this purpose).  In addition to this, many settings are gone as well as the template code to support it.  For example, the checkbox to indicate if this is a DLL or not.  ABC is smart enough to spot when you use DLLs, so you don't need to indicate it twice!
2. Consolidate code.  There are far too many routines, and worse, these are generated by the templates.  It clutters up your code.  These routines, where still needed are now in class code as methods. In addition to this, some of these methods cannot be named at design time, so they don't exist.  For example, when you wish to send a file to List and Label, it makes sense to name the method SendCustomerToLL.  Obviously, a class designer cannot possibly know a name of a method in such a context.  However, the templates do.  They now generate new method names based on the file(s) you wish List and Label to know about.  As well as the method code.  The only work you need to do is indicate which file(s) you want.  By default, the entire record layout is sent, you can override and exclude certain fields (like Salary, password, login ID, etc).  I think this is far easier if you spent your time and effort making exceptions (if any) to the defaults.
3. List & Label classes properly show up in the embed tree.  This is for overriding public methods as you see fit, just like other embeds.  They have a DATA and CODE section (with PARENT call), properly colored too.  Part of the ABC standard.
4. Ensure each template in the set generates proper working code.  This means out of the box as well as developer changes and overrides.  This is the part taking most of my time as each template does certain functions.  Included in this is the removal of the old RepLay files.  This added complexity to your projects, something a few emails complained about and I agree.  This means the removal of the two files from your dictionary (no longer needed nor required).  This means that you don't have to import TXAs into your application either.  It means removal of template code that supported this.  I've still more work to do on this part, but so far, so good.
5. Each template in the set generates compilable and working code.  This milestone will take some time as well since each template has redundant (and sloppy) code in it.  As well as the new features requested.
6. Release a limited beta.  I hope I can do this by the end of Feburary.  This is a big part of the modernization project.  I see this in separate phases, first the tests will be limited to Clarion 6 and ABC applications.  In this phase, only test projects should be used.  No 3rd party add-ons.  Version 13 should also work, but lets see what the testers say about that.  The next phase would be existing L&L applications.  Since this is a new set of templates, some confusion is expected here since you will see two distinct and different List and Label templates in your registry.  How does this affect existing List and Label developers?  I'm taking notes about this.  I'm sure conversion (or porting?) to the new templates will stir up some issues.  My job is to make this as smooth as possible.
7. After any and all issues are addressed during the beta, the first release!  If all goes well (and when does that ever happen?), I see a March release date.

Some have asked questions about the cost.  Yes, there will be a cost, but I PROMISE it won't break the bank!  This is mainly because I've yet to see any revenue from this project (my revenue derives from current clients) and yet I am gladly giving support to the old product and won't take fees for this.  The upgrade and exactly how much and how to order is the subject of a future blog.  I've got a plan for this that I think will be fair to all parties (and easy!).

So that is it in a rather large nutshell.  I hope this gives you a rough timeline as to when and what remains to be done.  I'm pretty sure you will like the new templates and the flatter interface so finding settings is easier.  They are certainly easier on the eyes.  My goal is to make List and Label appear like its a part of your application, ready to design and run saved reports with almost zero changes required of the developer.  That is a common request by existing L&L developers as well as those who tried to use it in the past and got confused and dumped it.

Existing developer's concentration is on embedding List and Label in their apps; new List and Label developers don't need to worry about how to do this, but instead concentrate on using List and Label to design and run their reports.

1. There are too many routines that make following the code difficult.  I agree.  These routines are now moved to private methods, the templates will generate the code in context for them.  That is, List  & Label needs to know about which files?  This also means the template interface needs some adjustments so its near automatic as to which files are needed.  Easy enough to do with the table schematic.  If a developers wants to change this, usually by witholding a file from L&L, then minimal effort is needed there.
2. Manual variables should be easy to define and use.  Why not use local data for that?  Global?
3. Why is there a need for importing procedures into your apps and declaring files not in your dictionary?  There should not be.
4. And why must one use an extra file to define which report goes where?  This is the LLRepLay file to be precise.  To be honest, I don't see why this is needed.  Seems to me the classes and templates should be clever enough to make some assumptions in context of the procedure you use it.  They are default values and the developer is free to change them as they see fit.  Also, all data once saved in L&L is available to L&L.  Unless you make a change, then its merely re-sent.

These conceptual ideas forced me to change my approach.  Yes, that is going to add some time, but not much.  I got this data early enough to do something about it.  Its a bit of a pain for me, but that is so you don't have some later.

The end result I'm after is with minimal action on the part of a Clarion developer connects your application to List & Label so it looks like your product all along.  Regardless of L&L standard (embed designed reports) or professional (the report designer is also part of your application) versions.  I'm thinking a few minutes of installing and you now have the best report tool out there fully function inside your application as if it belongs there.

I'm impressed with the feedback and suggestions.  Please keep them coming!