Re: Checking in on the project

Cool!  How about just a startup option that prompts you do a quick 
component import so that you have all the controls initially on the 
screen and then you could move them from that point.  Basically, that is 
what I was thinking of.

But your approach is sound.  It would just be helpful to know, in my 
opinion, what the original screen looks like.  An alternative would be a 
drag and drop option where you pull fields from a green screen and drop 
them into your design pallet.

It all sounds very cool though.  Keep me posted and, if you need some 
help, I'll try to pitch in.

Pete


[email protected] wrote:

>
> We were actually thinking along the lines of starting at the gui side. 
> You draw a GUI for a screen and tell the components on the panel at 
> which x,y locations on the 5250 they can find their info. The driver 
> component of the GUI listens on the stream and triggers the gui panels 
> when he finds the right screen info on the stream.
>
> HTH,
> Wim
>
>
>
> *Pete Helgren <[email protected]>*
> Sent by: [email protected]
>
> 14/10/2005 19:18
> Please respond to
> [email protected]
>
>
> 	
> To
> 	[email protected]
> cc
> 	
> Subject
> 	Re: [Tn5250j-general] Checking in on the project
>
>
>
> 	
>
>
>
>
>
> Well, not exactly sure how to describe it (although I have it in my 
> head clearly...) And, I'll be the first to admit that I am not fully 
> familiar with the architecture of tn5250j.
>
> I am assuming you read a stream and figure out how to translate the 
> fields and values into GUI components.  Those components have a given 
> ordinal relationship on the screen (X,Y locations) and then you place 
> the GUI components in place of the text ones.  A VERY simple example:
>
> Let's say you have screen that has two fields, a static text field and 
> a "text box", like so:
>
> This is the text:
> this is the data
>
>
>
> So lets say the static text starts at 1,1 and the text box starts at 
> 2,1. Although you are reading a stream, it eventually maps the entire 
> screen to X,Y coordinates and that is how it displays on the screen. 
>  You could "save" these ordinal relationships to a file (kind of like 
> SDA does) and then, through a GUI, allow the "designer" to move them 
> to where they want them to go so, as in the above example, although 
> the stream "says": Put static text field (STF1) in position 1,1 and 
> put text box field 1 (TBF1) in positions 2,1, you could use the 
> "saved" re-mapping file to tell the application to actually "paint" 
> the controls to position 5,20 and 7,1 like so
>
>
>
>
>                    This is the text:
>
> this is the data
>
>
>
>
> So all the "mapping" file would do is to save the original field 
> positions and map them to new places on the screen. A GUI tool that 
> captured the original positions and allowed the "designer" to move 
> them to new positions would be needed to create and save the map file, 
> and a map in memory of the original screen before it is mapped would 
> probably be needed in order to send the data , updated with the 
> changed data values, back to the iSeries in the correct sequence. But 
> this is the general idea.
>
> I think the Seagull screenscraper does something like this although I 
> have no experience with that product and don't know the underlying 
> technology at all.  Maybe WebFacing is similar.  But, conceptually, 
> that is what I have in my head.
>
> Pete
>
> _
> [email protected]_ <mailto:[email protected]> wrote:
>
> What exactly do you mean with the map file?
>
>
>
> *Pete Helgren **_<[email protected]>_* <mailto:[email protected]>
> Sent by: [email protected]_ 
> <mailto:[email protected]>
>
> 14/10/2005 16:48
> Please respond to_
> [email protected]_ 
> <mailto:[email protected]>
>
> 	
> To
> 	[email protected]_ 
> <mailto:[email protected]>
> cc
> 	
> Subject
> 	Re: [Tn5250j-general] Checking in on the project
>
>
>
>
> 	
>
>
>
>
>
>
> Thanks Wim.
>
> This sounds "exactly" like what I had in mind a couple of years ago. 
>  Seems to me that the "mapping" concept would be fairly 
> straight-forward (probably a lot harder to do than it sounded...) This 
> is very cool and Swing would be a good fit.  
>
> Have you looked at Java Server Faces at all?  I saw a demo of a JSF 
> app that looked very "Swing-like" but was all HTML and mostly a server 
> side implementation.  I have been meaning to take a look at it in more 
> detail and see how difficult the coding is.  The JSP/Struts/Tiles 
> approach has always been too complex to me and JSF *seemed* to 
> simplify that.  I need to take a look at it soon but it might give you 
> a richer-looking UI without the client side hassles of Swing.  Mapping 
> to JSF components might be a possibility.  I'll look into it when I 
> have a chance to see what you are doing.
>
> One other idea I had in the "screen scraping" area was a "static" 
> mapping option that would allow you to actually change the component 
> layout at the client end.  Rather than doing the transformation on the 
> fly, you could create "map file" and use that instead.  Not sure how 
> to implement that though.
>
> Thanks for the information on the code pages and the good news on the 
> code page support in JT400.  That should take care of it!
>
> Look forward to hearing more about the screen scraper....
>
> Pete Helgren
>
> _
>
> [email protected]_ <mailto:[email protected]> wrote:
>
> Hello Pete,
>
> great to hear some acitivity from this corner.
>
> The screenscraper works for one of our customers and is tailored to 
> their screen layouts. Still have to do some bugfixes for them shortly, 
> so I can send some screenshots on the list to give an idea to what it 
> looks like. We were now discussing internally whether we were going to 
> apply the scraper to our own screens, or build some kind of Swing gui 
> components on top of the stream: a table for a subfile, a label for 
> static text, a textfield for fields etc. The idea is to be able to 
> build swing panels that read and write their data from the screen. The 
> buttons and menu's would call function keys etc to do screen 
> transitions and move to the next swing panel. What do you think? For 
> us it is just to be able to quickly roll out GUIs until we find the 
> time to reengineer the apps in full GUI apps.
>
> The 1200 codepage is provided in JT400. However I can not find the 
> 1208. I wonder however if those are supported if they're not in de 
> toolbox. Or are the numbers provider here not the AS/400 numberings?
>
> Regards,
> wim
>
>
> *Pete Helgren **_<[email protected]>_* <mailto:[email protected]>
> Sent by: [email protected]_ 
> <mailto:[email protected]>
>
> 14/10/2005 15:41
> Please respond to_
> [email protected]_ 
> <mailto:[email protected]>
>
>
> 	
> To
> 	TN5250J List _<[email protected]>_ 
> <mailto:[email protected]>
> cc
> 	
> Subject
> 	[Tn5250j-general] Checking in on the project
>
>
>
>
>
> 	
>
>
>
>
>
>
>
> Gee....been kinda quiet around here.  Must mean we are all gainfully
> employed and busy?
>
> A couple of questions (just to blow the dust of the list!):
>
> 1. Wim, a while back you talked about a screenscraper project you were
> involved in that used tn5250j components.  Where are you on that?  I'd
> love to know what you are doing in that area since I think tn5250j has
> some powerful tools in that would be useful.
>
> 2. Also, in general, how hard is it to add code page support,
> specifically for 1200 and 1208?  There was a post in midrange.com from
> someone looking for an emulator that supported those code pages.  I
> didn't see it in the list of supported code pages (not in JT400
> either).  I'd like to help this guy out if I could, I just don't know
> how difficult it is to support other code pages.
>
> Thanks!
>
> Pete Helgren
>
> P.S. Kenneth are you out there ?  How is it going?
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. _http://solutions.newsforge.com/ibmarch.tmpl_
> _______________________________________________
> Tn5250j-general mailing list_
> [email protected]_ 
> <mailto:[email protected]>_
> __https://lists.sourceforge.net/lists/listinfo/tn5250j-general_
>