|
the same way as they are used to workingthat you didn't use OA since the objective as stated is to make it work
details.Not yet ...Are you going to be marketing/distributing this new tool?
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
in
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
the ADDRESSX table, Message-Id for Description, return all custnosADD
that are
= the entered CustNoWx_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
and a context menu with the options Change, Copy, Delete and Displaya
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
specific edit option (shows icons for the country) is usedhttp://archive.midrange.com/midrange-l.
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 forprograms).
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
German, French etc.
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,
wrote:
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>
forever.I agree that it would be better - as would many, many other options.I'm stuck with printer files and nothing else.
But
applications and had some thoughts on how best to handle printer files.
I was hoping that more people here had had experience in globalizing
their
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
be to take the approach that Booth did and load the fields in theI was rather afraid of that Birgitta, the only other option then
seems to
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:
particularly since green screen are dying - but printer could go onI can't believe that printer support is so poor compared with
displays -
screens).
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
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
--
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.
--
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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
