Re: CREATE WINDOW structured field (fwd)

James

On Jul 14, 2004, at 7:47 PM, James Rich wrote:

> On Wed, 14 Jul 2004, Kenneth J. Pouncey wrote:
>
>> Do a trace of the save screen command before receiving a window.  If
>> you look at a DSPF you have to specify save screen in there.  I have
>> never written a DSPF with windows that does not.  So I would say that
>> it is always.
>
> My traces do seem to be always, as well.
>
>> Can not remember as it has a been a while but I paint scrollbars as
>> well.  It is the single choice buttons that are killing me.  Have the
>> structures being parsed but can not for the life of me figure out how
>> it all works.  I would actually have to see the send query command 
>> that
>> you send back to know for sure.
>
> I probably need to come up with some screens that have these elements 
> in
> them.  I don't even know how to scrollbars or buttons in DDS.  I'm 
> trying
> to make a comprehensive test package.  Someone needs to educate me 
> about
> these elements.

I can send tests of these.  I did not know how to code them myself 
until they came up because I like to keep things simple.  We may be 
able to work together here to solve some of the issues I have been 
having.

>
>>>> There is a place in the document that explains how to compress the
>>>> screen data but that did not work either, still too much data.  So
>>>> what
>>>
>>> I wonder if this is because (if you are speaking of creating a second
>>> window) it is only expecting the contents of the window, and not the
>>> whole
>>> screen (or structure)?
>>
>> I never saw any difference here.  A screen to me is anything that 
>> makes
>> up a screen including the gui parts.  If what you are saying is true
>> how do you keep track of the window structure and the data within it 
>> to
>> redisplay it afterwards?  Now that would be interesting.  What are 
>> your
>> thoughts on how to deal with this?  It would be a change of thought 
>> for
>> me so would have to think about it and get back into the sequences of
>> what is sent in the datastreams but could be possible.
>
> My latest patch to tn5250 is here:
>
> http://www.chowhouse.com/~james/x5250/enhanced.patch
>
> What I'm trying to do is save the window structure in a struct like 
> this:
>
> /* This struct contains all the elements necessary to define a 5250
>  * window.
>  */
> typedef struct _tn5250window
> {
>   unsigned int windowid;        /* Numeric ID of this window */
>   unsigned int row;             /* Row window starts on */
>   unsigned int column;          /* Column window starts on */
>   unsigned int height;          /* height (in characters) of window */
>   unsigned int width;           /* width (in characters) of window */
>   unsigned int border[4];       /* Characters used to create borders
>                                  * Uses the masks as buf5250 */
> } tn5250window;
>
> Then I use an array of this struct:
>
> tn5250window win5250[10] = { {0, 0, 0, 0, 0, {0}} };

Unfortunately I can not use struct in java but what I did was save off 
the whole window structure as it comes in from the stream.  The 
structure has a length field id so I just copy all the bytes then 
process the byte array.  This byte array will then be saved off in a 
vector.  I am not saving this right now but am processing each 
structure that way in it's own module.  Just getting ready for the next 
phase because the way I implement windows is not correct.

I will look at the code but one thing you will have to take care of is 
that the whole window structure will sometimes not be passed.  I have 
never successfully created this situation in my code but had a couple 
of people send me examples of this.  The structure will only be start 
row/col and width and height.  You will then have to create the 
defaults from there.

>
> Each window is supposed to exist as an array element (right now only 10
> windows work, will be dynamic later).  Each array element also has it's
> own screen buffer.  The array element should persist as long as the 
> window
> exists on the screen.  The trouble I have is that so far it looks like 
> the
> whole screen is redrawn by the as/400, so it is hard to know which 
> window
> (of several) is being worked with.  Because of this I'm afraid my idea
> won't work.
>
> Also note that my patch above doesn't create a new buffer for each 
> window
> in tn5250.  Instead, create_window_structured_field() calls a function
> that x5250 uses to create a new buffer.

Yes am pretty sure I am working this way as well.  Will take a look at 
the patch.

>
>>> You are clearly doing something smarter than me since you have
>>> functioning
>>> windows and cursor progression working.  I wonder if there is a way 
>>> to
>>> tell the as/400 that I support cursor progression but not the create
>>> window structured field command?
>>
>> I wouldn't say smarter at all but maybe more traces.  I still get
>> things from users that I have never seen before and do not even know
>> how they were able to get that sequence of bits in the structure.  
>> They
>> do not have the source of the screen so I usually just have go from a
>> steam dump but it gets interesting.
>>
>> If there is a way I never found it but man would it make my our lives
>> easier.  I think when you turn on enhanced user interface level 3 you
>> get all of them as a bunch.  I think I have the minimum that can be
>> turned on and off.  I did find that you can control window headers and
>> footers with bit 4 so went ahead and did that.  I played for hours 
>> with
>> bit setting in there.  Humm now that I am thinking about it this also
>> turns on some other things.  I need to look at that again because I 
>> can
>> do without headers and footer if that is what it takes.
>
> I'll look at the QUERY command again as well.  It seems to me like I 
> went
> over this with some time ago and settled on the responses in my patch.
> But maybe a fresh look will give me more insight.

I am always tearing into that thing.  Sometimes I get the courage to 
start changing bits and find some weird things that are not documented. 
  Am pretty sure that both are correct.

>
>> After you asked here I went out to the archives and saw your patch.
>> There is something interesting there about the FCW and FFW.  When
>> parsing them you can receive a structure of those.  Meaning more than
>> one for a field.  I found this while implementing the word wrap that
>> you can receive a continuous field byte and also a wordwrap byte all 
>> in
>> the same field that made up an array of about 5 different field
>> attributes.  There may be missing lines in there but was wondering how
>> you were handling that.  I have a couple of ideas there if you would
>> like to discuss it.  Have not implemented it in my emulator yet but 
>> did
>> find a solution when I was working on the 3270 data stream
>> implementation.
>
> Are you looking at the patch I linked to above?  That patch handles the
> multiple FCW and FFW (at least FCW, I need to review FFW).  I'm pretty
> sure I got that stuff right.

Yeah it was the patch.  Like I said there were some lines that are 
truncated in the patch.  I still think I have a test laying around and 
will send it.  I am not handling it all perfectly either right now but 
it works for 99% of the case out there.

>
>> I also notice you send a 0x02 in the query command and I send a 0x07.
>> Not sure the difference here but also can not remember why.  CA sent a
>> 5E but that opens a can of worms that I am not even interested in
>> opening.
>
> I don't know anything about this either.  Again, a fresh look at the 
> query
> command is probably what I need to do.
>
>> Also what version of the code are you looking at from the tn5250j
>> project?  I have changed some things lately so would like to know if I
>> am handling some codes differently after fixing some bugs from when 
>> you
>> are looking at it.
>
> tn5250j - 0.5.7 pre3

CVS might be better.  The source is definately being changed right 
because I am changing how the library works.  It is going to be an 
actual framework this time but does not change the tnvt.java module 
which parses the data streams so that will not be a problem with using 
the CVS version.  The changes right now have more to do with taking the 
gui out of the modules.

The reason I want to change this to a framework/lib is so we can start 
doing a little screen scraping on the screens.  Lot's of ideas there.

Anyway maybe we can work on these other elements together when you get 
the windows done because two heads are better than one and have not had 
that before.  Nobody seems to want to dig into the datastreams with me. 
  All everyone wants is the gui with more functions.  You know, to tell 
the truth, I have spent 90% of my time getting the front end to work 
than on parsing the datastreams.

>
> James Rich
>
> Vs lbh cynl n Zvpebfsg PQ  onpxjneqf, lbh pna urne fngnavp zrffntrf. 
> Ohg
> rira jbefr, vs lbh cynl vg sbejneq, vg vafgnyyf gurve fbsgjner!
>         -- Fcbgvphf ba /.
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Tn5250j-develop mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/tn5250j-develop
>



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click