<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>
<DIV>Daniel:</DIV>
<DIV> </DIV>
<DIV>I tried @M3SlowTrace, but it does not seem to produce any output.</DIV>
<DIV> </DIV>
<DIV>I tried @M3TraceWinMsgs and it does indeed produce quite a lot of output. I'm not sure what it all means though. Here is a sample:</DIV>
<DIV><BR>msg 1033 = PAINTBATCH_VBT<BR>msg 1033 = PAINTBATCH_VBT<BR>msg 1033 = PAINTBATCH_VBT<BR>msg 1033 = PAINTBATCH_VBT<BR>msg 1033 = PAINTBATCH_VBT<BR>msg 132 = WM_NCHITTEST<BR>msg 32 = WM_SETCURSOR<BR>msg 513 = WM_LBUTTONDOWN<BR>msg 1033 = PAINTBATCH_VBT<BR>msg 1033 = PAINTBATCH_VBT<BR>msg 514 = WM_LBUTTONUP<BR> | msg 132 = WM_NCHITTEST<BR> | msg 533 = ???<BR>msg 514 = WM_LBUTTONUP<BR>msg 132 = WM_NCHITTEST<BR>msg 32 = WM_SETCURSOR<BR>msg 512 = WM_MOUSEMOVE (aka WM_MOUSEFIRST)<BR>msg 1033 = PAINTBATCH_VBT<BR>msg 1033 = PAINTBATCH_VBT<BR>msg 256 = WM_KEYDOWN (aka WM_KEYFIRST)<BR>msg 1033 = PAINTBATCH_VBT<BR>msg 1033 = PAINTBATCH_VBT<BR>msg 257 = WM_KEYUP<BR>msg 1033 = PAINTBATCH_VBT<BR>msg 256 = WM_KEYDOWN (aka WM_KEYFIRST)<BR>msg 1033 = PAINTBATCH_VBT<BR>msg 1033 = PAINTBATCH_VBT<BR>msg 257 = WM_KEYUP<BR>msg 1033 = PAINTBATCH_VBT<BR>msg 256 = WM_KEYDOWN (aka WM_KEYFIRST)<BR>msg 1033 = PAINTBATCH_VBT<BR>msg 1033 = PAINTBATCH_VBT<BR>msg 257 = WM_KEYUP<BR>msg 1033 = PAINTBATCH_VBT<BR>msg 1033 = PAINTBATCH_VBT<BR>msg 1033 = PAINTBATCH_VBT<BR>msg 256 = WM_KEYDOWN (aka WM_KEYFIRST)<BR>msg 258 = WM_CHAR<BR>msg 1033 = PAINTBATCH_VBT<BR>msg 1033 = PAINTBATCH_VBT<BR>msg 257 = WM_KEYUP<BR>msg 1033 = PAINTBATCH_VBT<BR>msg 256 = WM_KEYDOWN (aka WM_KEYFIRST)<BR>msg 258 = WM_CHAR<BR>msg 1033 = PAINTBATCH_VBT<BR>msg 1033 = PAINTBATCH_VBT<BR>msg 257 = WM_KEYUP<BR>msg 1033 = PAINTBATCH_VBT<BR>msg 1033 = PAINTBATCH_VBT<BR>msg 1033 = PAINTBATCH_VBT</DIV>
<DIV> </DIV>
<DIV>During this brief snippet above, I clicked in the formsedit window, then pressed the left arrow a few times, then typed a couple of keys. The first key I pressed showed up at the position of the initial mouse click, while the rest showed up at the cursor position.</DIV>
<DIV> </DIV>
<DIV>Do these messages help? It is interesting to note that one of the messages (#533) is identified as "???"</DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV>Randy</DIV>
<DIV><BR>>>> "Daniel Alejandro Benavides D." <dabenavidesd@yahoo.es> 7/31/2008 7:16 PM >>><BR></DIV>
<TABLE cellSpacing=0 cellPadding=0 border=0>
<TBODY>
<TR>
<TD vAlign=top>Hi all:<BR>They are @M3TraceWinMsgs and @M3SlowTrace<BR>I get it in the file m3-ui/ui/src/winvbt/WinTrestle.m3<BR>lines 1096, 1097<BR> trace_msgs := RTParams.IsPresent ("TraceWinMsgs");<BR> slow_trace := RTParams.IsPresent ("SlowTrace");<BR>Thanks<BR><BR><BR>--- El <B>jue, 31/7/08, Daniel Alejandro Benavides D. <I><dabenavidesd@yahoo.es></I></B> escribió:<BR>
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: rgb(16,16,255) 2px solid">De: Daniel Alejandro Benavides D. <dabenavidesd@yahoo.es><BR>Asunto: Re: [M3devel] need help with cm3 problem before I deliver software this week<BR>Para: "Rodney M. Bates" <rodney.bates@wichita.edu>, "Randy Coleburn" <rcoleburn@scires.com><BR>CC: m3devel@elegosoft.com<BR>Fecha: jueves, 31 julio, 2008 5:43<BR><BR><PRE>Hi all:<BR>I think I remember somewhere there are runtime
parameters for debugging Trestle<BR>on windows implementation. Check the source code of it; I can't find them in<BR>this moment.<BR>Thanks<BR><BR>--- El jue, 31/7/08, Randy Coleburn <rcoleburn@scires.com> escribió:<BR>De: Randy Coleburn <rcoleburn@scires.com><BR>Asunto: Re: [M3devel] need help with cm3 problem before I deliver software this<BR>week<BR>Para: "Rodney M. Bates" <rodney.bates@wichita.edu><BR>CC: m3devel@elegosoft.com<BR>Fecha: jueves, 31 julio, 2008 10:51<BR><BR><BR> <BR>Rodney:<BR> <BR>I am using Windows XP Professional, Service Pack 2 (on some systems, Service<BR>Pack 3 is applied).<BR> <BR>Michel Dagenais suggested that if the problem does not reproduce on Linux, that<BR>it might have to do with how Windows reports character events. He thought a<BR>Filter VBT may exist somewhere that would aid in debugging by printing method<BR>calls before propagating them to father/son. This filter VBT would be
inserted<BR>at different places in the VBT tree to get tracing information. Are you<BR>familiar with something like this?<BR> <BR>As for the pixmaps, Michel suggests increasing the resolution of the original<BR>pixmap to help alleviate problems with upscaling. I may try this, but of<BR>course, FormsVBT uses a lot of pixmap resources, for example, radio, boolean,<BR>checkmark, numeric, etc all use pixmaps.<BR> <BR>Regards,<BR>Randy<BR><BR>>>> "Rodney M. Bates" <rodney.bates@wichita.edu><BR>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><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>>>><BR>> Quoting Randy Coleburn <rcoleburn@scires.com>:<BR>> <BR>> > Hi:<BR>> ><BR>> > I've been using cm3 to develop software I am delivering this<BR>week to <BR>> > a customer. During the acceptance testing, we've run into a<BR><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"<BR>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<BR>the <BR>> > left arrow key to move the insertion point a few characters to<BR>the <BR>> > left. Then, type a few characters. Observe that the first <BR>> > character you type shows up at the place where you initially<BR>moved <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<BR>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<BR>it 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<BR>screen <BR>> > is in the right spot, it's just that the first character gets<BR><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>> > 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<BR>to <BR>> > re-code everything in some Microsoft language, probably C++ or C#</PRE></BLOCKQUOTE></TD></TR></TBODY></TABLE><BR>
<HR SIZE=1>
<BR><FONT face=Verdana size=-2>Enviado desde <A href="http://us.rd.yahoo.com/mailuk/taglines/isp/control/*http://us.rd.yahoo.com/evt=52431/*http://es.docs.yahoo.com/mail/overview/index.html">Correo Yahoo!</A><BR>La bandeja de entrada más inteligente.<BR></FONT></BODY></HTML>