<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>Olaf:</DIV>
<DIV> </DIV>
<DIV>The problem reproduces every time on my system. I've tried it on three different XP computers with same results every time.</DIV>
<DIV> </DIV>
<DIV>I froze my Modula-3 sources a couple of months ago in order to ensure stability during production of my deliverables. At the time they were frozen, I was up-to-date with all of the cm3 sources via cvs.</DIV>
<DIV> </DIV>
<DIV>I've attached a gzipped formsedit program that I just built on my system using the build_standalone() directive. See if you can unzip this and run it on your system and let me know if you get the bad behavior problem.</DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV>Randy<BR><BR>>>> Olaf Wagner <wagner@elegosoft.com> 7/31/2008 12:44 PM >>><BR>Quoting Randy Coleburn <rcoleburn@scires.com>:<BR><BR>> Rodney:<BR>><BR>> I am using Windows XP Professional, Service Pack 2 (on some systems,<BR>> Service Pack 3 is applied).<BR><BR>Hi Randy,<BR><BR>I just tried formsedit on exactly this system (XP professional, SP2)<BR>in my virtual machine, and wasn't able to see any fault wrt. cursor<BR>processing and typing, too. I checked-out and compiled all the latest<BR>sources of the relevant gui packages (ui, vbtkit, formsvbt etc.), but<BR>that didn't make any difference (though some changes had been applied).<BR>For me it just seems to work correctly. It may be of interest though<BR>that some months ago when I was last working on this system for the<BR>regression tests, I applied all existing Microsoft patches; but you've<BR>done that probably, too.<BR><BR>I've got no idea about the pixmap problem, too.<BR>As long as nobody else is able to reproduce the problem it will<BR>remain difficult to analyze this problem.<BR><BR>Sorry that I cannot be of more help,<BR><BR>Olaf<BR><BR>PS: Are you sure that you are really using exactly the current CM3 gui<BR>libraries, and not some adapted or modified stuff from an older<BR>release?<BR><BR>> Michel Dagenais suggested that if the problem does not reproduce on<BR>> Linux, that it might have to do with how Windows reports character<BR>> events. He thought a Filter VBT may exist somewhere that would aid in<BR>> debugging by printing method calls before propagating them to<BR>> father/son. This filter VBT would be inserted at different places in<BR>> the VBT tree to get tracing information. Are you familiar with<BR>> something like this?<BR>><BR>> As for the pixmaps, Michel suggests increasing the resolution of the<BR>> original pixmap to help alleviate problems with upscaling. I may try<BR>> this, but of course, FormsVBT uses a lot of pixmap resources, for<BR>> example, radio, boolean, checkmark, numeric, etc all use pixmaps.<BR>><BR>> Regards,<BR>> 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<BR>> 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,<BR>> but<BR>>> our email server has been offline for nearly 24-hours. There were<BR>> some<BR>>> severe electrical storms that took down both redundant power systems<BR>> 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<BR>> 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<BR>> any<BR>>> event, it is a real problem for me.<BR>>><BR>>> As for the pixmap stretching problem, I have tested various<BR>> resolutions<BR>>> on the customer's computer. Unfortunately, the customer demands that<BR>><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<BR>> 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<BR>> in<BR>>> > the cm3 community can help. I need to solve this problem ASAP<BR>> 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<BR>> 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>><BR>>> > text. Observe that the cursor moves to that point. Now, use the<BR>><BR>>> > left arrow key to move the insertion point a few characters to the<BR>><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>><BR>>> > the cursor with the mouse, while the remaining characters show up<BR>> at<BR>>> > the place where you moved the cursor via the left-arrow key.<BR>> This<BR>>> > behavior is wrong. The first character you type should be at the<BR>><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<BR>> 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<BR>> yet.<BR>>> > It probably has to do with the internal idea of the insertion<BR>> point<BR>>> > not getting updated properly. Note that the cursor on the screen<BR>><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.,<BR>> it<BR>>> > is put at the place from the mouse move, not from the last arrow<BR>><BR>>> > key move).<BR>>> ><BR>>> > Any assistance you can provide is very much appreciated and will<BR>> 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<BR>> C#.<BR>>> ><BR>>> > I also have one other strange anomaly, but it is less of an issue<BR>> at<BR>>> > the moment. On a Dell M4300 laptop at 1920x1200 resolution, all<BR>><BR>>> > pixmaps are getting stretched vertically. Text seems to be fine<BR>> as<BR>>> > do HBox, Rim, Frame, etc., but pixmaps get vertically stretched<BR>> out<BR>>> > of proportion. This problem has not happened on all other<BR>> platforms<BR>>> > I've tested, (e.g. Lenovo T60 at 1024x768 and 2048x1024, IBM G40<BR>> at<BR>>> > 1400x1050, etc.). Any ideas on what could be the issue? I know<BR>><BR>>> > that 1920x1200 is a strange resolution, but it is the native<BR>>> > resolution for the M4300 laptop computer that the customer is<BR>> using.<BR>>> > I checked and the computer is set for 96dpi (normal). Perhaps<BR>><BR>>> > there is some Trestle setting that I need to tweak on this<BR>> 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,<BR>> Germany<BR>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23<BR>> 45 86 95<BR>>> <A href="http://www.elegosoft.com">http://www.elegosoft.com</A> | Geschäftsführer: Olaf Wagner | Sitz:<BR>> Berlin<BR>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:<BR>> 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>><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>