AW: Question for Printer Gurus

Are you going to be marketing/distributing this new tool?

Not yet ...
Next week we will start rolling it out.
Even though the software package is multilingual we'll start first in
German.
Only because the documentation around 350, pages, screen shots, message
files are not yet correctly translated or reworked.

This morning my manager showed me, it is now on our website (only in
German), but there are several screen shots (but only for list programs /
detail programs are also possible).
http://www.toolmaker.de/produkte/wopixx/

You may run the texts though babble fish or something else for translation
or just contact me directly. I certainly can give you more details.

The RPG Programmer does neither have to care about any HTML, JavaScipt etc
code nor about statelessness of Web programs. This is all handled by our
tool.
The RPG programmer only calls WOPiXX Procedures and writes his programs in
almost the same way as before.
For example in detail programs: Chain/Read data as before, define
input/output fields - instead of populating fields in a display file, call
Wx_GetChgInput() instead of EXFMT, check the entered data (that is returned
into your variables) with your own procedures/source code. If an error
occurs call Wx_FldErr() instead of moving on an indicator or sending the
message to an error subfile. If everything is okay, just do your
updates/inserts/deletes as before. At the end call procedure Wx_WrtChgTbl()
which manages the next screen to be displayed (i.e. same screen if an error
occurred, previous screen if everything was OK).

List programs are even much easier.

The following source code is the complete source code for an address master
list program with 3 filter fields, 6 columns, the ADD-button and a context
menu with the Change, Copy, Delete and display options.
For the appropriate SAA-standard subfile I needed around 500 statements
(without comments)

* H-Specs (including binding directories and activation groups)
H/Include QCPYLESRC,WX_HSPECS
* Prototypes for all WOPiXX-Procedures
D/INCLUDE QPROLESRC,WX_PROTO
************************************************************************
/Free
*INLR = *On;

//1. Open HTML document, define the title through a Message Id and
define the detail program
Wx_OpnHTMLWrk('TIT0001': 'TRCHGADDR');

//2. Define filter fields
// 2.1. Define physical Files/Tables/Views to be used

Wx_FltFile('ADDRESSX');

// 2.2. Define Filter Fields
Wx_FltFld('CustNo': 'DSP0001': '>='); //Column CUSTNO in
the ADDRESSX table, Message-Id for Description, return all custnos that are

= the entered CustNo

Wx_FltFld('City': 'DSP0002': '=': 'SelectList'); //Column
CITY, Message-Id, compare with =, build a combobox conctaining all cities
within the ADDRESSX table
Wx_FltFld('CustName1': 'DSP0003': 'LIKE'); //Column
CUSTNAME1, Message Id, return all rows that contain the entered text
somewhere in the CUSTNAME1

//3. Context Menu/Buttons
// If neither a button nor an context menu item is defined, button ADD
and a context menu with the options Change, Copy, Delete and Display is
automatically included

//4. Define the List
// 4.1. Define a unique key column (Relative record no in this case)

Wx_WrkKeyRRN('ADDRESSX');

// 4.2. Columns to be displayed
Wx_WrkFld('CustNo': 'DSP0001'); //Column CUSTNO,
Message-Id for the column header
Wx_WrkFld('CustName1': 'DSP0003');
Wx_WrkFld('Country': 'DSP0007': 'CTL(Country)'); //For Country a
specific edit option (shows icons for the country) is used
Wx_WrkFld('ZipCode': 'DSP0006');
Wx_WrkFld('City': 'DSP0002');
Wx_WrkFld('Street': 'DSP0004');

// 4.3. Default Order (optional)
Wx_WrkDftOrder('CustNo');

//5. Write the HTML document / send it to the browser

Wx_WrtWrkTbl();

Return;
/End-Free
****************************************************************************
*******************************************

BTW the best thing about the development tool is (at least for the
programmer and users of WOPiXX) it is free!
Runtime is also free.
... but hotline, support, education etc must be paid.

Mit freundlichen Grüßen / Best regards

Birgitta Hauser

"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"

-----Ursprüngliche Nachricht-----
Von: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] Im Auftrag von Jon
Paris
Gesendet: Friday, 05.9 2014 15:40
An: Midrange Systems Technical Discussion
Betreff: Re: Question for Printer Gurus

Thanks Birgitta - that is exactly what is happening with the web and green
screen aspects of the app - it is just the printer side that is causing
grief.

Are you going to be marketing/distributing this new tool?


On 2014-09-04, at 1:23 AM, Birgitta Hauser <Hauser@xxxxxxxxxxxxxxx> wrote:

Multi-lingual applications are always a problem (may be less for
native English speakers and companies) but for the rest of the world :).
In my experience there is only a single tool, that retrieves the
message texts at runtime on the fly from message files and that are
good old green screen display files.
Printer files always accepted MSGCON, but retrieved the message texts
at compile time. It was/is always a pain, if a message text needs to
be corrected, i.e. the appropriated printer file(s) need to be recreated.
Everything else, in HTML, XML or whatever, the message text in the
appropriate language must be determined at run time from either a
message file or a database file (or is even worse hard coded within the

programs).

We just developed a tool that allows RPG programmers to write web
applications without knowing anything about HTML and JavaScript.
Multilingualism was a big issue, and we had to solve it by determining
the message texts at runtime from the appropriate (overridden) message
files depending on the language.
... the programmer does not need to care about the different
languages, he only specifies the message ids and depending on the user
and the associated language the HTML is prepared and displayed in English,

German, French etc.

Mit freundlichen Grüßen / Best regards

Birgitta Hauser

"Shoot for the moon, even if you miss, you'll land among the stars."
(Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training
them and keeping them!"

-----Ursprüngliche Nachricht-----
Von: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] Im Auftrag
von John Yeung
Gesendet: Thursday, 04.9 2014 04:33
An: Midrange Systems Technical Discussion
Betreff: Re: Question for Printer Gurus

On Wed, Sep 3, 2014 at 4:32 PM, Jon Paris <jon.paris@xxxxxxxxxxxxxx>

wrote:

I agree that it would be better - as would many, many other options.
But

I'm stuck with printer files and nothing else.

I was hoping that more people here had had experience in globalizing
their

applications and had some thoughts on how best to handle printer files.

I think what people *with* experience are saying is that the best way
to handle printer files is to do away with them. Birgitta gave a
concrete strategy for using printer files, to which you said

I was rather afraid of that Birgitta, the only other option then
seems to

be to take the approach that Booth did and load the fields in the
logic, but that's not a good solution either.

The best available solution isn't always a good solution. In your
position, it seems like "something that works" is better than anything
that doesn't work.

Also, I disagree strongly with this:

I can't believe that printer support is so poor compared with
displays -

particularly since green screen are dying - but printer could go on

forever.

I mean, I agree with the part about printer support being poor
compared with display support. I disagree that green screens are
dying any faster than printer output. Where I work, print is pretty
much dead. There is definitely no new development in print output,
yet there's still a continual stream of green screen development.
Even where we *need* printed output for whatever reason, there are
replacement options for printer files (DocPath, ACOM, and the like).
With the group of developers we have, it's been easier to learn other
forms of output than other forms of interactive user interface. There
has actually also been more demand from our users for electronic
output (usually
Excel) than demand for a different UI (especially from our
long-in-the-tooth users who have gotten freakishly proficient with green

screens).

Finally, regardless of how easy or hard it is to learn other UI
technologies and paradigms, in large existing systems, it's easier to
replace printer files one by one in organic fashion than it is to
replace a display file here and a display file there.

John Y.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at
http://archive.midrange.com/midrange-l.

Jon Paris

www.partner400.com
www.SystemiDeveloper.com




--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.