Re: DSPF with SRCFILE(*NONE) Re: external *PRTF (was: RE: 'ILE RPG' or 'RPG IV' . What's the difference!!!)

> Anton,
>
> I don't understand everything you're saying here, so if I get it wrong,
> please be gentle, okay? <grin>
Of course, was i too harsh? I try to be a friendly austrian, but i think
that i'm not always successful with it..<g> It's a pleasure to me and i'm
sorry for being not clear enough. (Better? Let's see, how long i can make
it! :-)


> Certainly if someone actually used this approach, that would be the case.
> I'm not advocating this as something anyone should ever do, I'm just
> pointing out that program-described display files ARE possible, so that
> argument against comparing print files to display files is not as strong
as
> it might seem.
OK, nice to know that, but i think it's of no practical use. That's what i
wanted to express and proove it the historical way... As i've learned here,
but not yet tested myself, the dynamic screen APIs seem to be the solution
for the problem that every SW-selling shop has/had that i know: differences
in article number length's and so on. To have them referenced to a ref file
is nice, but that means in fact that one has to hold a copy of all programs
for each customer's database (and database means in this case more than just
one file :-). Being able to determine the length of screen fields at run
time according to field lengths in the database would have been a feature
that i loved when i was working for another company some years ago. (and i
mean screen fields with the correct length, not just the field end hex
attribute in a standard-length-input field)


> - - -
> > And - what about input fields in *your* example?
>
> As written, the whole screen is effectively a big I/O field.  Anything you
> type into it goes back to the program.  You'd have to set the right hex
> attributes at the right locations to protect constant text and allow entry
> where appropriate.  It's doable but tedious and error-prone, I would say.
But users can write over screen atributes, can't they? If the answer is yes,
this is unusable.


> > - - -
> > Didn't anybody on this world - nowadays i can ask the "whole"
> > world (at
> > last!) - program a tool, that outputs real 5250 data stream, like i
> > sometimes suggest(ed) the UPDDTA to work, as performance for
> > creating the
> > display formats was quite good even at earlier releases *and*
> > the screens do
> > behave slightly different from the ones created by a "stored"
> > DFU "program".
>
> Could you please type that a little slower <g>, I don't quite know what
> you're asking here?
I once examined the 5250 data stream in order to write a standard
interactive transaction program that would offer fields according to some
settings in file(s), user spaces, user index or something like that(didn't
get that far). I stopped the thing when i realized how many time i had to
spend for that. Time that i didn't had. I don't know whether there were the
dynamic screen api's already, i do not even know whether they do now exactly
what i want(ed).


Still something unclear?
Still speaking in riddles?

Best regards,

Anton Gombkötö


+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---