OpenEuphoria

Re: more info on ARF020

• Posted by gwalters at sc.rr.com Jul 26, 2001
• 352 views

I agree with you in principle, but my knowledge base at present is far from
that level. I'm in a learning mode at this point. I will say however that
even though windows is event driven and not procedural, an accounting
application is procedural by its very nature. So I beleive a good deal of
effort in windows programming would be to defeat its event nature to
preserve those items in accounting that must be sequential one after the
other.

...george
----- Original Message -----
From: <irvm at ellijay.com>
To: "EUforum" <EUforum at topica.com>
Subject: Re: more info on ARF020


>
>
> On Thursday 26 July 2001 12:11, gwalters at sc.rr.com wrote:
>
> > All the screens are already layed out (approx 70 of them) in another
> > environment and I'm trying to find how this new stuff works so I can
then
> > 'convert' the screens to some type of sequence so they don't have to be
> > constructed one by one...
>
> I expected you to say that.  I've often wished I could
> do something similar. The truth is, it is a 'bad idea'.
>
> One of the common misconceptions is that a procedural program
> can be easily translated into an event-driven windows program,
> and function properly. This is generally not the case. If you try to
> do it anyway, you lose out to those who accept the differences,
> and write programs that *do* use event-driven features to
> their advantage.
>
> People who use Windows (or xWindows, or Mac) programs
> expect, for example, to be able to move on the fly from one task
> to another as needed.  Example:  someone is entering invoices
> into the system. No customer record has been created for the next
> invoice. Windows users expect to be able to pop up a screen, enter the
> new customer data, and then contine where they left off on the
> invoice entry screen, without closing the program or creating an
> error condition. Or, perhaps they need to pop up another customer's
> account to look up some info, without cancelling the work they are
> currently doing.
>
> A second concept that makes translation impractical is that of
> presenting only what information a user needs at the moment.
>
> Take your ARF020 data entry screen, for example.
> It would be much easier to use if the customer name, address,
> etc were presented on the screen, and below that three tab items,
> each tab of which showed a category of items, only a click away.
> Just as an example;
>
> Under Preferences tab:
>   Salesman
>   Tax info
>   Default Shipping info, etc.
>
> Under Terms tab:
>   Cust. group
>   Price level
>   Credit limit
>   Pmt terms, etc
>
> Under Account Status tab:
>   Last invoice date, amt
>   Last pmt date, amt
>   YTD sales, etc....
>
> You can see that, by categorizing the displayed data, and presenting
> only that which the user is concerned with at the moment,  you gain
> in several ways:
>
> 1. Your program is easier to use.
> 2. Your users are less likely to modify something they didn't intend to
> modify, and you don't have to validate entries that aren't accessible.
> 3. You have room on the screen for more informative text, which
> again cuts down on errors, as well as calls for help.
> 4. Your program looks more professional.
>
> BTW, my version would probaby have user-level protection on
> the terms tab, so that only the acctg mgr could change a customer's
> discount, etc.
>
> Now, consider this: It would take about 30 minutes to lay out the
> screen as described above, with tab items, etc. The result would
> be a program with a more professional look and feel, and that will
> outweigh the small amount of time invested in designing the new
> screen.  (It's also likely that the errors introduced in porting the
existing
> screens will take more time to track down than it would take
> to design new screens in the first place;)
>
> Regards,
> Irv
>
>
>
>
>