Re: Binary Dist (setup program) for Win32

On Monday 08 April 2002 7:10 pm, Scott Klement wrote:
> On 8 Apr 2002, Martin Rowe wrote:
> > I've tried it on a few more boxes at work now and the install itself
> > is very slick; no problems to report. There is, I think, a bug in the
> > Quick Connect for device name where only the first nine characters of
> > the name get used. A ten character name like TN5250TEST ends up as
> > TN5250TES for the session name. It works fine from tn5250rc however,
> > so I assume it's parsing in QC at fault.
>
> Yuck.  I guess I really missed the boat on that one. :)  That should be
> easy to fix, I'll try to fix it tonight after work.

Actually, at first I thought it was a bug in the emulator display, as
I've been getting some weird screen oddities recently[1]. As it worked
fine from tn5250rc I thought no more of it until it did the same at work.


> > Incidentaly, is there anyway of defaulting the
> > map to other than 37 (285 for me) used on QC, other than recompiling
> > specifically.
>
> You want it to pop-up 285 in the Quick-Connect dialog, right?
> I could change it so that "tn5250 map=285" would cause the
> quick-connect dialog to bring up "285".  (At least, I think I could...)
>  Would that help?

Yes, that's the idea. I don't know if the initial setup dialog could
include a few 'wizard' type questions to get the commandline options set
appropriately. I know it's covered in the docs (very well, I should add)
but reading documentation doesn't always seem to be top of the list when
getting software installed & configured :(

> > The only other thing that's got me stumped is running it through VNC.
> > For some bizarre reason the roll and cursor keys don't do anything at
> > all. They seem fine using them on the Windows PC directly, but nada
> > if accessed through a VNC session. Does anyone else see this effect?
> > The cursor keys work fine in all other Windows apps via VNC that I've
> > tried - including running vncviewer on the windows box back to my
> > Linux box and xt5250 running there (though response is a bit slow
> > this way ;-).
>
> The keyboard handler in the Windows version is RADICALLY different
> than the one in xt5250 (actually "cursesterm").
>
> Do the function keys work?   How about error reset, sysreq?  I'm
> thinking that maybe VNC is only sending WM_CHAR messages to the window
> instead of WM_KEYDOWN and WM_KEYUP messages.   That's unfortunate,
> since we can't can't do all of our possible keystrokes without using
> the lower level messages.

It seems to be the Insert/Home/PageUp/Delete/End/PageDown and cursor keys
that have zero function. The number pad with numlock off doesn't work
either (as the other keys). Print screen does, and shift-Esc does a
SysRq. For some reason tab only goes forwards *unless* I hit the Windows
key first, when it goes backwards. The usual combination of Shift-Tab
doesn't work properly. Is there anything I can do to get more on this, or
is it just bad luck. The only Windows boxes I use are accessed by VNC or
RDesktop (MS terminal server) so I can't do too much to test it at work.

> > Finally, running a precompiled version instead of tweaked CVS one
> > made me take notice the colour issue again. What is the reason why
> > cyan is substituted for blue?
>
> Well, that's what the Unix version does... it uses Cyan instead of
> Blue. Also, thats what RUMBA does by default (which is the other
> emulator we use here).  Actually, I originally used blue in the Windows
> version of TN5250, but my co-worker (who I asked to try it out)
> immediately complained about it being blue, so I made it cyan before
> releasing it to the public :)

I don't actually use blue (too hard to see) but nabbed the blue/purple
colour from a Client Access session - #7b91f6. MediumSlateBlue from
rgb.txt works well too. Is that doable in the Windows version?

> > I'm guessing it's down to readable colours
> > available when tn5250 is run in a console, but it would be better
> > (IMHO) to use the correct ones where possible. I know some people
> > like to remap them anyway, but as blue and cyan are compiled to the
> > same colour, you can't remap them independantly.
>
> Yeah, we really need to add color mapping support!   Along with
> keyboard mapping...   One of these days, I'll get around to that... :)

Hey, don't forget keyboard macros and on the fly font selection ;-) BTW
I'm well impressed with the copy/paste function, good work.

> Actually, color mapping would be pretty easy to do since there are only
> 8 possible 5250 colors.   Green, White, Red, Turquoise, Yello, Pink,
> Blue and Black.  They could easily be config keywords:
>
>       green = 0,255,0
>       white = 255,255,255
>
> etc.  (the numbers are the RGB values)
>
> Of course, the RGB values wouldn't work in cursesterm...   sigh.   I
> could we could "just know" that 0,255,255 = cyan, 255,0,0 is red, etc.

It's the variation from standard colours that people use that surprises
me. I try to work with 'standard' colours then find the users have
strange schemes of beige or pink instead. Some equivalent of .Xresources
would suit me, but I've no idea how that's done in Windows.

Regards, Martin
[1] Every now & then a character near the right edge of the screen where
an input field wraps to the next line get stuck and the cursor just steps
over it (can't delete it) and it stays there until the screen is changed.
Another one is the switch from 24x80 to 27x132 where the session freezes
after the window has resized to 27x132 but while the font & contents is
still at 24x80. Hitting a key or switching desktops seems to cure it. It
only started happening last week, and I'm running a CVS version from over
a month ago.
--
martin@dbg400.net  jamaro@firstlinux.net  http://www.dbg400.net        /"\
DBG/400 - DataBase Generation utilities - AS/400 / iSeries Open        \ /
Source free test environment tools and others (file/spool/misc)         X
[this space for hire]  ASCII Ribbon Campaign against HTML mail & news  / \