nxSoftware Blog

In need of a short break from Arctic Reports (what can I say, too much concentrated effort on one project is not always a good thing I reckon! ) I have returned to an old 'hobby' project of mine, something which I have rewritten twice and, basically, abandoned twice because of time constraints and, frankly, complexity.

What has always started out (on paper at least) as a simple form designer has, on all previous occasions, ballooned into something far far more complex than I ever imagined. So much so that I have always, reluctantly, been forced to abandon the work with the promise that 'I'll be back!'. A promise I have not broken!

And so, it is third time lucky now with my KwikForm designer (or at least that is the hope!)

And let me say, that I've nailed the bugger this time! If this doesn't turn out to be the simplest to use form designer ever then I will eat my cotton picking shorts! I may have to wash them down with a few pints of Guinness of course!

So why a form designer exactly?

It is just something which has interested me for quite some time now, but with so many such tools around, this is always consigned to being little more than a hobby project really. Not something which will ever see me buy that luxury yacht I keep promising myself, or something which will enable me to bankroll some Premiership football club,... but fun nevertheless. Crap, this is one of the most enjoyable things I think I have ever worked on!

So what makes KwikForm so easy to use?

Well, for one thing, it does not present the user with a hundred and one disjointed windows to sift through everytime you wish to perform some action or other. Run KwikForm and all you get is your form - nothing else. No clutter, no mess and no messing! KwikForm itself does not present any kind of GUI with menu options or toolbars etc. It doesn't get much simpler than that - no sir! Right click your form, select to add a button control (for example), click the button and then drag it to it's allotted position and your form will be well on its way with a minimum of fuss and delay. Right click the button, select properties, select a property to edit... voila! Right click a previously added container gadget (for example), select 'Child Controls...' and the next submenu displays a list of all controls added to the container. Select one and... you get the idea!

There is also the fact that, unlike many other designers, KwikForm does not save its forms in some internal format and then require an additional menu option to 'generate Purebasic source'. Instead, forms are saved as Purebasic source code files in a similar way that the VB form designer operates. KwikForm generated source files contain a section which you should not edit. Add additional code outside of this section as you see fit. Load the source into KwikForm, visually edit your form and then re-save etc. What we are left with then is a source file which can be loaded into both KwikForm (to visually edit the underlying form) and into the Purebasic IDE to add additional code etc. Compile the code and you have immediate access to your visually generated form as well as your additional routines. To my mind, this is the way that designers 'should work'. Of course it would be even better if KwikForm could parse Purebasic code directly, but that is pushing things a bit for a 'simple designer'.

An interesting question, from my point of view, is whether the Pyrex visual report designer or the KiwkForm form designer is the more complex program to work on? Difficult to compare really, though of course I do make comparisons as the work progresses. They operate completely differently. Pyrex constructs the design canvas directly through GDI, physically drawing the report components directly onto the canvas etc. KwikForm, on the other hand, like many designers, uses proper controls. You add a button to your form at design time, then a proper 'live' button control is what you get! This is what I regard to be the easiest way of approaching a form designer (and is one used by many designers) although it does throw up a lot of rendering problems which do not exist if rendering controls 'off-screen' first and then using GDI to render these images. For example, place one button control on top of another (even if a temporary arrangement) and all hell can break loose! KwiKForm addresses these problems and at present the only control which still misbehaves in this regard is the cursed panel gadget. But then, I notice that this is the same for all other designers I can lay my hands on which also use 'live controls' at design time. I think this is something we are just going to have to put up with where panel gadgets are concerned. Still, how often do we overlap gadgets anyhow?

Right, back to work for me then.

Currently working on Pyrex 1.4 which will be a major update in that it will offer copy/cut/paste of controls aswell as undo/redo facilities (and not before time perhaps! )

I say will offer, but this does come with a somewhat tentative proviso where the undo/redo facility is concerned ... Users may have to wait until version 1.5 for this if it proves to be too problematic. Sure a lot of the code is already in place for ths undo/redo facility, but this still represents a major undertaking anyhow.

Whilst I am re-acquianting myself with the Pyrex code (32000 lines of Purebasic source without the nxReport core module), certain obstacles do present themselves to achieving a full undo facility. For example, if a user deletes an entire subreport together with all companion controls, how best do we undo that little operation? How do we reinstate the subreport (and all of it's properties and those of other subreport's which depend on this one) together with the possibly hundreds of companion controls together with the dozens of properties for each control together with their places within the object tree... A thorny problem indeed!

My initial thoughts are to make the deletion (and therefore the addition) of subreports an action which cannot be undone. I guess I have to draw the line somewhere. Deleting multiple controls will certainly be undoable, but entire subreports...... Perhaps I shall indeed exclude deleting subreports from the undo/redo facility and think about adding this at a later date should there be a demand for it? It sounds like a plan to me!

Copy and paste of controls (not subreports) presents a different challenge, one that would seem to be relatively straight forward. Again this must be undoable and so I need to code this in such a way that it fits in to the existing undo/redo framework (as it exists at the moment). It occurs to me that the information required to be stored on the clipboard is identical to that required to be stored in an undo stack when a control is deleted anyhow and so there is a nice link between the two areas of focus of this next update.

Internally, Pyrex operates like a scripting engine in that 'commands' are despatched to a central 'hub' for processing. For example, when the user moves a control then a suitable command is sent to the central hub informing it that the underlying control should be moved etc. An undo/redo facility simply needs to place these commands within a stack and despatch these commands when appropriate. Something similar is true for copy/paste. When a control is to be copied, a suitable bunch of these 'script commands' are to be tied together and written to the clipboard. A paste operation then simply retrieves this bunch of commands, modifies them as appropriate (e.g. the command for setting a control's ID will need to be altered to give the new control a unique ID) and then sends them to the central hub.

Perhaps not the fastest way of implementing copy/paste and undo/redo, but certainly amongst the most convenient!

Well, ExGRID is complete (and with a fully detailed user manual!)

This took somewhat longer than I had originally intended (especially the manual!) Though, in all fairness, ExGRID does come with more features than I had originally intended for it, quite a lot more in fact. And the OOP programming api does make the whole business of creating complex grids a lot simpler.

Of course, with the new fixed column of row header cells and all, ExGRID (like the original EsGRID control upon which ExGRID is based) is still based upon a Windows ListView control and so of course is subject to the same limitations where they exist. Still, I am quite proud of ExGRID and look forward to using this control myself in a future application or two.

The question does arise now, though, of whether I shall create a new custom grid control at some point? One based, not upon a Windows ListView control, but one built entirely from scratch? This has been asked a few times now and I have to say that I certainly will be creating a completely new grid control at some point in the future, one that will not have quite the power of EsGRID/ExGRID, but one that will occupy a nice little niche anyhow. A grid built from scratch will not have any limits (aside from physical memory etc.) in terms of the number of columns which can be added in that performance will not be hit in quite the same way as a typical ListView control.

So yes a new grid is on the 'to do' mountain, one that will not replace ExGRID, but one whose underlying simplicity should give it the edge in more data-intensive applications. And with all the lessons learned in creating a grid control based upon a Window's ListView, let me tell you all right now that a grid built from scratch will be a damn sight easier to code!

But this 'new grid' control is for another day.

Welcome to the nxSoftware blog.

Here I will post some occasional thoughts regarding my software development and the various projects with which I am involved. Perhaps a few progress reports as well along the way, when appropriate.