<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Dear all:<br>I have some (user point of view) experience with trestle and as I see in a kubuntu 8.04 box here with almost up to date cm3 environment, I have not seen in formsedit the bug you report (at least in the source code box), and looking where is actually used TypeInVBT, it's not actually imported by any interface, see (on cm3ide):<br>http://localhost:3800/public/ui/src/split/TypeInVBT.i3/<br>but it does TypeinVBT<br>http://localhost:3800/public/vbtkit/src/etext/TypeinVBT.i3/<br>imported by several clients (including vbtkit).<br>If I guess rigth you migth be using that TypeinVBT. As I say works fine (with this linux box in the formsedit program on the source code box). So I think if you have tested this software with a previous version of Trestle and it worked fine, then I think the  changes made in the cm3 sources have affected the mentioned
 Interface, so it's easier to catch the bug, but if you haven't tested with the previous version of Trestle (is not possible, or the behaviour is the same with both versions of Trestle), then could be some ¿? win32 dependant interface causing the bug. Could you make that comparison with of both Trestle implemenations using formsedit?<br>I can give it a try (first, setting a working win32 box with cm3) and see what happens with formsedit (or if you have a win32 box I can point an url of m3browser or cm3ide) to get an idea of what happens deeping in the sources of both implementations (from formsedit source). <br>Let me know if this is useful. Good luck.  <br><br>--- El <b>mar, 29/7/08, Tony Hosking <i><hosking@cs.purdue.edu></i></b> escribió:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;">De: Tony Hosking <hosking@cs.purdue.edu><br>Asunto: Re: [M3devel] need help with cm3 problem
 before I deliver software this week<br>Para: "Randy Coleburn" <rcoleburn@scires.com><br>CC: m3devel@elegosoft.com, m3-support@elego.de<br>Fecha: martes, 29 julio, 2008 4:04<br><br><div id="yiv311114697">Hmm, do we have any Trestle gurus these days?<div><br><div><div>On Jul 29, 2008, at 9:17 PM, Randy Coleburn wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="margin: 4px 4px 1px; font-family: Tahoma; font-style: normal; font-variant: normal; font-weight: normal; font-size: 10pt; line-height: normal; font-size-adjust: none; font-stretch: normal; -x-system-font: none;"> <div>Hi:</div> <div> </div> <div>I've been using cm3 to develop software I am delivering this week to a customer.  During the acceptance testing, we've run into a problem that I have not been able to solve.  I am hoping someone in the cm3 community can help.  I need to solve this problem ASAP this week.</div> <div> </div>
 <div>This problem is easily reproduced using the "formsedit" program.</div> <div> </div> <div>The problem is with the TypeIn and TypeScript FormsVBT elements used in my program.  Since formsedit uses these, you can easily reproduce the problem.</div> <div> </div> <div>Click with the mouse to move the insertion point somewhere in the text.  Observe that the cursor moves to that point.  Now, use the left arrow key to move the insertion point a few characters to the left.  Then, type a few characters.  Observe that the first character you type shows up at the place where you initially moved the cursor with the mouse, while the remaining characters show up at the place where you moved the cursor via the left-arrow key.  This behavior is wrong.  The first character you type should be at the current insertion point, not at the one from the mouse move.</div> <div> </div> <div>I'm sure the fix is easy, but
 I haven't been able to locate it yet.  It probably has to do with the internal idea of the insertion point not getting updated properly.  Note that the cursor on the screen is in the right spot, it's just that the first character gets inserted into the TypeIn or TypeScript in the wrong place (i.e., it is put at the place from the mouse move, not from the last arrow key move).</div> <div> </div> <div>Any assistance you can provide is very much appreciated and will go a long way toward keeping Modula-3 use alive and well for this project.  If we can't fix this one, the customers will want to re-code everything in some Microsoft language, probably C++ or C#.</div> <div> </div> <div>I also have one other strange anomaly, but it is less of an issue at the moment.  On a Dell M4300 laptop at 1920x1200 resolution, all pixmaps are getting stretched vertically.  Text seems to be fine as do HBox, Rim, Frame, etc., but pixmaps get
 vertically stretched out of proportion.  This problem has not happened on all other platforms I've tested, (e.g. Lenovo T60 at 1024x768 and 2048x1024, IBM G40 at 1400x1050, etc.).  Any ideas on what could be the issue?  I know that 1920x1200 is a strange resolution, but it is the native resolution for the M4300 laptop computer that the customer is using.  I checked and the computer is set for 96dpi (normal).  Perhaps there is some Trestle setting that I need to tweak on this platform, or perhaps there is a bug that needs fixing.</div> <div> </div> <div>Regards,</div> <div>Randy Coleburn</div> <div>Senior Systems Engineer</div> <div>Scientific Research Corporation</div></div></blockquote></div><br></div></div></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>