<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>
oh, well, I have a file over 2gig at the root of my drive...<BR>
 <BR>
PROCEDURE BuildStatus (READONLY ffd  : WinBase.WIN32_FIND_DATA;<BR>                     VAR(*OUT*) stat : File.Status) =<BR>  BEGIN<BR>    stat.size := ffd.nFileSizeLow;<BR>    stat.modificationTime := TimeWin32.FromFileTime(ffd.ftLastWriteTime);<BR>    IF Word.And(ffd.dwFileAttributes, WinNT.FILE_ATTRIBUTE_DIRECTORY) # 0<BR>      THEN stat.type := DirectoryFileType;<BR>      ELSE stat.type := RegularFile.FileType; (* more or less... *)<BR>    END;<BR>  END BuildStatus;<BR><BR>
  Status = RECORD<BR>    type: Type;<BR>    modificationTime: Time.T;<BR>    size: CARDINAL<BR>  END;<BR><BR>
This should be a 64 bit integer...<BR>
 <BR>
Any ideas for an easy compatible fix?<BR>
Making it 64 bits is perhaps breaking..and won't "just work" on Win32 anyway.<BR>
Still, probably changing it to LONGINT or LongWord.T is goodness.<BR>
But one wonders about breaking preexisting pickles? ? ?<BR>
You know, what type changes are ok?<BR>
DOUBLE (er, LONGFLOAT?) would also be kind of good -- it would allow 53 bit file sizes..<BR>
 <BR>
Since Status is not branded, not particularly amenable to pickling?<BR>
Or anyone could embed it in a branded type?<BR>
 <BR>
 - Jay<BR><BR><BR>

<HR>
<BR>
From: jayk123@hotmail.com<BR>To: dabenavidesd@yahoo.es; rodney.bates@wichita.edu; rcoleburn@scires.com<BR>Date: Fri, 1 Aug 2008 08:43:31 +0000<BR>CC: m3devel@elegosoft.com<BR>Subject: Re: [M3devel] need help with cm3 problem before I deliver software this week<BR><BR>
<META content="Microsoft SafeHTML" name=Generator>
<STYLE>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Tahoma;}
</STYLE>
I can reproduce the problem. Exactly as well reported.<BR>It kind of only happens once. Bring up formsedit, click, left arrow(s), type, it does what Randy said.<BR>Click again, arrows again, type again, not a second time. Good enough though.<BR>Close formsedit, reopen, it repros. Good.<BR>file.save, type backslash or forward slash in the dialog, press return, and boom:<BR>Most other strings are ok, but a single forward or backward slash, booms.<BR> <BR>***<BR>*** runtime error:<BR>***    An enumeration or subrange value was out of range.<BR>***    file "..\src\os\WIN32\FSWin32.m3", line 435<BR>***<BR>Stack trace:<BR>   FP         PC      Procedure<BR>---------  ---------  -------------------------------<BR>0x67afccc   0x42524f  BuildStatus + 0x21 in ..\src\os\WIN32\FSWin32.m3<BR>0x67afe60   0x4251dc  Status + 0x137 in ..\src\os\WIN32\FSWin32.m3<BR>0x67aff50   0xd9d131  DoStats + 0x253 in ..\src\lego\FileBrowserVBT.m3<BR>0x67aff88   0x53a6ca  RunThread + 0x1f6 in ..\src\thread\WIN32\ThreadWin32.m3<BR>0x67affb4   0x53a463  ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3<BR>.........  .........  ... more frames ...<BR> <BR>bugs...<BR> <BR> <BR>And is that red line supposed to appear in the gui?<BR> <BR> - Jay<BR><BR><BR><BR><BR>> Date: Thu, 31 Jul 2008 22:43:07 +0000<BR>> From: dabenavidesd@yahoo.es<BR>> To: rodney.bates@wichita.edu; rcoleburn@scires.com<BR>> CC: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] need help with cm3 problem before I deliver software this week<BR>> <BR>> Hi all:<BR>> I think I remember somewhere there are runtime parameters for debugging Trestle on windows implementation. Check the source code of it; I can't find them in 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 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 Pack 3 is applied).<BR>>  <BR>> Michel Dagenais suggested that if the problem does not reproduce on Linux, that it might have to do with how Windows reports character events.  He thought a Filter VBT may exist somewhere that would aid in debugging by printing method calls before propagating them to father/son.  This filter VBT would be inserted at different places in the VBT tree to get tracing information.  Are you familiar with something like this?<BR>>  <BR>> As for the pixmaps, Michel suggests increasing the resolution of the original pixmap to help alleviate problems with upscaling.  I may try this, but of course, FormsVBT uses a lot of pixmap resources, for 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 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>> > 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 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><BR></body>
</html>