<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>
You reminded me -- there is something in the code about double reporting of characters and ignoring the first one.<BR>
It is, like the main/environment stuff, one of those suspicious changes that crept in  -- a change with a comment indicating the changer didn't know what is going on, and overridable with environment variable/command line switch. But I had less luck resolving this than with main/environment.<BR>
Does it repro with 4.1? Or 3.6?<BR>
I haven't tried yet but will shortly.<BR>
Been on gcc related tangents since I got a sparc/Solaris machine, sorry.<BR>
 <BR>
 - Jay<BR><BR><BR>

<HR>
<BR>
Date: Thu, 31 Jul 2008 11:51:28 -0400<BR>From: rcoleburn@scires.com<BR>To: rodney.bates@wichita.edu<BR>CC: m3devel@elegosoft.com<BR>Subject: Re: [M3devel] need help with cm3 problem before I deliver software this week<BR><BR><BR>
<META content="Microsoft SafeHTML" name=Generator>
<DIV>Rodney:</DIV>
<DIV> </DIV>
<DIV>I am using Windows XP Professional, Service Pack 2 (on some systems, Service Pack 3 is applied).</DIV>
<DIV> </DIV>
<DIV>Michel Dagenais suggested that if the problem does not reproduce on Linux, that it might have to do with how Windows reports character events.  He thought a Filter VBT may exist somewhere that would aid in debugging by printing method calls before propagating them to father/son.  This filter VBT would be inserted at different places in the VBT tree to get tracing information.  Are you familiar with something like this?</DIV>
<DIV> </DIV>
<DIV>As for the pixmaps, Michel suggests increasing the resolution of the original pixmap to help alleviate problems with upscaling.  I may try this, but of course, FormsVBT uses a lot of pixmap resources, for example, radio, boolean, checkmark, numeric, etc all use pixmaps.</DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV>Randy<BR><BR>>>> "Rodney M. Bates" <rodney.bates@wichita.edu> 7/31/2008 9:33 AM >>><BR>Which variant of the M3 Windows target are you using?  I don't have any<BR>of them built right now.<BR><BR>Randy Coleburn wrote:<BR>> Hi Olaf, Daniel, Rodney, et al:<BR>>  <BR>> Thanks for your responses so far.  Sorry for the delay in replying, but <BR>> our email server has been offline for nearly 24-hours.  There were some <BR>> severe electrical storms that took down both redundant power systems for <BR>> our email system.  Hope I have not missed any of your replies.<BR>>  <BR>> Right now, I am delivering the software on Windows XP using SP2 or <BR>> greater.  I have not tried to see if this problem also occurs on Unix.  <BR>> I don't have ready access to a unix system from my current location.<BR>>  <BR>> So it is perhaps a Windows-only problem with Trestle/FormsVBT.  In any <BR>> event, it is a real problem for me.<BR>>  <BR>> As for the pixmap stretching problem, I have tested various resolutions <BR>> on the customer's computer.  Unfortunately, the customer demands that <BR>> the display resolution stay at the 1920x1200.<BR>> 1920x1200=pixmap stretch problem<BR>> 1680x1050=pixmap stretch problem<BR>> 1440x900=no problem<BR>> 1024x768=no problem<BR>>  <BR>> Regards,<BR>> Randy<BR>> <BR>>  >>> Olaf Wagner <wagner@elegosoft.com> 7/30/2008 2:24 AM >>><BR>> Quoting Randy Coleburn <rcoleburn@scires.com>:<BR>> <BR>>  > Hi:<BR>>  ><BR>>  > I've been using cm3 to develop software I am delivering this week to <BR>>  >  a customer.  During the acceptance testing, we've run into a <BR>>  > problem  that I have not been able to solve.  I am hoping someone in <BR>>  > the cm3  community can help.  I need to solve this problem ASAP this <BR>>  > week.<BR>>  ><BR>>  > This problem is easily reproduced using the "formsedit" program.<BR>>  ><BR>>  > The problem is with the TypeIn and TypeScript FormsVBT elements used <BR>>  >  in my program.  Since formsedit uses these, you can easily <BR>>  > reproduce  the problem.<BR>>  ><BR>>  > Click with the mouse to move the insertion point somewhere in the  <BR>>  > text.  Observe that the cursor moves to that point.  Now, use the  <BR>>  > left arrow key to move the insertion point a few characters to the  <BR>>  > left.  Then, type a few characters.  Observe that the first  <BR>>  > character you type shows up at the place where you initially moved  <BR>>  > the cursor with the mouse, while the remaining characters show up at <BR>>  >  the place where you moved the cursor via the left-arrow key.  This  <BR>>  > behavior is wrong.  The first character you type should be at the  <BR>>  > current insertion point, not at the one from the mouse move.<BR>> <BR>> Randy,<BR>> <BR>> I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't able<BR>> to reproduce the problem on FreeBSD 6.3.<BR>> <BR>> Does the problem show up on all platforms you are working on?<BR>> Which are these?<BR>> <BR>> Are there any local modifications to the libraries which I may not<BR>> have?<BR>> <BR>> If it occurs only on Unix, it may be possible that a weird window<BR>> manager interferes with the event delivery; otherwise I've got no<BR>> good idea. If on Unix, you/we could perhaps test the behaviour<BR>> on a different (remote) X display?<BR>> <BR>> Please provide more data about the problem context and how to<BR>> reproduce it.<BR>> <BR>> Regards,<BR>> <BR>> Olaf<BR>> <BR>>  > I'm sure the fix is easy, but I haven't been able to locate it yet.  <BR>>  >  It probably has to do with the internal idea of the insertion point <BR>>  >  not getting updated properly.  Note that the cursor on the screen <BR>>  > is  in the right spot, it's just that the first character gets <BR>>  > inserted  into the TypeIn or TypeScript in the wrong place (i.e., it <BR>>  > is put at  the place from the mouse move, not from the last arrow <BR>>  > key move).<BR>>  ><BR>>  > Any assistance you can provide is very much appreciated and will go  <BR>>  > a long way toward keeping Modula-3 use alive and well for this  <BR>>  > project.  If we can't fix this one, the customers will want to  <BR>>  > re-code everything in some Microsoft language, probably C++ or C#.<BR>>  ><BR>>  > I also have one other strange anomaly, but it is less of an issue at <BR>>  >  the moment.  On a Dell M4300 laptop at 1920x1200 resolution, all  <BR>>  > pixmaps are getting stretched vertically.  Text seems to be fine as  <BR>>  > do HBox, Rim, Frame, etc., but pixmaps get vertically stretched out  <BR>>  > of proportion.  This problem has not happened on all other platforms <BR>>  >  I've tested, (e.g. Lenovo T60 at 1024x768 and 2048x1024, IBM G40 at <BR>>  >  1400x1050, etc.).  Any ideas on what could be the issue?  I know  <BR>>  > that 1920x1200 is a strange resolution, but it is the native  <BR>>  > resolution for the M4300 laptop computer that the customer is using. <BR>>  >   I checked and the computer is set for 96dpi (normal).  Perhaps  <BR>>  > there is some Trestle setting that I need to tweak on this platform, <BR>>  >  or perhaps there is a bug that needs fixing.<BR>>  ><BR>>  > Regards,<BR>>  > Randy Coleburn<BR>>  > Senior Systems Engineer<BR>>  > Scientific Research Corporation<BR>>  ><BR>> <BR>> <BR>> <BR>> -- <BR>> Olaf Wagner -- elego Software Solutions GmbH<BR>>                 Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany<BR>> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95<BR>>     <A href="http://www.elegosoft.com/" target=_blank>http://www.elegosoft.com</A> | Geschäftsführer: Olaf Wagner | Sitz: Berlin<BR>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<BR>> <BR>> <BR><BR>-- <BR>-------------------------------------------------------------<BR>Rodney M. Bates, retired assistant professor<BR>Dept. of Computer Science, Wichita State University<BR>Wichita, KS 67260-0083<BR>316-978-3922<BR>rodney.bates@wichita.edu<BR><BR></DIV></body>
</html>