Re: CREATE WINDOW structured field (fwd)

James

On Jul 13, 2004, at 11:54 PM, James Rich wrote:

> Replying to just the tn5250j list since that seems like the best place 
> for
> everyone.
>
> On Tue, 13 Jul 2004, Kenneth J. Pouncey wrote:
>
>> Usually when a window is created there is a save screen issued and 
>> when
>> a window is taken off the screen there is a restore screen issued.  So
>
> You say "usually".  Is there any way to find out if this is always the
> case?

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.

>
>> in reality you do not have to keep track of windows.  What you have to
>> do is save off the window(s) in the save screen and then recreate them
>> on the restore screen.  As you notice I do nothing with the clear gui
>
> Hmm...  In my case I think I want to keep track of them.  If I can, 
> that
> will allow me to make the client much more flexible in terms of what it
> can do.

I agree just never found out how.

>
>> command yet.  What I have seen with this is that you would clear all
>> gui constucts from the screen in this command that was last created
>> since the save screen.  So some marker needs to be used.  In my last
>> version I am keeping the actual window structure that was passed so I
>> can do this but have not fully implemented it (see below).
>
> So far I've yet to ever receive the clear all gui constructs order.  I
> guess this only happens if there are gui elements other than windows
> (scrollbars and the like perhaps?).

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.

>
> One of the ideas I had was to use a completely new buffer for the 
> screen
> everytime a save screen command was issued.  Upon receiving the restore
> screen destroy the new buffer and use the old one.  This is how my 
> demo of
> x5250 worked for windows.  Each window used it's own buffer.  As 
> windows
> were created and destroyed so too were the respective buffers.  That 
> way a
> marker is not required, just activate the previous buffer.

Yes that is how it should work IMHO.  If I understood what you said 
here that is how I am doing it.  That buffer is what I send in the save 
screen so restore it when it comes back as part of the restore screen.

>
>> I tried saving off the window structure a long time ago but the as400
>> was not accepting all the data that I was sending so was not able to
>> save off the window structure on a very busy screen so I just saved 
>> off
>> the characters on the screen so when a restore screen is issued the
>> window is not really recreated but just the characters on the screen
>> were so the window gets restored like it would look by not using
>> enhanced mode.  This means that the characters :...............: get
>> restored instead of the graphic symbols.  I have since then redone the
>> way I do a save screen and do not know if the window structure would 
>> be
>> able to be saved off and restored without the as400 complaining.  Also
>> this was on a very old model of an as400 and also do not know if the
>> controller has changed again.
>
> Save the window structure - as part of the SAVE SCREEN command?  For 
> me,
> the save screen command occurs before the create window structured 
> field
> occurs so there's no window to save.  Unless you mean saving the window
> structure that is sent to you as part of the create windows structured
> field command, but that doesn't jibe with the rest of what you said.

Unless you have windows upon windows.  For instance a window pops up 
and then from there you do something that initiates another window.

>
> Or do you mean when another window is created saving the first window 
> as
> part of the save screen command?  In that case, I would have guessed 
> that
> you just save the contents of the window and not the sctructure or the
> rest of the screen.

Yes.

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

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

Please ask more questions here as I find this very interesting.  Maybe 
we both will find a nice solution to this.

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.

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.

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.

Regards

Kenneth

>
> 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 sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Tn5250j-develop mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/tn5250j-develop
>



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com