<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-15">
<META content="MSHTML 6.00.6000.16674" name=GENERATOR></HEAD>
<BODY style="MARGIN: 4px 4px 1px">
<DIV>Hi Olaf, Daniel, Rodney, et al:</DIV>
<DIV> </DIV>
<DIV>Thanks for your responses so far. Sorry for the delay in replying, but our email server has been offline for nearly 24-hours. There were some severe electrical storms that took down both redundant power systems for our email system. Hope I have not missed any of your replies.</DIV>
<DIV> </DIV>
<DIV>Right now, I am delivering the software on Windows XP using SP2 or greater. I have not tried to see if this problem also occurs on Unix. I don't have ready access to a unix system from my current location.</DIV>
<DIV> </DIV>
<DIV>So it is perhaps a Windows-only problem with Trestle/FormsVBT. In any event, it is a real problem for me.</DIV>
<DIV> </DIV>
<DIV>As for the pixmap stretching problem, I have tested various resolutions on the customer's computer. Unfortunately, the customer demands that the display resolution stay at the 1920x1200.</DIV>
<DIV>1920x1200=pixmap stretch problem</DIV>
<DIV>1680x1050=pixmap stretch problem</DIV>
<DIV>1440x900=no problem</DIV>
<DIV>1024x768=no problem</DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV>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">http://www.elegosoft.com</A> | Geschäftsführer: Olaf Wagner | Sitz: Berlin<BR>Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<BR><BR><BR></DIV></BODY></HTML>