<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">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="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;">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></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>