Re: CREATE WINDOW structured field (fwd)

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.

> >> 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}} };

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.

> > 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.

> 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.

> 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

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