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

Anton,

Much clearer, thank you!  The "gentle" thing was a joke, intended to keep
the tone of the discussion light, since I find discussions with a light tone
to be much more productive (and enjoyable) for all involved than those with
lots of solemnity.

I agree that writing interactive applications using display files without
source is not practical.  Just in case anyone is still unclear on it, my
point was that the argument that internally-defined print files are not
analogous to internally-defined display files because the latter are
impossible is weak, since they actually are possible, even without any
display file source.  In essence, I was trying to get Dan to make the
confession that he ultimately made: that his preference for
internally-defined print files is a tool issue, not a functional issue.
Since that is my own belief as well, I considered it a test of my powers of
persuasion - and for once I actually passed. <g>

As for the DSM API's, I haven't had a good use for them yet, so I haven't
worked with them.  Having played with, and gotten frustrated by,
user-defined data streams at one time, I am glad to hear that they really
are Good Things (TM).

Dave Shaw
Spartan International, Inc.
Spartanburg, SC

> -----Original Message-----
> From: Anton Gombkötö [mailto:Gombkoetoe@ASsoft.com]
> 
> > 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
+---