Clarion Live presentations

Clarion Live format today seeing all the host presenters was great fun!!

many thanks to the team at clarion live for the entertaining introduction, graphic , music and presentations.



Latest clarion live…

BRUCE was discussing queue based or temp files for business apps and thinking was the Invoice numbers ect did not need to be shown.

Think Bruce is right on this approach…

we are starting to store business information in queues and storing in XML and registering them as documents.

And Bruce was suggesting pointing to the queue…

well Bruce has his pipe class for queue’s and if you declare your queue fields mapping to ANY fields then your invoices or journal transactions or posting engine can POINT for an instance of your data

your problem is that you have no record locking and data has to be posted or batched.

You need perhaps a file for what documents are being edited or processed.

IP driver come in handy then for designing a distributed system of documents…

And clarion 11 has function pointers to class methods which allows for the complete abstraction of your transaction and posting engine… big job of course… and then your have a base class for no GUI and then an inherited class for your GUI.

that can then attach anyscreen.

(post deleted by author)

and in the end the presenters started talking about documents …

gosh and documents and app event management is where we find ourselves…

those new GUI features for clarion might hopefully allow for more dynamic application for creating new class of applets…

the presenters are heading there you can see it…

Tax Accounting systems and bank systems in this part of the world are ancient and bank statements dont even come with ID numbers… ANZAC banking system is …

Stock market reports cant be software audited and balanced…

AUSSI NZ banking and business systems are …

Deleted…messaged removed.

(post deleted by author)

In the ANZAC banking system transactions arnt numbered or identified in anyway for third party or client processing.

The same for transaction processing on ANZAC stock markets making auditable transaction processing in New Zealand and Australia basically impossible.

Well, naturally :wink:

It’s worth understanding the constraints and goals of the app;

A) it’s a “out the box” clarion example. So we’re only using what’s in the Clarion box. (That’s an interesting exercise for those of us who typically work with “a bigger box”.)

B) the issue was around the approach to a parent-child form; in this case the tradional invoice/line-item form.

C) of course this can be coded with a browse control on a form, using auto-number. It’s certainly trivial to do, and “good enough” in most programs most of the time. But that approach has a number of issues, and this is an example, so we wanted to try and show it done in a better way.

D) “better” is not perfect. There are still refinements that could be added, but there’s both a point of diminishing returns, and an introduction of complexity that starts making the example not-useful.

So yes, a generic parent/child form template or class would be useful (Indeed, SuperInvoice exists to do this) that is outside the scope of this example.

Also, since we’re not using auto-numbering we avoid many of the issues that introduces.

I agree though that whether to use a transaction or not will be an interesting discussion next time. There are cases to be made both ways.

I am enjoying this process though. I think it will make an interesting tutorial to go with the finished example, and will underline the thought that goes into programming. Also it shows (as happened last night) that you can start with one approach, but be wrong, and need to throw it away and do it a different way. Throwing work away is painful, but a necessary part of the development process.

1 Like

And many thanks to the team of presenters for giving their valuable time for us all to enjoy… looking forward to the next episode.

1 Like