From dabenavidesd at yahoo.es  Fri Aug  1 00:43:07 2008
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Thu, 31 Jul 2008 22:43:07 +0000 (GMT)
Subject: [M3devel] need help with cm3 problem before I deliver software
	this week
In-Reply-To: <4891A737.1E75.00D7.1@scires.com>
Message-ID: <537778.13498.qm@web27107.mail.ukl.yahoo.com>

Hi all:
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.
Thanks

--- El jue, 31/7/08, Randy Coleburn <rcoleburn at scires.com> escribi?:
De: Randy Coleburn <rcoleburn at scires.com>
Asunto: Re: [M3devel] need help with cm3 problem before I deliver software this week
Para: "Rodney M. Bates" <rodney.bates at wichita.edu>
CC: m3devel at elegosoft.com
Fecha: jueves, 31 julio, 2008 10:51


 
Rodney:
?
I am using Windows XP Professional, Service Pack 2 (on some systems, Service Pack 3 is applied).
?
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?
?
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.
?
Regards,
Randy

>>> "Rodney M. Bates" <rodney.bates at wichita.edu> 7/31/2008 9:33 AM >>>
Which variant of the M3 Windows target are you using?? I don't have any
of them built right now.

Randy Coleburn wrote:
> Hi Olaf, Daniel, Rodney, et al:
>? 
> Thanks for your responses so far.? Sorry for the delay in replying, but 
> our email server has been offline for nearly 24-hours.? There were some 
> severe electrical storms that took down both redundant power systems for 
> our email system.? Hope I have not missed any of your replies.
>? 
> Right now, I am delivering the software on Windows XP using SP2 or 
> greater.? I have not tried to see if this problem also occurs on Unix.? 
> I don't have ready access to a unix system from my current location.
>? 
> So it is perhaps a Windows-only problem with Trestle/FormsVBT.? In any 
> event, it is a real problem for me.
>? 
> As for the pixmap stretching problem, I have tested various resolutions 
> on the customer's computer.? Unfortunately, the customer demands that 
> the display resolution stay at the 1920x1200.
> 1920x1200=pixmap stretch problem
> 1680x1050=pixmap stretch problem
> 1440x900=no problem
> 1024x768=no problem
>? 
> Regards,
> Randy
> 
>? >>> Olaf Wagner <wagner at elegosoft.com> 7/30/2008 2:24 AM >>>
> Quoting Randy Coleburn <rcoleburn at scires.com>:
> 
>? > Hi:
>? >
>? > 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.
>? >
>? > This problem is easily reproduced using the "formsedit" program.
>? >
>? > The problem is with the TypeIn and TypeScript FormsVBT elements used 
>? >? in my program.? Since formsedit uses these, you can easily 
>? > reproduce? the problem.
>? >
>? > 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.
> 
> Randy,
> 
> I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't able
> to reproduce the problem on FreeBSD 6.3.
> 
> Does the problem show up on all platforms you are working on?
> Which are these?
> 
> Are there any local modifications to the libraries which I may not
> have?
> 
> If it occurs only on Unix, it may be possible that a weird window
> manager interferes with the event delivery; otherwise I've got no
> good idea. If on Unix, you/we could perhaps test the behaviour
> on a different (remote) X display?
> 
> Please provide more data about the problem context and how to
> reproduce it.
> 
> Regards,
> 
> Olaf
> 
>? > 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).
>? >
>? > 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#.
>? >
>? > 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.
>? >
>? > Regards,
>? > Randy Coleburn
>? > Senior Systems Engineer
>? > Scientific Research Corporation
>? >
> 
> 
> 
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>???????????????? Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96? mobile: +49 177 2345 869? fax: +49 30 23 45 86 95
>???? http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 
> 

-- 
-------------------------------------------------------------
Rodney M. Bates, retired assistant professor
Dept. of Computer Science, Wichita State University
Wichita, KS 67260-0083
316-978-3922
rodney.bates at wichita.edu




      ______________________________________________ 
Enviado desde Correo Yahoo! La bandeja de entrada m?s inteligente.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080731/87ed8ad9/attachment.html>

From jayk123 at hotmail.com  Fri Aug  1 00:52:51 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 31 Jul 2008 22:52:51 +0000
Subject: [M3devel] need help with cm3 problem before I
	deliver	software	this	week
In-Reply-To: <4891A737.1E75.00D7.1@scires.com>
References: <488F4292.1E75.00D7.1@scires.com>
	<20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com>
	<4890EB9C.1E75.00D7.1@scires.com> <4891BF18.8000905@wichita.edu> 
	<4891A737.1E75.00D7.1@scires.com>
Message-ID: <COL101-W53603D6A9F25219F7DF8C2E67C0@phx.gbl>


You reminded me -- there is something in the code about double reporting of characters and ignoring the first one.
It is, like the main/environment stuff, one of those suspicious changes that crept in  -- a change with a comment indicating the changer didn't know what is going on, and overridable with environment variable/command line switch. But I had less luck resolving this than with main/environment.
Does it repro with 4.1? Or 3.6?
I haven't tried yet but will shortly.
Been on gcc related tangents since I got a sparc/Solaris machine, sorry.
 
 - Jay



Date: Thu, 31 Jul 2008 11:51:28 -0400From: rcoleburn at scires.comTo: rodney.bates at wichita.eduCC: m3devel at elegosoft.comSubject: Re: [M3devel] need help with cm3 problem before I deliver software this week

Rodney:
 
I am using Windows XP Professional, Service Pack 2 (on some systems, Service Pack 3 is applied).
 
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?
 
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.
 
Regards,
Randy>>> "Rodney M. Bates" <rodney.bates at wichita.edu> 7/31/2008 9:33 AM >>>Which variant of the M3 Windows target are you using?  I don't have anyof them built right now.Randy Coleburn wrote:> Hi Olaf, Daniel, Rodney, et al:>  > Thanks for your responses so far.  Sorry for the delay in replying, but > our email server has been offline for nearly 24-hours.  There were some > severe electrical storms that took down both redundant power systems for > our email system.  Hope I have not missed any of your replies.>  > Right now, I am delivering the software on Windows XP using SP2 or > greater.  I have not tried to see if this problem also occurs on Unix.  > I don't have ready access to a unix system from my current location.>  > So it is perhaps a Windows-only problem with Trestle/FormsVBT.  In any > event, it is a real problem for me.>  > As for the pixmap stretching problem, I have tested various resolutions > on the customer's computer.  Unfortunately, the customer demands that > the display resolution stay at the 1920x1200.> 1920x1200=pixmap stretch problem> 1680x1050=pixmap stretch problem> 1440x900=no problem> 1024x768=no problem>  > Regards,> Randy> >  >>> Olaf Wagner <wagner at elegosoft.com> 7/30/2008 2:24 AM >>>> Quoting Randy Coleburn <rcoleburn at scires.com>:> >  > Hi:>  >>  > 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.>  >>  > This problem is easily reproduced using the "formsedit" program.>  >>  > The problem is with the TypeIn and TypeScript FormsVBT elements used >  >  in my program.  Since formsedit uses these, you can easily >  > reproduce  the problem.>  >>  > 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.> > Randy,> > I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't able> to reproduce the problem on FreeBSD 6.3.> > Does the problem show up on all platforms you are working on?> Which are these?> > Are there any local modifications to the libraries which I may not> have?> > If it occurs only on Unix, it may be possible that a weird window> manager interferes with the event delivery; otherwise I've got no> good idea. If on Unix, you/we could perhaps test the behaviour> on a different (remote) X display?> > Please provide more data about the problem context and how to> reproduce it.> > Regards,> > Olaf> >  > 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).>  >>  > 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#.>  >>  > 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.>  >>  > Regards,>  > Randy Coleburn>  > Senior Systems Engineer>  > Scientific Research Corporation>  >> > > > -- > Olaf Wagner -- elego Software Solutions GmbH>                 Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95>     http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> > -- -------------------------------------------------------------Rodney M. Bates, retired assistant professorDept. of Computer Science, Wichita State UniversityWichita, KS 67260-0083316-978-3922rodney.bates at wichita.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080731/3ccb6074/attachment.html>

From dabenavidesd at yahoo.es  Fri Aug  1 01:16:05 2008
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Thu, 31 Jul 2008 23:16:05 +0000 (GMT)
Subject: [M3devel] need help with cm3 problem before I deliver software
	this week
In-Reply-To: <537778.13498.qm@web27107.mail.ukl.yahoo.com>
Message-ID: <464840.85424.qm@web27104.mail.ukl.yahoo.com>

Hi all:
They are @M3TraceWinMsgs and @M3SlowTrace
I get it in the file m3-ui/ui/src/winvbt/WinTrestle.m3
lines 1096, 1097
? trace_msgs := RTParams.IsPresent ("TraceWinMsgs");
? slow_trace := RTParams.IsPresent ("SlowTrace");
Thanks


--- El jue, 31/7/08, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:
De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] need help with cm3 problem before I deliver software this week
Para: "Rodney M. Bates" <rodney.bates at wichita.edu>, "Randy Coleburn" <rcoleburn at scires.com>
CC: m3devel at elegosoft.com
Fecha: jueves, 31 julio, 2008 5:43

Hi all:
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.
Thanks

--- El jue, 31/7/08, Randy Coleburn <rcoleburn at scires.com> escribi?:
De: Randy Coleburn <rcoleburn at scires.com>
Asunto: Re: [M3devel] need help with cm3 problem before I deliver software this
week
Para: "Rodney M. Bates" <rodney.bates at wichita.edu>
CC: m3devel at elegosoft.com
Fecha: jueves, 31 julio, 2008 10:51


 
Rodney:
?
I am using Windows XP Professional, Service Pack 2 (on some systems, Service
Pack 3 is applied).
?
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?
?
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.
?
Regards,
Randy

>>> "Rodney M. Bates" <rodney.bates at wichita.edu>
7/31/2008 9:33 AM >>>
Which variant of the M3 Windows target are you using?? I don't have any
of them built right now.

Randy Coleburn wrote:
> Hi Olaf, Daniel, Rodney, et al:
>? 
> Thanks for your responses so far.? Sorry for the delay in replying, but 
> our email server has been offline for nearly 24-hours.? There were some 
> severe electrical storms that took down both redundant power systems for 
> our email system.? Hope I have not missed any of your replies.
>? 
> Right now, I am delivering the software on Windows XP using SP2 or 
> greater.? I have not tried to see if this problem also occurs on Unix.? 
> I don't have ready access to a unix system from my current location.
>? 
> So it is perhaps a Windows-only problem with Trestle/FormsVBT.? In any 
> event, it is a real problem for me.
>? 
> As for the pixmap stretching problem, I have tested various resolutions 
> on the customer's computer.? Unfortunately, the customer demands that

> the display resolution stay at the 1920x1200.
> 1920x1200=pixmap stretch problem
> 1680x1050=pixmap stretch problem
> 1440x900=no problem
> 1024x768=no problem
>? 
> Regards,
> Randy
> 
>? >>> Olaf Wagner <wagner at elegosoft.com> 7/30/2008 2:24 AM
>>>
> Quoting Randy Coleburn <rcoleburn at scires.com>:
> 
>? > Hi:
>? >
>? > 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.
>? >
>? > This problem is easily reproduced using the "formsedit"
program.
>? >
>? > The problem is with the TypeIn and TypeScript FormsVBT elements
used 
>? >? in my program.? Since formsedit uses these, you can easily 
>? > reproduce? the problem.
>? >
>? > 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.
> 
> Randy,
> 
> I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't able
> to reproduce the problem on FreeBSD 6.3.
> 
> Does the problem show up on all platforms you are working on?
> Which are these?
> 
> Are there any local modifications to the libraries which I may not
> have?
> 
> If it occurs only on Unix, it may be possible that a weird window
> manager interferes with the event delivery; otherwise I've got no
> good idea. If on Unix, you/we could perhaps test the behaviour
> on a different (remote) X display?
> 
> Please provide more data about the problem context and how to
> reproduce it.
> 
> Regards,
> 
> Olaf
> 
>? > 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).
>? >
>? > 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#


      ?No te gusta tu direcci?n de correo?
Consigue una que te guste de verdad - millones de direcciones de correo disponibles en Yahoo!
http://es.docs.yahoo.com/mail/nueva_direccion.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080731/3ff8953c/attachment.html>

From jayk123 at hotmail.com  Fri Aug  1 02:23:43 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 1 Aug 2008 00:23:43 +0000
Subject: [M3devel] need help with cm3 problem before I deliver
	software	this week
In-Reply-To: <464840.85424.qm@web27104.mail.ukl.yahoo.com>
References: <537778.13498.qm@web27107.mail.ukl.yahoo.com>
	<464840.85424.qm@web27104.mail.ukl.yahoo.com>
Message-ID: <COL101-W37FB9AE76D233A727F58D1E67F0@phx.gbl>


Try this also:
 
d:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinTrestle.m3
 
(*-------------------------------------------------------- initialization ---*)
VAR  useEvent_WM_CHAR := FALSE;BEGIN  WITH v = Env.Get("USE_EVENT_WM_CHAR") DO    IF v # NIL THEN      useEvent_WM_CHAR := Text.Length(v) = 0 OR                          Text.GetChar(v, 0) = '1' OR                          Text.GetChar(v, 0) = 'y' OR                          Text.GetChar(v, 0) = 'Y';    END;  END;  CreateTrestle ();END WinTrestle. set USE_EVENT_WM_CHAR=1
 or 
 set USE_EVENT_WM_CHAR=Yucky! 
 
(I think it should check for "y", or "yes", case insensitive, not just any string that starts with "y".., or only allow 0 or 1, and error for anything else, and put M3 or CM3 at the front of the variable to not clash with other uses...)
 
Though, granted, I am just totally guessing right now.
 
   - Jay



Date: Thu, 31 Jul 2008 23:16:05 +0000From: dabenavidesd at yahoo.esTo: rodney.bates at wichita.edu; rcoleburn at scires.comCC: m3devel at elegosoft.comSubject: Re: [M3devel] need help with cm3 problem before I deliver software this week



Hi all:They are @M3TraceWinMsgs and @M3SlowTraceI get it in the file m3-ui/ui/src/winvbt/WinTrestle.m3lines 1096, 1097  trace_msgs := RTParams.IsPresent ("TraceWinMsgs");  slow_trace := RTParams.IsPresent ("SlowTrace");Thanks--- El jue, 31/7/08, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:
De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>Asunto: Re: [M3devel] need help with cm3 problem before I deliver software this weekPara: "Rodney M. Bates" <rodney.bates at wichita.edu>, "Randy Coleburn" <rcoleburn at scires.com>CC: m3devel at elegosoft.comFecha: jueves, 31 julio, 2008 5:43Hi all:I think I remember somewhere there are runtime
 parameters for debugging Trestleon windows implementation. Check the source code of it; I can't find them inthis moment.Thanks--- El jue, 31/7/08, Randy Coleburn <rcoleburn at scires.com> escribi?:De: Randy Coleburn <rcoleburn at scires.com>Asunto: Re: [M3devel] need help with cm3 problem before I deliver software thisweekPara: "Rodney M. Bates" <rodney.bates at wichita.edu>CC: m3devel at elegosoft.comFecha: jueves, 31 julio, 2008 10:51 Rodney: I am using Windows XP Professional, Service Pack 2 (on some systems, ServicePack 3 is applied). Michel Dagenais suggested that if the problem does not reproduce on Linux, thatit might have to do with how Windows reports character events.  He thought aFilter VBT may exist somewhere that would aid in debugging by printing methodcalls before propagating them to father/son.  This filter VBT would be
 insertedat different places in the VBT tree to get tracing information.  Are youfamiliar with something like this? As for the pixmaps, Michel suggests increasing the resolution of the originalpixmap to help alleviate problems with upscaling.  I may try this, but ofcourse, FormsVBT uses a lot of pixmap resources, for example, radio, boolean,checkmark, numeric, etc all use pixmaps. Regards,Randy>>> "Rodney M. Bates" <rodney.bates at wichita.edu>7/31/2008 9:33 AM >>>Which variant of the M3 Windows target are you using?  I don't have anyof them built right now.Randy Coleburn wrote:> Hi Olaf, Daniel, Rodney, et al:>  > Thanks for your responses so far.  Sorry for the delay in replying, but > our email server has been offline for nearly 24-hours.  There were some > severe electrical storms that
 took down both redundant power systems for > our email system.  Hope I have not missed any of your replies.>  > Right now, I am delivering the software on Windows XP using SP2 or > greater.  I have not tried to see if this problem also occurs on Unix.  > I don't have ready access to a unix system from my current location.>  > So it is perhaps a Windows-only problem with Trestle/FormsVBT.  In any > event, it is a real problem for me.>  > As for the pixmap stretching problem, I have tested various resolutions > on the customer's computer.  Unfortunately, the customer demands that> the display resolution stay at the 1920x1200.> 1920x1200=pixmap stretch problem> 1680x1050=pixmap stretch problem> 1440x900=no problem> 1024x768=no problem>  > Regards,> Randy> > 
 >>> Olaf Wagner <wagner at elegosoft.com> 7/30/2008 2:24 AM>>>> Quoting Randy Coleburn <rcoleburn at scires.com>:> >  > Hi:>  >>  > I've been using cm3 to develop software I am delivering thisweek to >  >  a customer.  During the acceptance testing, we've run into a>  > problem  that I have not been able to solve.  I am hoping someonein >  > the cm3  community can help.  I need to solve this problem ASAPthis >  > week.>  >>  > This problem is easily reproduced using the "formsedit"program.>  >>  > The problem is with the TypeIn and TypeScript FormsVBT elementsused >  >  in my program.  Since formsedit uses these, you can easily >  > reproduce  the
 problem.>  >>  > Click with the mouse to move the insertion point somewhere in the >  > text.  Observe that the cursor moves to that point.  Now, usethe  >  > left arrow key to move the insertion point a few characters tothe  >  > left.  Then, type a few characters.  Observe that the first  >  > character you type shows up at the place where you initiallymoved  >  > the cursor with the mouse, while the remaining characters show upat >  >  the place where you moved the cursor via the left-arrow key. This  >  > behavior is wrong.  The first character you type should be atthe  >  > current insertion point, not at the one from the mouse move.> > Randy,> > I just rebuilt the CM3 GUI
 libraries and formsedit, but I wasn't able> to reproduce the problem on FreeBSD 6.3.> > Does the problem show up on all platforms you are working on?> Which are these?> > Are there any local modifications to the libraries which I may not> have?> > If it occurs only on Unix, it may be possible that a weird window> manager interferes with the event delivery; otherwise I've got no> good idea. If on Unix, you/we could perhaps test the behaviour> on a different (remote) X display?> > Please provide more data about the problem context and how to> reproduce it.> > Regards,> > Olaf> >  > I'm sure the fix is easy, but I haven't been able to locateit yet.  >  >  It probably has to do with the internal idea of the insertionpoint >  >  not getting updated
 properly.  Note that the cursor on thescreen >  > 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).>  >>  > Any assistance you can provide is very much appreciated and willgo  >  > a long way toward keeping Modula-3 use alive and well for this  >  > project.  If we can't fix this one, the customers will wantto  >  > re-code everything in some Microsoft language, probably C++ or C#

Enviado desde Correo Yahoo!La bandeja de entrada m?s inteligente.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/3e9294c6/attachment.html>

From rcoleburn at scires.com  Fri Aug  1 06:28:25 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Fri, 01 Aug 2008 00:28:25 -0400
Subject: [M3devel] need help with cm3 problem before I
	deliver	software	this week
In-Reply-To: <COL101-W37FB9AE76D233A727F58D1E67F0@phx.gbl>
References: <537778.13498.qm@web27107.mail.ukl.yahoo.com>
	<464840.85424.qm@web27104.mail.ukl.yahoo.com>
	<COL101-W37FB9AE76D233A727F58D1E67F0@phx.gbl>
Message-ID: <489258A0.1E75.00D7.1@scires.com>

Jay:
 
I tried "set USE_EVENT_WM_CHAR=1"
 
The result is that I get two or more characters on the screen for each
single character typed.
 
Regards,
Randy

>>> Jay <jayk123 at hotmail.com> 7/31/2008 8:23 PM >>>
Try this also:
 
d:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinTrestle.m3
 
(*--------------------------------------------------------
initialization ---*)
VAR
  useEvent_WM_CHAR := FALSE;
BEGIN
  WITH v = Env.Get("USE_EVENT_WM_CHAR") DO
    IF v # NIL THEN
      useEvent_WM_CHAR := Text.Length(v) = 0 OR
                          Text.GetChar(v, 0) = '1' OR
                          Text.GetChar(v, 0) = 'y' OR
                          Text.GetChar(v, 0) = 'Y';
    END;
  END;
  CreateTrestle ();
END WinTrestle.


 set USE_EVENT_WM_CHAR=1
 or 
 set USE_EVENT_WM_CHAR=Yucky! 
 
(I think it should check for "y", or "yes", case insensitive, not just
any string that starts with "y".., or only allow 0 or 1, and error for
anything else, and put M3 or CM3 at the front of the variable to not
clash with other uses...)
 
Though, granted, I am just totally guessing right now.
 
   - Jay


Date: Thu, 31 Jul 2008 23:16:05 +0000
From: dabenavidesd at yahoo.es 
To: rodney.bates at wichita.edu; rcoleburn at scires.com 
CC: m3devel at elegosoft.com 
Subject: Re: [M3devel] need help with cm3 problem before I deliver
software this week



Hi all:
They are @M3TraceWinMsgs and @M3SlowTrace
I get it in the file m3-ui/ui/src/winvbt/WinTrestle.m3
lines 1096, 1097
  trace_msgs := RTParams.IsPresent ("TraceWinMsgs");
  slow_trace := RTParams.IsPresent ("SlowTrace");
Thanks


--- El jue, 31/7/08, Daniel Alejandro Benavides D.
<dabenavidesd at yahoo.es> escribi?:


De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] need help with cm3 problem before I deliver
software this week
Para: "Rodney M. Bates" <rodney.bates at wichita.edu>, "Randy Coleburn"
<rcoleburn at scires.com>
CC: m3devel at elegosoft.com 
Fecha: jueves, 31 julio, 2008 5:43

Hi all:
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.
Thanks

--- El jue, 31/7/08, Randy Coleburn <rcoleburn at scires.com> escribi?:
De: Randy Coleburn <rcoleburn at scires.com>
Asunto: Re: [M3devel] need help with cm3 problem before I deliver
software this
week
Para: "Rodney M. Bates" <rodney.bates at wichita.edu>
CC: m3devel at elegosoft.com 
Fecha: jueves, 31 julio, 2008 10:51



Rodney:
 
I am using Windows XP Professional, Service Pack 2 (on some systems,
Service
Pack 3 is applied).
 
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?
 
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.
 
Regards,
Randy

>>> "Rodney M. Bates" <rodney.bates at wichita.edu>
7/31/2008 9:33 AM >>>
Which variant of the M3 Windows target are you using?  I don't have
any
of them built right now.

Randy Coleburn wrote:
> Hi Olaf, Daniel, Rodney, et al:
>  
> Thanks for your responses so far.  Sorry for the delay in replying,
but 
> our email server has been offline for nearly 24-hours.  There were
some 
> severe electrical storms that took down both redundant power systems
for 
> our email system.  Hope I have not missed any of your replies.
>  
> Right now, I am delivering the software on Windows XP using SP2 or 
> greater.  I have not tried to see if this problem also occurs on
Unix.  
> I don't have ready access to a unix system from my current location.
>  
> So it is perhaps a Windows-only problem with Trestle/FormsVBT.  In
any 
> event, it is a real problem for me.
>  
> As for the pixmap stretching problem, I have tested various
resolutions 
> on the customer's computer.  Unfortunately, the customer demands
that

> the display resolution stay at the 1920x1200.
> 1920x1200=pixmap stretch problem
> 1680x1050=pixmap stretch problem
> 1440x900=no problem
> 1024x768=no problem
>  
> Regards,
> Randy
> 
>  >>> Olaf Wagner <wagner at elegosoft.com> 7/30/2008 2:24 AM
>>>
> Quoting Randy Coleburn <rcoleburn at scires.com>:
> 
>  > Hi:
>  >
>  > 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.
>  >
>  > This problem is easily reproduced using the "formsedit"
program.
>  >
>  > The problem is with the TypeIn and TypeScript FormsVBT elements
used 
>  >  in my program.  Since formsedit uses these, you can easily 
>  > reproduce  the problem.
>  >
>  > 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.
> 
> Randy,
> 
> I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't
able
> to reproduce the problem on FreeBSD 6.3.
> 
> Does the problem show up on all platforms you are working on?
> Which are these?
> 
> Are there any local modifications to the libraries which I may not
> have?
> 
> If it occurs only on Unix, it may be possible that a weird window
> manager interferes with the event delivery; otherwise I've got no
> good idea. If on Unix, you/we could perhaps test the behaviour
> on a different (remote) X display?
> 
> Please provide more data about the problem context and how to
> reproduce it.
> 
> Regards,
> 
> Olaf
> 
>  > 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).
>  >
>  > 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#


Enviado desde Correo Yahoo! (
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
)
La bandeja de entrada m?s inteligente.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/03efd605/attachment.html>

From rcoleburn at scires.com  Fri Aug  1 06:44:38 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Fri, 01 Aug 2008 00:44:38 -0400
Subject: [M3devel] need help with cm3 problem before I deliver	software
	this week
In-Reply-To: <464840.85424.qm@web27104.mail.ukl.yahoo.com>
References: <537778.13498.qm@web27107.mail.ukl.yahoo.com>
	<464840.85424.qm@web27104.mail.ukl.yahoo.com>
Message-ID: <48925C6D.1E75.00D7.1@scires.com>

Daniel:
 
I tried @M3SlowTrace, but it does not seem to produce any output.
 
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:

msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
msg 132 = WM_NCHITTEST
msg 32 = WM_SETCURSOR
msg 513 = WM_LBUTTONDOWN
msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
msg 514 = WM_LBUTTONUP
 | msg 132 = WM_NCHITTEST
 | msg 533 = ???
msg 514 = WM_LBUTTONUP
msg 132 = WM_NCHITTEST
msg 32 = WM_SETCURSOR
msg 512 = WM_MOUSEMOVE (aka WM_MOUSEFIRST)
msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
msg 256 = WM_KEYDOWN (aka WM_KEYFIRST)
msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
msg 257 = WM_KEYUP
msg 1033 = PAINTBATCH_VBT
msg 256 = WM_KEYDOWN (aka WM_KEYFIRST)
msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
msg 257 = WM_KEYUP
msg 1033 = PAINTBATCH_VBT
msg 256 = WM_KEYDOWN (aka WM_KEYFIRST)
msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
msg 257 = WM_KEYUP
msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
msg 256 = WM_KEYDOWN (aka WM_KEYFIRST)
msg 258 = WM_CHAR
msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
msg 257 = WM_KEYUP
msg 1033 = PAINTBATCH_VBT
msg 256 = WM_KEYDOWN (aka WM_KEYFIRST)
msg 258 = WM_CHAR
msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
msg 257 = WM_KEYUP
msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
 
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.
 
Do these messages help?  It is interesting to note that one of the
messages (#533) is identified as "???"
 
Regards,
Randy

>>> "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> 7/31/2008
7:16 PM >>>

Hi all:
They are @M3TraceWinMsgs and @M3SlowTrace
I get it in the file m3-ui/ui/src/winvbt/WinTrestle.m3
lines 1096, 1097
  trace_msgs := RTParams.IsPresent ("TraceWinMsgs");
  slow_trace := RTParams.IsPresent ("SlowTrace");
Thanks


--- El jue, 31/7/08, Daniel Alejandro Benavides D.
<dabenavidesd at yahoo.es> escribi?:


De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] need help with cm3 problem before I deliver
software this week
Para: "Rodney M. Bates" <rodney.bates at wichita.edu>, "Randy Coleburn"
<rcoleburn at scires.com>
CC: m3devel at elegosoft.com 
Fecha: jueves, 31 julio, 2008 5:43

Hi all:
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.
Thanks

--- El jue, 31/7/08, Randy Coleburn <rcoleburn at scires.com> escribi?:
De: Randy Coleburn <rcoleburn at scires.com>
Asunto: Re: [M3devel] need help with cm3 problem before I deliver
software this
week
Para: "Rodney M. Bates" <rodney.bates at wichita.edu>
CC: m3devel at elegosoft.com 
Fecha: jueves, 31 julio, 2008 10:51



Rodney:
 
I am using Windows XP Professional, Service Pack 2 (on some systems,
Service
Pack 3 is applied).
 
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?
 
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.
 
Regards,
Randy

>>> "Rodney M. Bates" <rodney.bates at wichita.edu>
7/31/2008 9:33 AM >>>
Which variant of the M3 Windows target are you using?  I don't have
any
of them built right now.

Randy Coleburn wrote:
> Hi Olaf, Daniel, Rodney, et al:
>  
> Thanks for your responses so far.  Sorry for the delay in replying,
but 
> our email server has been offline for nearly 24-hours.  There were
some 
> severe electrical storms that took down both redundant power systems
for 
> our email system.  Hope I have not missed any of your replies.
>  
> Right now, I am delivering the software on Windows XP using SP2 or 
> greater.  I have not tried to see if this problem also occurs on
Unix.  
> I don't have ready access to a unix system from my current location.
>  
> So it is perhaps a Windows-only problem with Trestle/FormsVBT.  In
any 
> event, it is a real problem for me.
>  
> As for the pixmap stretching problem, I have tested various
resolutions 
> on the customer's computer.  Unfortunately, the customer demands
that

> the display resolution stay at the 1920x1200.
> 1920x1200=pixmap stretch problem
> 1680x1050=pixmap stretch problem
> 1440x900=no problem
> 1024x768=no problem
>  
> Regards,
> Randy
> 
>  >>> Olaf Wagner <wagner at elegosoft.com> 7/30/2008 2:24 AM
>>>
> Quoting Randy Coleburn <rcoleburn at scires.com>:
> 
>  > Hi:
>  >
>  > 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.
>  >
>  > This problem is easily reproduced using the "formsedit"
program.
>  >
>  > The problem is with the TypeIn and TypeScript FormsVBT elements
used 
>  >  in my program.  Since formsedit uses these, you can easily 
>  > reproduce  the problem.
>  >
>  > 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.
> 
> Randy,
> 
> I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't
able
> to reproduce the problem on FreeBSD 6.3.
> 
> Does the problem show up on all platforms you are working on?
> Which are these?
> 
> Are there any local modifications to the libraries which I may not
> have?
> 
> If it occurs only on Unix, it may be possible that a weird window
> manager interferes with the event delivery; otherwise I've got no
> good idea. If on Unix, you/we could perhaps test the behaviour
> on a different (remote) X display?
> 
> Please provide more data about the problem context and how to
> reproduce it.
> 
> Regards,
> 
> Olaf
> 
>  > 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).
>  >
>  > 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#


Enviado desde Correo Yahoo! (
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
)
La bandeja de entrada m?s inteligente.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/df3dc33a/attachment.html>

From rcoleburn at scires.com  Fri Aug  1 07:00:24 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Fri, 01 Aug 2008 01:00:24 -0400
Subject: [M3devel] need help with cm3 problem before I
	deliver	software	this week
In-Reply-To: <20080731184449.su7qkp9x6ocwkoo0@mail.elegosoft.com>
References: <488F4292.1E75.00D7.1@scires.com>
	<20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com>
	<4890EB9C.1E75.00D7.1@scires.com> <4891BF18.8000905@wichita.edu>
	<4891A737.1E75.00D7.1@scires.com>
	<20080731184449.su7qkp9x6ocwkoo0@mail.elegosoft.com>
Message-ID: <4892601C.1E75.00D7.1@scires.com>

Olaf:
 
The problem reproduces every time on my system.  I've tried it on three
different XP computers with same results every time.
 
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.
 
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.
 
Regards,
Randy

>>> Olaf Wagner <wagner at elegosoft.com> 7/31/2008 12:44 PM >>>
Quoting Randy Coleburn <rcoleburn at scires.com>:

> Rodney:
>
> I am using Windows XP Professional, Service Pack 2 (on some systems,
> Service Pack 3 is applied).

Hi Randy,

I just tried formsedit on exactly this system (XP professional, SP2)
in my virtual machine, and wasn't able to see any fault wrt. cursor
processing and typing, too. I checked-out and compiled all the latest
sources of the relevant gui packages (ui, vbtkit, formsvbt etc.), but
that didn't make any difference (though some changes had been
applied).
For me it just seems to work correctly. It may be of interest though
that some months ago when I was last working on this system for the
regression tests, I applied all existing Microsoft patches; but you've
done that probably, too.

I've got no idea about the pixmap problem, too.
As long as nobody else is able to reproduce the problem it will
remain difficult to analyze this problem.

Sorry that I cannot be of more help,

Olaf

PS: Are you sure that you are really using exactly the current CM3 gui
libraries, and not some adapted or modified stuff from an older
release?

> 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?
>
> 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.
>
> Regards,
> Randy
>
>>>> "Rodney M. Bates" <rodney.bates at wichita.edu> 7/31/2008 9:33 AM
>>>
> Which variant of the M3 Windows target are you using?  I don't have
> any
> of them built right now.
>
> Randy Coleburn wrote:
>> Hi Olaf, Daniel, Rodney, et al:
>>
>> Thanks for your responses so far.  Sorry for the delay in replying,
> but
>> our email server has been offline for nearly 24-hours.  There were
> some
>> severe electrical storms that took down both redundant power
systems
> for
>> our email system.  Hope I have not missed any of your replies.
>>
>> Right now, I am delivering the software on Windows XP using SP2 or
>> greater.  I have not tried to see if this problem also occurs on
> Unix.
>> I don't have ready access to a unix system from my current
location.
>>
>> So it is perhaps a Windows-only problem with Trestle/FormsVBT.  In
> any
>> event, it is a real problem for me.
>>
>> As for the pixmap stretching problem, I have tested various
> resolutions
>> on the customer's computer.  Unfortunately, the customer demands
that
>
>> the display resolution stay at the 1920x1200.
>> 1920x1200=pixmap stretch problem
>> 1680x1050=pixmap stretch problem
>> 1440x900=no problem
>> 1024x768=no problem
>>
>> Regards,
>> Randy
>>
>>  >>> Olaf Wagner <wagner at elegosoft.com> 7/30/2008 2:24 AM >>>
>> Quoting Randy Coleburn <rcoleburn at scires.com>:
>>
>>  > Hi:
>>  >
>>  > 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.
>>  >
>>  > This problem is easily reproduced using the "formsedit" program.
>>  >
>>  > The problem is with the TypeIn and TypeScript FormsVBT elements
> used
>>  >  in my program.  Since formsedit uses these, you can easily
>>  > reproduce  the problem.
>>  >
>>  > 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.
>>
>> Randy,
>>
>> I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't
> able
>> to reproduce the problem on FreeBSD 6.3.
>>
>> Does the problem show up on all platforms you are working on?
>> Which are these?
>>
>> Are there any local modifications to the libraries which I may not
>> have?
>>
>> If it occurs only on Unix, it may be possible that a weird window
>> manager interferes with the event delivery; otherwise I've got no
>> good idea. If on Unix, you/we could perhaps test the behaviour
>> on a different (remote) X display?
>>
>> Please provide more data about the problem context and how to
>> reproduce it.
>>
>> Regards,
>>
>> Olaf
>>
>>  > 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).
>>  >
>>  > 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#.
>>  >
>>  > 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.
>>  >
>>  > Regards,
>>  > Randy Coleburn
>>  > Senior Systems Engineer
>>  > Scientific Research Corporation
>>  >
>>
>>
>>
>> --
>> Olaf Wagner -- elego Software Solutions GmbH
>>                 Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin,
> Germany
>> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23
> 45 86 95
>>     http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz:
> Berlin
>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:
> DE163214194
>>
>>
>
> --
> -------------------------------------------------------------
> Rodney M. Bates, retired assistant professor
> Dept. of Computer Science, Wichita State University
> Wichita, KS 67260-0083
> 316-978-3922
> rodney.bates at wichita.edu 
>
>



-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin,
Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45
86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz:
Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:
DE163214194


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/32d067b8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: formsedit.exe.gz
Type: application/x-gzip
Size: 747981 bytes
Desc: not available
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/32d067b8/attachment.bin>

From jayk123 at hotmail.com  Fri Aug  1 10:43:31 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 1 Aug 2008 08:43:31 +0000
Subject: [M3devel] need help with cm3 problem before I deliver
	software	this week
In-Reply-To: <537778.13498.qm@web27107.mail.ukl.yahoo.com>
References: <4891A737.1E75.00D7.1@scires.com>
	<537778.13498.qm@web27107.mail.ukl.yahoo.com>
Message-ID: <COL101-W47C793FC4B3AB08006FD9DE67F0@phx.gbl>


I can reproduce the problem. Exactly as well reported.
It kind of only happens once. Bring up formsedit, click, left arrow(s), type, it does what Randy said.
Click again, arrows again, type again, not a second time. Good enough though.
Close formsedit, reopen, it repros. Good.
file.save, type backslash or forward slash in the dialog, press return, and boom:
Most other strings are ok, but a single forward or backward slash, booms.
 
****** runtime error:***    An enumeration or subrange value was out of range.***    file "..\src\os\WIN32\FSWin32.m3", line 435***
Stack trace:   FP         PC      Procedure---------  ---------  -------------------------------0x67afccc   0x42524f  BuildStatus + 0x21 in ..\src\os\WIN32\FSWin32.m30x67afe60   0x4251dc  Status + 0x137 in ..\src\os\WIN32\FSWin32.m30x67aff50   0xd9d131  DoStats + 0x253 in ..\src\lego\FileBrowserVBT.m30x67aff88   0x53a6ca  RunThread + 0x1f6 in ..\src\thread\WIN32\ThreadWin32.m30x67affb4   0x53a463  ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3.........  .........  ... more frames ...
 
bugs...
 
 
And is that red line supposed to appear in the gui?
 
 - Jay> Date: Thu, 31 Jul 2008 22:43:07 +0000> From: dabenavidesd at yahoo.es> To: rodney.bates at wichita.edu; rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] need help with cm3 problem before I deliver software this week> > Hi all:> 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.> Thanks> > --- El jue, 31/7/08, Randy Coleburn <rcoleburn at scires.com> escribi?:> De: Randy Coleburn <rcoleburn at scires.com>> Asunto: Re: [M3devel] need help with cm3 problem before I deliver software this week> Para: "Rodney M. Bates" <rodney.bates at wichita.edu>> CC: m3devel at elegosoft.com> Fecha: jueves, 31 julio, 2008 10:51> > > > Rodney:>  > I am using Windows XP Professional, Service Pack 2 (on some systems, Service Pack 3 is applied).>  > 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?>  > 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.>  > Regards,> Randy> > >>> "Rodney M. Bates" <rodney.bates at wichita.edu> 7/31/2008 9:33 AM >>>> Which variant of the M3 Windows target are you using?  I don't have any> of them built right now.> > Randy Coleburn wrote:> > Hi Olaf, Daniel, Rodney, et al:> >  > > Thanks for your responses so far.  Sorry for the delay in replying, but > > our email server has been offline for nearly 24-hours.  There were some > > severe electrical storms that took down both redundant power systems for > > our email system.  Hope I have not missed any of your replies.> >  > > Right now, I am delivering the software on Windows XP using SP2 or > > greater.  I have not tried to see if this problem also occurs on Unix.  > > I don't have ready access to a unix system from my current location.> >  > > So it is perhaps a Windows-only problem with Trestle/FormsVBT.  In any > > event, it is a real problem for me.> >  > > As for the pixmap stretching problem, I have tested various resolutions > > on the customer's computer.  Unfortunately, the customer demands that > > the display resolution stay at the 1920x1200.> > 1920x1200=pixmap stretch problem> > 1680x1050=pixmap stretch problem> > 1440x900=no problem> > 1024x768=no problem> >  > > Regards,> > Randy> > > >  >>> Olaf Wagner <wagner at elegosoft.com> 7/30/2008 2:24 AM >>>> > Quoting Randy Coleburn <rcoleburn at scires.com>:> > > >  > Hi:> >  >> >  > 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.> >  >> >  > This problem is easily reproduced using the "formsedit" program.> >  >> >  > The problem is with the TypeIn and TypeScript FormsVBT elements used > >  >  in my program.  Since formsedit uses these, you can easily > >  > reproduce  the problem.> >  >> >  > 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.> > > > Randy,> > > > I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't able> > to reproduce the problem on FreeBSD 6.3.> > > > Does the problem show up on all platforms you are working on?> > Which are these?> > > > Are there any local modifications to the libraries which I may not> > have?> > > > If it occurs only on Unix, it may be possible that a weird window> > manager interferes with the event delivery; otherwise I've got no> > good idea. If on Unix, you/we could perhaps test the behaviour> > on a different (remote) X display?> > > > Please provide more data about the problem context and how to> > reproduce it.> > > > Regards,> > > > Olaf> > > >  > 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).> >  >> >  > 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#
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/a6c7192d/attachment.html>

From jayk123 at hotmail.com  Fri Aug  1 10:57:20 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 1 Aug 2008 08:57:20 +0000
Subject: [M3devel] files over 2gig break 32bit Trestle file browser
 (maybe only Win32) (was the formsedit bug)
In-Reply-To: <COL101-W47C793FC4B3AB08006FD9DE67F0@phx.gbl>
References: <4891A737.1E75.00D7.1@scires.com>
	<537778.13498.qm@web27107.mail.ukl.yahoo.com> 
	<COL101-W47C793FC4B3AB08006FD9DE67F0@phx.gbl>
Message-ID: <COL101-W749C621ADBFF6587DAC097E67F0@phx.gbl>


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



From: jayk123 at hotmail.comTo: dabenavidesd at yahoo.es; rodney.bates at wichita.edu; rcoleburn at scires.comDate: Fri, 1 Aug 2008 08:43:31 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] need help with cm3 problem before I deliver software this week


I can reproduce the problem. Exactly as well reported.It kind of only happens once. Bring up formsedit, click, left arrow(s), type, it does what Randy said.Click again, arrows again, type again, not a second time. Good enough though.Close formsedit, reopen, it repros. Good.file.save, type backslash or forward slash in the dialog, press return, and boom:Most other strings are ok, but a single forward or backward slash, booms. ****** runtime error:***    An enumeration or subrange value was out of range.***    file "..\src\os\WIN32\FSWin32.m3", line 435***Stack trace:   FP         PC      Procedure---------  ---------  -------------------------------0x67afccc   0x42524f  BuildStatus + 0x21 in ..\src\os\WIN32\FSWin32.m30x67afe60   0x4251dc  Status + 0x137 in ..\src\os\WIN32\FSWin32.m30x67aff50   0xd9d131  DoStats + 0x253 in ..\src\lego\FileBrowserVBT.m30x67aff88   0x53a6ca  RunThread + 0x1f6 in ..\src\thread\WIN32\ThreadWin32.m30x67affb4   0x53a463  ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3.........  .........  ... more frames ... bugs...  And is that red line supposed to appear in the gui?  - Jay> Date: Thu, 31 Jul 2008 22:43:07 +0000> From: dabenavidesd at yahoo.es> To: rodney.bates at wichita.edu; rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] need help with cm3 problem before I deliver software this week> > Hi all:> 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.> Thanks> > --- El jue, 31/7/08, Randy Coleburn <rcoleburn at scires.com> escribi?:> De: Randy Coleburn <rcoleburn at scires.com>> Asunto: Re: [M3devel] need help with cm3 problem before I deliver software this week> Para: "Rodney M. Bates" <rodney.bates at wichita.edu>> CC: m3devel at elegosoft.com> Fecha: jueves, 31 julio, 2008 10:51> > > > Rodney:>  > I am using Windows XP Professional, Service Pack 2 (on some systems, Service Pack 3 is applied).>  > 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?>  > 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.>  > Regards,> Randy> > >>> "Rodney M. Bates" <rodney.bates at wichita.edu> 7/31/2008 9:33 AM >>>> Which variant of the M3 Windows target are you using?  I don't have any> of them built right now.> > Randy Coleburn wrote:> > Hi Olaf, Daniel, Rodney, et al:> >  > > Thanks for your responses so far.  Sorry for the delay in replying, but > > our email server has been offline for nearly 24-hours.  There were some > > severe electrical storms that took down both redundant power systems for > > our email system.  Hope I have not missed any of your replies.> >  > > Right now, I am delivering the software on Windows XP using SP2 or > > greater.  I have not tried to see if this problem also occurs on Unix.  > > I don't have ready access to a unix system from my current location.> >  > > So it is perhaps a Windows-only problem with Trestle/FormsVBT.  In any > > event, it is a real problem for me.> >  > > As for the pixmap stretching problem, I have tested various resolutions > > on the customer's computer.  Unfortunately, the customer demands that > > the display resolution stay at the 1920x1200.> > 1920x1200=pixmap stretch problem> > 1680x1050=pixmap stretch problem> > 1440x900=no problem> > 1024x768=no problem> >  > > Regards,> > Randy> > > >  >>> Olaf Wagner <wagner at elegosoft.com> 7/30/2008 2:24 AM >>>> > Quoting Randy Coleburn <rcoleburn at scires.com>:> > > >  > Hi:> >  >> >  > 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.> >  >> >  > This problem is easily reproduced using the "formsedit" program.> >  >> >  > The problem is with the TypeIn and TypeScript FormsVBT elements used > >  >  in my program.  Since formsedit uses these, you can easily > >  > reproduce  the problem.> >  >> >  > 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.> > > > Randy,> > > > I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't able> > to reproduce the problem on FreeBSD 6.3.> > > > Does the problem show up on all platforms you are working on?> > Which are these?> > > > Are there any local modifications to the libraries which I may not> > have?> > > > If it occurs only on Unix, it may be possible that a weird window> > manager interferes with the event delivery; otherwise I've got no> > good idea. If on Unix, you/we could perhaps test the behaviour> > on a different (remote) X display?> > > > Please provide more data about the problem context and how to> > reproduce it.> > > > Regards,> > > > Olaf> > > >  > 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).> >  >> >  > 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#
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/112b85c5/attachment.html>

From jayk123 at hotmail.com  Fri Aug  1 11:15:56 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 1 Aug 2008 09:15:56 +0000
Subject: [M3devel] need help with cm3 problem before I deliver
	software	this week
In-Reply-To: <537778.13498.qm@web27107.mail.ukl.yahoo.com>
References: <4891A737.1E75.00D7.1@scires.com>
	<537778.13498.qm@web27107.mail.ukl.yahoo.com> 
Message-ID: <COL101-W61F864A9FD2E441743295E67F0@phx.gbl>


I take that back -- it repros better than I said.
Every time I click, arrow, type, the first text insertion happens where I clicked.
Trestle is so layered..so many calls to a function called "Mouse" when you click..
 
 - Jay



From: jayk123 at hotmail.comTo: dabenavidesd at yahoo.es; rodney.bates at wichita.edu; rcoleburn at scires.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] need help with cm3 problem before I deliver software this weekDate: Fri, 1 Aug 2008 08:43:31 +0000


I can reproduce the problem. Exactly as well reported.It kind of only happens once. Bring up formsedit, click, left arrow(s), type, it does what Randy said.Click again, arrows again, type again, not a second time. Good enough though.Close formsedit, reopen, it repros. Good.file.save, type backslash or forward slash in the dialog, press return, and boom:Most other strings are ok, but a single forward or backward slash, booms. ****** runtime error:***    An enumeration or subrange value was out of range.***    file "..\src\os\WIN32\FSWin32.m3", line 435***Stack trace:   FP         PC      Procedure---------  ---------  -------------------------------0x67afccc   0x42524f  BuildStatus + 0x21 in ..\src\os\WIN32\FSWin32.m30x67afe60   0x4251dc  Status + 0x137 in ..\src\os\WIN32\FSWin32.m30x67aff50   0xd9d131  DoStats + 0x253 in ..\src\lego\FileBrowserVBT.m30x67aff88   0x53a6ca  RunThread + 0x1f6 in ..\src\thread\WIN32\ThreadWin32.m30x67affb4   0x53a463  ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3.........  .........  ... more frames ... bugs...  And is that red line supposed to appear in the gui?  - Jay> Date: Thu, 31 Jul 2008 22:43:07 +0000> From: dabenavidesd at yahoo.es> To: rodney.bates at wichita.edu; rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] need help with cm3 problem before I deliver software this week> > Hi all:> 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.> Thanks> > --- El jue, 31/7/08, Randy Coleburn <rcoleburn at scires.com> escribi?:> De: Randy Coleburn <rcoleburn at scires.com>> Asunto: Re: [M3devel] need help with cm3 problem before I deliver software this week> Para: "Rodney M. Bates" <rodney.bates at wichita.edu>> CC: m3devel at elegosoft.com> Fecha: jueves, 31 julio, 2008 10:51> > > > Rodney:>  > I am using Windows XP Professional, Service Pack 2 (on some systems, Service Pack 3 is applied).>  > 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?>  > 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.>  > Regards,> Randy> > >>> "Rodney M. Bates" <rodney.bates at wichita.edu> 7/31/2008 9:33 AM >>>> Which variant of the M3 Windows target are you using?  I don't have any> of them built right now.> > Randy Coleburn wrote:> > Hi Olaf, Daniel, Rodney, et al:> >  > > Thanks for your responses so far.  Sorry for the delay in replying, but > > our email server has been offline for nearly 24-hours.  There were some > > severe electrical storms that took down both redundant power systems for > > our email system.  Hope I have not missed any of your replies.> >  > > Right now, I am delivering the software on Windows XP using SP2 or > > greater.  I have not tried to see if this problem also occurs on Unix.  > > I don't have ready access to a unix system from my current location.> >  > > So it is perhaps a Windows-only problem with Trestle/FormsVBT.  In any > > event, it is a real problem for me.> >  > > As for the pixmap stretching problem, I have tested various resolutions > > on the customer's computer.  Unfortunately, the customer demands that > > the display resolution stay at the 1920x1200.> > 1920x1200=pixmap stretch problem> > 1680x1050=pixmap stretch problem> > 1440x900=no problem> > 1024x768=no problem> >  > > Regards,> > Randy> > > >  >>> Olaf Wagner <wagner at elegosoft.com> 7/30/2008 2:24 AM >>>> > Quoting Randy Coleburn <rcoleburn at scires.com>:> > > >  > Hi:> >  >> >  > 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.> >  >> >  > This problem is easily reproduced using the "formsedit" program.> >  >> >  > The problem is with the TypeIn and TypeScript FormsVBT elements used > >  >  in my program.  Since formsedit uses these, you can easily > >  > reproduce  the problem.> >  >> >  > 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.> > > > Randy,> > > > I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't able> > to reproduce the problem on FreeBSD 6.3.> > > > Does the problem show up on all platforms you are working on?> > Which are these?> > > > Are there any local modifications to the libraries which I may not> > have?> > > > If it occurs only on Unix, it may be possible that a weird window> > manager interferes with the event delivery; otherwise I've got no> > good idea. If on Unix, you/we could perhaps test the behaviour> > on a different (remote) X display?> > > > Please provide more data about the problem context and how to> > reproduce it.> > > > Regards,> > > > Olaf> > > >  > 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).> >  >> >  > 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#
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/f991c98a/attachment.html>

From jayk123 at hotmail.com  Fri Aug  1 15:04:13 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 1 Aug 2008 13:04:13 +0000
Subject: [M3devel] winuser.i3
Message-ID: <COL101-W12E97C0F8EA0D9038B2985E67F0@phx.gbl>


Darko,
 
1) Where did these come from?
    (* Where did these come from? *)     MFS_MASK            = 16_0000108B;     MFS_HOTTRACKDRAWN   = 16_10000000;     MFS_CACHEDBMP       = 16_20000000;     MFS_BOTTOMGAPDROP   = 16_40000000;     MFS_TOPGAPDROP      = 16_80000000;     MFS_GAPDROP         = 16_C0000000;
I can't find them in "real" headers.
 
2) Why DEFAULT_GUI_FONT here? It belongs in WinGDI.i3. I'm moving it.
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/de74cb54/attachment.html>

From jayk123 at hotmail.com  Fri Aug  1 15:52:43 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 1 Aug 2008 13:52:43 +0000
Subject: [M3devel] need help with cm3 problem before I
	deliver	software	this week
In-Reply-To: <48925C6D.1E75.00D7.1@scires.com>
References: <537778.13498.qm@web27107.mail.ukl.yahoo.com>
	<464840.85424.qm@web27104.mail.ukl.yahoo.com> 
	<48925C6D.1E75.00D7.1@scires.com>
Message-ID: <COL101-W5623694736FE1A45441C7EE67F0@phx.gbl>


 > It is interesting to note that one of the messages (#533) is identified as "???"
This is not worrisome, and it should be fixed now.
They are:
#define WM_CAPTURECHANGED               0x0215
Sadly the real problem is not yet fixed -- not even understood. :(
 
It definitely doesn't occur on other systems?
It seems quite odd -- clearly formsedit is not missing any mouse or key events, and it is dealing with all of them at least partly correctly.
It clearly isn't missing any events, otherwise it wouldn't act as correctly as it does.
The mouse click moves the insertion point and the blinking cursor. The arrow keys move the blinking cursor and the "next" insertion point, typing insert the desired characters, just that FIRST character goes to the wrong place. Strange.
 
Recoding everything in C++ or C# isn't a bad idea imho, but certainly overkill for this one problem...
 
Trying with 3.6 or 4.1 would be good. I should do that very soon. Easier than reading through all the Trestle code. :(
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/d6a91b2a/attachment.html>

From jayk123 at hotmail.com  Fri Aug  1 16:06:45 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 1 Aug 2008 14:06:45 +0000
Subject: [M3devel] need help with cm3 problem before
	I	deliver	software	this week
In-Reply-To: <COL101-W5623694736FE1A45441C7EE67F0@phx.gbl>
References: <537778.13498.qm@web27107.mail.ukl.yahoo.com>
	<464840.85424.qm@web27104.mail.ukl.yahoo.com> 
	<48925C6D.1E75.00D7.1@scires.com> 
	<COL101-W5623694736FE1A45441C7EE67F0@phx.gbl>
Message-ID: <COL101-W806E32408CDC1FE80AE503E67F0@phx.gbl>


It works ok with 3.6..

From: jayk123 at hotmail.comTo: rcoleburn at scires.com; rodney.bates at wichita.edu; dabenavidesd at yahoo.esDate: Fri, 1 Aug 2008 13:52:43 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] need help with cm3 problem before I deliver software this week


 > It is interesting to note that one of the messages (#533) is identified as "???"This is not worrisome, and it should be fixed now.They are:#define WM_CAPTURECHANGED               0x0215Sadly the real problem is not yet fixed -- not even understood. :( It definitely doesn't occur on other systems?It seems quite odd -- clearly formsedit is not missing any mouse or key events, and it is dealing with all of them at least partly correctly.It clearly isn't missing any events, otherwise it wouldn't act as correctly as it does.The mouse click moves the insertion point and the blinking cursor. The arrow keys move the blinking cursor and the "next" insertion point, typing insert the desired characters, just that FIRST character goes to the wrong place. Strange. Recoding everything in C++ or C# isn't a bad idea imho, but certainly overkill for this one problem... Trying with 3.6 or 4.1 would be good. I should do that very soon. Easier than reading through all the Trestle code. :(  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/217e4bbc/attachment.html>

From jayk123 at hotmail.com  Fri Aug  1 16:45:02 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 1 Aug 2008 14:45:02 +0000
Subject: [M3devel] need help with cm3 problem before
	I	deliver	software	this week
In-Reply-To: <COL101-W5623694736FE1A45441C7EE67F0@phx.gbl>
References: <537778.13498.qm@web27107.mail.ukl.yahoo.com>
	<464840.85424.qm@web27104.mail.ukl.yahoo.com> 
	<48925C6D.1E75.00D7.1@scires.com> 
	<COL101-W5623694736FE1A45441C7EE67F0@phx.gbl> 
Message-ID: <COL101-W5340B42054B530082445DCE67F0@phx.gbl>


 > It works ok with 3.6..
 
a *quick* and *incomplete* survey of 3.6 vs. current shows:  - deal with change in Text type (platform independent)   - handle WM_CHAR (windows specific)   - handle newlines differently (platform independly, except maybe the data varies per platform) 
 I tried undoing the last two, still no luck. The first is harder to undo, maybe "impossible", just have to read/debug it and decide it is ok or not..?
 Next easy step is probably to see if repros with 4.1,  and then proceed with comparing the "closer" repro vs. non-repro.  If it does not repro with 4.1, and newer releases are available  between it and current -- e.g. 5.2 -- would be good to narrow  down when it started happening and compare those source trees.
The code in question is stuff like mtext and textport.
There are functions named key or Key or mouse or Mouse. Those are also important to look at, I think.
Not being particularly close to figuring this out, consider ignoring everything I have said. :)
It is hard to pass up such a simple repro. :)And the knowledge that 3.6 works, and really not much has changed in the intervening ~12 years..
Oh, and there are pixmap changes.Randy, I glossed over the mail about pixmaps.You have a simple repro of that?You can try it with 3.6?
3.6 should still be readily downloadable from the web, and it really isn'tdifficult to get it up and running, at least on Windows.(I can't speak for Linux. I ran 3.6, albeit hardly at all, on Linux 1.2 I think it was,and NT 3.51, maybe later NT and maybe Win9x)
(and 3.6 is liberally licensed, so anyone can send it around.The notion that 5.1 was the open source release always sounded wrong...)
 - Jay



From: jayk123 at hotmail.comTo: rcoleburn at scires.com; rodney.bates at wichita.edu; dabenavidesd at yahoo.esCC: m3devel at elegosoft.comSubject: RE: [M3devel] need help with cm3 problem before I deliver software this weekDate: Fri, 1 Aug 2008 14:06:45 +0000


It works ok with 3.6..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/ca6fbed3/attachment.html>

From jayk123 at hotmail.com  Fri Aug  1 16:43:17 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 1 Aug 2008 14:43:17 +0000
Subject: [M3devel] winuser.i3
In-Reply-To: <CD17C8FC-CD4C-4927-85C6-6C2FB20F80A2@darko.org>
References: <COL101-W12E97C0F8EA0D9038B2985E67F0@phx.gbl>
	<CD17C8FC-CD4C-4927-85C6-6C2FB20F80A2@darko.org>
Message-ID: <COL101-W4910DD3A123B57A3DFAAE9E67F0@phx.gbl>


Yes, I wouldn't mind that either. Windows.i3, MSWindows.i3.
For now thought I have preserved the structure and moved the font to WinGDI.i3, since it is in WinGDI.h.
I commented out the others, until such time as they are found *somewhere*, so I can least verify their correctness.
(NOT that I am in general verifying everything, just random samples.)
 
 
 - Jay



CC: m3devel at elegosoft.comFrom: darko at darko.orgTo: jayk123 at hotmail.comSubject: Re: [M3devel] winuser.i3Date: Fri, 1 Aug 2008 16:29:15 +0200
I have no Idea where there came from or where they go. Personally I'm of the opinion that all the Windows defs should go in one big file (Win.i3).


On 01/08/2008, at 3:04 PM, Jay wrote:

Darko, 1) Where did these come from?    (* Where did these come from? *)     MFS_MASK            = 16_0000108B;     MFS_HOTTRACKDRAWN   = 16_10000000;     MFS_CACHEDBMP       = 16_20000000;     MFS_BOTTOMGAPDROP   = 16_40000000;     MFS_TOPGAPDROP      = 16_80000000;     MFS_GAPDROP         = 16_C0000000;I can't find them in "real" headers. 2) Why DEFAULT_GUI_FONT here? It belongs in WinGDI.i3. I'm moving it.  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/d2d11f3a/attachment.html>

From darko at darko.org  Fri Aug  1 16:29:15 2008
From: darko at darko.org (Darko)
Date: Fri, 1 Aug 2008 16:29:15 +0200
Subject: [M3devel] winuser.i3
In-Reply-To: <COL101-W12E97C0F8EA0D9038B2985E67F0@phx.gbl>
References: <COL101-W12E97C0F8EA0D9038B2985E67F0@phx.gbl>
Message-ID: <CD17C8FC-CD4C-4927-85C6-6C2FB20F80A2@darko.org>

I have no Idea where there came from or where they go. Personally I'm  
of the opinion that all the Windows defs should go in one big file  
(Win.i3).


On 01/08/2008, at 3:04 PM, Jay wrote:

> Darko,
>
> 1) Where did these come from?
>     (* Where did these come from? *)
>      MFS_MASK            = 16_0000108B;
>      MFS_HOTTRACKDRAWN   = 16_10000000;
>      MFS_CACHEDBMP       = 16_20000000;
>      MFS_BOTTOMGAPDROP   = 16_40000000;
>      MFS_TOPGAPDROP      = 16_80000000;
>      MFS_GAPDROP         = 16_C0000000;
>
> I can't find them in "real" headers.
>
> 2) Why DEFAULT_GUI_FONT here? It belongs in WinGDI.i3. I'm moving it.
>
>  - Jay
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/057ae0fa/attachment.html>

From jayk123 at hotmail.com  Fri Aug  1 17:28:16 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 1 Aug 2008 15:28:16 +0000
Subject: [M3devel] need help with cm3 problem
	before	I	deliver	software	this week
In-Reply-To: <COL101-W5340B42054B530082445DCE67F0@phx.gbl>
References: <537778.13498.qm@web27107.mail.ukl.yahoo.com>
	<464840.85424.qm@web27104.mail.ukl.yahoo.com> 
	<48925C6D.1E75.00D7.1@scires.com> 
	<COL101-W5623694736FE1A45441C7EE67F0@phx.gbl>  
	<COL101-W5340B42054B530082445DCE67F0@phx.gbl>
Message-ID: <COL101-W37A68B1566CAAAF8791DBFE67F0@phx.gbl>


Clarification: there are other changes.
There was a change in font stuff.
There was added batching of painting.
And more.
 
I'm still stumped. I have to be away from this for a few hours or all day.
I think seeing if 4.1 repros will be good, and then maybe widen the net on either a) what changed (not just trestle?) and b) debugging it.
Really it shouldn't be hard..to figure how out it decides where to place the character.
 
Oh, and save the text file, see if it is in memory and on disk where it is drawn on the screen.
That would be useful to know.
 
ok..the text matches the display.
 
I can roll Wintrestle.i3 back to cm3.6, still repros.
 
Ok, the reason it is platform specific is because of:
 
Searching for 'TextPortModel: TEXT := "'...C:\dev2\cm3.2\m3-ui\vbtkit\src\vbtkitutils\POSIX\VBTKitEnv.i3(30):  TextPortModel: TEXT := "emacs";C:\dev2\cm3.2\m3-ui\vbtkit\src\vbtkitutils\WIN32\VBTKitEnv.i3(30):  TextPortModel: TEXT := "mac";
If you change Windows the the emacs model, no repro.
So try Posix to mac model, hopefully it repros.
 
Ok, Randy, is this actually your bug, or just indicative of it?
 
 - Jay



From: jayk123 at hotmail.comTo: rcoleburn at scires.com; rodney.bates at wichita.edu; dabenavidesd at yahoo.esDate: Fri, 1 Aug 2008 14:45:02 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] need help with cm3 problem before I deliver software this week


 > It works ok with 3.6.. a *quick* and *incomplete* survey of 3.6 vs. current shows:  - deal with change in Text type (platform independent)   - handle WM_CHAR (windows specific)   - handle newlines differently (platform independly, except maybe the data varies per platform)  I tried undoing the last two, still no luck. The first is harder to undo, maybe "impossible", just have to read/debug it and decide it is ok or not..? Next easy step is probably to see if repros with 4.1,  and then proceed with comparing the "closer" repro vs. non-repro.  If it does not repro with 4.1, and newer releases are available  between it and current -- e.g. 5.2 -- would be good to narrow  down when it started happening and compare those source trees.The code in question is stuff like mtext and textport.There are functions named key or Key or mouse or Mouse. Those are also important to look at, I think.Not being particularly close to figuring this out, consider ignoring everything I have said. :)It is hard to pass up such a simple repro. :)And the knowledge that 3.6 works, and really not much has changed in the intervening ~12 years..Oh, and there are pixmap changes.Randy, I glossed over the mail about pixmaps.You have a simple repro of that?You can try it with 3.6?3.6 should still be readily downloadable from the web, and it really isn'tdifficult to get it up and running, at least on Windows.(I can't speak for Linux. I ran 3.6, albeit hardly at all, on Linux 1.2 I think it was,and NT 3.51, maybe later NT and maybe Win9x)(and 3.6 is liberally licensed, so anyone can send it around.The notion that 5.1 was the open source release always sounded wrong...) - Jay



From: jayk123 at hotmail.comTo: rcoleburn at scires.com; rodney.bates at wichita.edu; dabenavidesd at yahoo.esCC: m3devel at elegosoft.comSubject: RE: [M3devel] need help with cm3 problem before I deliver software this weekDate: Fri, 1 Aug 2008 14:06:45 +0000

It works ok with 3.6..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/0a69aa5b/attachment.html>

From wagner at elegosoft.com  Fri Aug  1 17:59:07 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Fri, 01 Aug 2008 17:59:07 +0200
Subject: [M3devel] need help with cm3 problem before I deliver
	software	this week
In-Reply-To: <4892601C.1E75.00D7.1@scires.com>
References: <488F4292.1E75.00D7.1@scires.com>
	<20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com>
	<4890EB9C.1E75.00D7.1@scires.com> <4891BF18.8000905@wichita.edu>
	<4891A737.1E75.00D7.1@scires.com>
	<20080731184449.su7qkp9x6ocwkoo0@mail.elegosoft.com>
	<4892601C.1E75.00D7.1@scires.com>
Message-ID: <20080801175907.irr4cv7jls0gokc0@mail.elegosoft.com>

Quoting Randy Coleburn <rcoleburn at scires.com>:

> Olaf:
>
> The problem reproduces every time on my system.  I've tried it on three
> different XP computers with same results every time.
>
> 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.
>
> 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.

Randy,

indeed your compiled program shows the strange behaviour. I'll add
my version as someone may be able to compare the linked objects and
see which are significantly different.

We can now be sure that it is indeed either a difference in the source
code or a difference in the code my and your compiler generate.
I haven't upgrade my Windows compiler for more than two months.
I'll try an upgrade of the core system later.

Regards,

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194

-------------- next part --------------
A non-text attachment was scrubbed...
Name: formsedit.exe.gz
Type: application/gzip
Size: 746259 bytes
Desc: not available
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/03eb6d8b/attachment.bin>

From rcoleburn at scires.com  Fri Aug  1 18:06:31 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Fri, 01 Aug 2008 12:06:31 -0400
Subject: [M3devel] need help with cm3 problem	before	I	deliver	software
	this week
In-Reply-To: <COL101-W37A68B1566CAAAF8791DBFE67F0@phx.gbl>
References: <537778.13498.qm@web27107.mail.ukl.yahoo.com>
	<464840.85424.qm@web27104.mail.ukl.yahoo.com>
	<48925C6D.1E75.00D7.1@scires.com>
	<COL101-W5623694736FE1A45441C7EE67F0@phx.gbl>
	<COL101-W5340B42054B530082445DCE67F0@phx.gbl><COL101-W5340B42054B530082445DCE67F0@phx.gbl>
	<COL101-W37A68B1566CAAAF8791DBFE67F0@phx.gbl>
Message-ID: <4892FC3F.1E75.00D7.1@scires.com>

Jay:
 
I have checked my Reactor v4.1 distribution and the problem also reproduces there as well, so this is not something new, its been around awhile.  I guess my memory must be failing that I don't remember this bug.  In any event, my customer is not happy, so I have to try and fix this and the pixmap problem.
 
I've returned back home from the customer site.  They have given me two weeks to fix these problems and to make some enhancements they want in the product before it is released to the end users.  So, that is my time interval--I've got 2 weeks max to fix everything.  The customer is not going to accept the product if I can't fix the cursor movement typein problem.  They don't like the pixmap problem, but since it is a non-functional issue, they will have to accept the defect if I can't fix it.  So, number one priority is to get the typein at cursor issue solved.
 
Note that this problem seems to reproduce in all FormsVBT places where you can type text, even in numerics.  Thus, it is a real problem.  My product uses several windows that have fields where the user has to type to change values.  In every case, when you click the mouse and also use the arrow keys, the first character typed goes to the wrong place.  I guess I never observed this because I always clicked the mouse to the exact place I wanted and didn't use the arrow keys.
 
Jay, you mention something about changing the TextPort model and ask "is this actually your bug, or just indicative of it"?  I'm not sure exactly what you are asking me, so if you will clarify your question, I'll try to give a better answer.  I don't think switching the TextPortModel will have a bearing on the problem I am having.
 
I have to leave now for a family reunion event, so I won't have email access again until late Sunday.  When I get back, I'll try to send a short program to demonstrate the pixmap problem, but then I'm not sure you can reproduce it unless you can set your screen resolution to 1920x1200.  At a minimum, I'll try and capture some screen images to show the difference in the same window when run at the various resolutions.
 
Thanks for your assistance in helping track down this problem.
 
Regards,
Randy

>>> Jay <jayk123 at hotmail.com> 8/1/2008 11:28 AM >>>
Clarification: there are other changes.
There was a change in font stuff.
There was added batching of painting.
And more.
 
I'm still stumped. I have to be away from this for a few hours or all day.
I think seeing if 4.1 repros will be good, and then maybe widen the net on either a) what changed (not just trestle?) and b) debugging it.
Really it shouldn't be hard..to figure how out it decides where to place the character.
 
Oh, and save the text file, see if it is in memory and on disk where it is drawn on the screen.
That would be useful to know.
 
ok..the text matches the display.
 
I can roll Wintrestle.i3 back to cm3.6, still repros.
 
Ok, the reason it is platform specific is because of:
 
Searching for 'TextPortModel: TEXT := "'...
C:\dev2\cm3.2\m3-ui\vbtkit\src\vbtkitutils\POSIX\VBTKitEnv.i3(30):  TextPortModel: TEXT := "emacs";
C:\dev2\cm3.2\m3-ui\vbtkit\src\vbtkitutils\WIN32\VBTKitEnv.i3(30):  TextPortModel: TEXT := "mac";

If you change Windows the the emacs model, no repro.
So try Posix to mac model, hopefully it repros.
 
Ok, Randy, is this actually your bug, or just indicative of it?
 
 - Jay



From: jayk123 at hotmail.com 
To: rcoleburn at scires.com; rodney.bates at wichita.edu; dabenavidesd at yahoo.es 
Date: Fri, 1 Aug 2008 14:45:02 +0000
CC: m3devel at elegosoft.com 
Subject: Re: [M3devel] need help with cm3 problem before I deliver software this week

 > It works ok with 3.6..

 
a *quick* and *incomplete* survey of 3.6 vs. current shows:
  - deal with change in Text type (platform independent) 
  - handle WM_CHAR (windows specific) 
  - handle newlines differently (platform independly, except maybe the data varies per platform) 

 I tried undoing the last two, still no luck.
 The first is harder to undo, maybe "impossible", just have to read/debug it and decide it is ok or not..?

 Next easy step is probably to see if repros with 4.1,
  and then proceed with comparing the "closer" repro vs. non-repro.
  If it does not repro with 4.1, and newer releases are available
  between it and current -- e.g. 5.2 -- would be good to narrow
  down when it started happening and compare those source trees.

The code in question is stuff like mtext and textport.

There are functions named key or Key or mouse or Mouse. Those are also important to look at, I think.

Not being particularly close to figuring this out, consider ignoring everything I have said. :)

It is hard to pass up such a simple repro. :)
And the knowledge that 3.6 works, and really not much has changed in the intervening ~12 years..

Oh, and there are pixmap changes.
Randy, I glossed over the mail about pixmaps.
You have a simple repro of that?
You can try it with 3.6?

3.6 should still be readily downloadable from the web, and it really isn't
difficult to get it up and running, at least on Windows.
(I can't speak for Linux. I ran 3.6, albeit hardly at all, on Linux 1.2 I think it was,
and NT 3.51, maybe later NT and maybe Win9x)
(and 3.6 is liberally licensed, so anyone can send it around.
The notion that 5.1 was the open source release always sounded wrong...)

 - Jay





From: jayk123 at hotmail.com 
To: rcoleburn at scires.com; rodney.bates at wichita.edu; dabenavidesd at yahoo.es 
CC: m3devel at elegosoft.com 
Subject: RE: [M3devel] need help with cm3 problem before I deliver software this week
Date: Fri, 1 Aug 2008 14:06:45 +0000

It works ok with 3.6..


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/811dfc2d/attachment.html>

From rcoleburn at scires.com  Fri Aug  1 18:29:38 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Fri, 01 Aug 2008 12:29:38 -0400
Subject: [M3devel] need help with cm3 problem before I
	deliver	software	this week
In-Reply-To: <20080801175907.irr4cv7jls0gokc0@mail.elegosoft.com>
References: <488F4292.1E75.00D7.1@scires.com>
	<20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com>
	<4890EB9C.1E75.00D7.1@scires.com> <4891BF18.8000905@wichita.edu>
	<4891A737.1E75.00D7.1@scires.com>
	<20080731184449.su7qkp9x6ocwkoo0@mail.elegosoft.com>
	<4892601C.1E75.00D7.1@scires.com>
	<20080801175907.irr4cv7jls0gokc0@mail.elegosoft.com>
Message-ID: <489301AA.1E75.00D7.1@scires.com>

Olaf:
 
I tested your version of formsedit on my computer and it works
correctly.
 
This is a big clue I think.  We now have the same program built on two
different machines.  One works well and one has a bug.  The bug
manifests on both systems using same EXE, so we can rule out a
difference in the computer causing the bug to manifest.  Thus, there
must be either (1) a difference in the source code base, OR (2) a
difference in the way the EXE is produced.
 
If we could compare the two source trees and find them identical, then
the problem could be traced to #2.  If the sources differ, the problem
could still be #2, but more likely would be #1.
 
Would it make sense for me to make a tar gzip file of my cm3 source
tree and send to you for compare?  Alternately, you could make the
tarball and send to me for compare with my source tree.
 
Regards,
Randy

>>> Olaf Wagner <wagner at elegosoft.com> 8/1/2008 11:59 AM >>>
Quoting Randy Coleburn <rcoleburn at scires.com>:

> Olaf:
>
> The problem reproduces every time on my system.  I've tried it on
three
> different XP computers with same results every time.
>
> 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.
>
> 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.

Randy,

indeed your compiled program shows the strange behaviour. I'll add
my version as someone may be able to compare the linked objects and
see which are significantly different.

We can now be sure that it is indeed either a difference in the source
code or a difference in the code my and your compiler generate.
I haven't upgrade my Windows compiler for more than two months.
I'll try an upgrade of the core system later.

Regards,

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin,
Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45
86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz:
Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:
DE163214194

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/ead69b46/attachment.html>

From wagner at elegosoft.com  Fri Aug  1 19:33:11 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Fri, 01 Aug 2008 19:33:11 +0200
Subject: [M3devel] need help with cm3 problem before I deliver
	software	this week
In-Reply-To: <489301AA.1E75.00D7.1@scires.com>
References: <488F4292.1E75.00D7.1@scires.com>
	<20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com>
	<4890EB9C.1E75.00D7.1@scires.com> <4891BF18.8000905@wichita.edu>
	<4891A737.1E75.00D7.1@scires.com>
	<20080731184449.su7qkp9x6ocwkoo0@mail.elegosoft.com>
	<4892601C.1E75.00D7.1@scires.com>
	<20080801175907.irr4cv7jls0gokc0@mail.elegosoft.com>
	<489301AA.1E75.00D7.1@scires.com>
Message-ID: <20080801193311.cr577vkk8cw88w4s@mail.elegosoft.com>

Quoting Randy Coleburn <rcoleburn at scires.com>:

> Olaf:
>
> I tested your version of formsedit on my computer and it works
> correctly.
>
> This is a big clue I think.  We now have the same program built on two
> different machines.  One works well and one has a bug.  The bug
> manifests on both systems using same EXE, so we can rule out a
> difference in the computer causing the bug to manifest.  Thus, there
> must be either (1) a difference in the source code base, OR (2) a
> difference in the way the EXE is produced.
>
> If we could compare the two source trees and find them identical, then
> the problem could be traced to #2.  If the sources differ, the problem
> could still be #2, but more likely would be #1.
>
> Would it make sense for me to make a tar gzip file of my cm3 source
> tree and send to you for compare?  Alternately, you could make the
> tarball and send to me for compare with my source tree.

In the meantime I have updated my core system on Windows (m3-sys and
m3-libs and performed scripts/upgrade.sh) and rebuilt all the GUI
sources (they were already up-to-date). Now I can reproduce the problem.
So something must definitely been broken in the recent months.

Of course I saved all the old sources and binaries before, so I am now
able to compare them. There have been quite a lot of changes though,
so it may take a while. I don't think it is necessary that you send
me your sources now. I'll let you know what I find.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From wagner at elegosoft.com  Fri Aug  1 22:15:51 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Fri, 01 Aug 2008 22:15:51 +0200
Subject: [M3devel] need help with cm3 problem before I deliver
	software	this week
In-Reply-To: <489301AA.1E75.00D7.1@scires.com>
References: <488F4292.1E75.00D7.1@scires.com>
	<20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com>
	<4890EB9C.1E75.00D7.1@scires.com> <4891BF18.8000905@wichita.edu>
	<4891A737.1E75.00D7.1@scires.com>
	<20080731184449.su7qkp9x6ocwkoo0@mail.elegosoft.com>
	<4892601C.1E75.00D7.1@scires.com>
	<20080801175907.irr4cv7jls0gokc0@mail.elegosoft.com>
	<489301AA.1E75.00D7.1@scires.com>
Message-ID: <20080801221551.padpgo9q4gsssgsk@mail.elegosoft.com>

Quoting Randy Coleburn <rcoleburn at scires.com>:

> Olaf:
>
> I tested your version of formsedit on my computer and it works
> correctly.
>
> This is a big clue I think.  We now have the same program built on two
> different machines.  One works well and one has a bug.  The bug
> manifests on both systems using same EXE, so we can rule out a
> difference in the computer causing the bug to manifest.  Thus, there
> must be either (1) a difference in the source code base, OR (2) a
> difference in the way the EXE is produced.
>
> If we could compare the two source trees and find them identical, then
> the problem could be traced to #2.  If the sources differ, the problem
> could still be #2, but more likely would be #1.

After I first had problems to reproduce the problem, I now seem unable
to make it disappear again. I saved all sources and executables
(cm3 installation, m3-libs, m3-sys) before I did a cvs update and
upgrade on them (after which the problem showed up), but moving back
the old sources and compiler produces the same failure still.

I'm at a complete loss right now. Perhaps we really need to compare
the linked objects in both the working and broken executable after all :-/
I seem unable to narrow down the faulting component.

Perhaps I need something to eat and then some sleep...

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From jayk123 at hotmail.com  Sat Aug  2 03:18:40 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 2 Aug 2008 01:18:40 +0000
Subject: [M3devel] formsedit/pixmap bugs
In-Reply-To: <20080801221551.padpgo9q4gsssgsk@mail.elegosoft.com>
References: <488F4292.1E75.00D7.1@scires.com>
	<20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com>
	<4890EB9C.1E75.00D7.1@scires.com> <4891BF18.8000905@wichita.edu>
	<4891A737.1E75.00D7.1@scires.com>
	<20080731184449.su7qkp9x6ocwkoo0@mail.elegosoft.com>
	<4892601C.1E75.00D7.1@scires.com>
	<20080801175907.irr4cv7jls0gokc0@mail.elegosoft.com>
	<489301AA.1E75.00D7.1@scires.com> 
	<20080801221551.padpgo9q4gsssgsk@mail.elegosoft.com>
Message-ID: <COL101-W16F4A874630C2E5F5A76CEE67E0@phx.gbl>


Darnit I realized what I should have quickly checked for before disappearing for a few hours.
(and darnit, did anyone else look at any code?)


The bug is in 3.6, essentially.
Anyone have anything older?
I think older might be readily available, but I also think 3.6 might be the first version with a Win32 Trestle, declared experimental at that.


3.6:
Searching for 'TextPortModel'...
D:\modula-3\src\vbtkit\src\vbtkitutils\VBTKitEnv.i3(30):  TextPortModel: TEXT := "emacs";
D:\modula-3\src\vbtkit\src\vbtkitutils\VBTKitEnv.m3(27):      IF Text.Equal (s, "ivy") THEN TextPortModel := "ivy" 
D:\modula-3\src\vbtkit\src\vbtkitutils\VBTKitEnv.m3(28):      ELSIF Text.Equal (s, "mac") THEN TextPortModel := "mac" 
D:\modula-3\src\vbtkit\src\vbtkitutils\VBTKitEnv.m3(29):      ELSIF Text.Equal (s, "xterm") THEN TextPortModel := "xterm"


The environment variable being checked for in the last lines didn't seem to work.
So I fiddled with the first line directly.
Change it to "mac" and it repros with 3.6.


Short term fix:
  Change the default to emacs for all platforms.


After that:
 Fix the mac model.


This is all related to how selection works.
Like if I select text, and then type, does the selected text get wholly replaced (mac) or does something wierd happen (emacs).
Or something like that.
"Model" is a plugin to "TextPort" that varies some of the behavior.
I only first heard of this this morning, skimming the code


If anyone can show me it *working* with the mac model in any version, I'm slightly interested.
Really we should just focus on MacModel.m3 and fix it, for the first time.
The problem is narrowed down enough, that it should be easy.


Please make the pixmap bug clear to me. I've only skimmed and I have noticed no description at all of the bug.
Just that there is a problem with pixmaps.
There was churn here between 3.6 and current.
Please test with 3.6 and/or 4.1 if you can.


I assume the "formsedit" bug is bad behavior in various "text fields" in a gui.
Formsedit is just one user of that -- of TextPort.


 - Jay

From jayk123 at hotmail.com  Sat Aug  2 03:39:34 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 2 Aug 2008 01:39:34 +0000
Subject: [M3devel] formsedit/pixmap bugs
In-Reply-To: <COL101-W16F4A874630C2E5F5A76CEE67E0@phx.gbl>
References: <488F4292.1E75.00D7.1@scires.com>
	<20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com>
	<4890EB9C.1E75.00D7.1@scires.com> <4891BF18.8000905@wichita.edu>
	<4891A737.1E75.00D7.1@scires.com>
	<20080731184449.su7qkp9x6ocwkoo0@mail.elegosoft.com>
	<4892601C.1E75.00D7.1@scires.com>
	<20080801175907.irr4cv7jls0gokc0@mail.elegosoft.com>
	<489301AA.1E75.00D7.1@scires.com> 
	<20080801221551.padpgo9q4gsssgsk@mail.elegosoft.com> 
	<COL101-W16F4A874630C2E5F5A76CEE67E0@phx.gbl>
Message-ID: <COL101-W71F979196B1C29448A15C2E67E0@phx.gbl>


Duh, it's obvious why the environment variable didn't work.
 
You can now revert to the "working" 3.6 behavior by setting the environment variable TEXTPORTMODEL=emacs.
It already supported TEXTPORTMODEL=mac, TEXTPORTMODEL=ivy, TEXTPORTMODEL=and xterm, and defaulted to emacs on Posix, but defaults to mac on Win32, without enabling getting the emacs mode.
3.6 defaulted to emacs for all platforms, that's why 3.6 "worked".
 
The mac model should still be fixed.
 
Some of the relevant files are:
 
D:\modula-3\src>dir /s/b *model*3D:\modula-3\src\vbtkit\src\etext\EmacsModel.i3D:\modula-3\src\vbtkit\src\etext\EmacsModel.m3D:\modula-3\src\vbtkit\src\etext\IvyModel.i3D:\modula-3\src\vbtkit\src\etext\IvyModel.m3D:\modula-3\src\vbtkit\src\etext\MacModel.i3D:\modula-3\src\vbtkit\src\etext\MacModel.m3D:\modula-3\src\vbtkit\src\etext\XtermModel.i3D:\modula-3\src\vbtkit\src\etext\XtermModel.m3
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080802/f17547df/attachment.html>

From rcoleburn at scires.com  Sat Aug  2 05:18:56 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Fri, 01 Aug 2008 23:18:56 -0400
Subject: [M3devel] screen shots of pixmap problem
Message-ID: <489399D1.1E75.00D7.1@scires.com>

I managed to get the customer to grab a few screen images that illustrate the pixmap problem we are having.  These screen shots supplied by the customer don't show the full extent of the pixmap problem, but I do think they show the basic issues.  Quality of the bitmaps isn't great, but I think it illustrates the problem.  
 
I think my whole application is fairly sophisticated in its use of Trestle/FormsVBT.  After the delivery, I'll try to provide the community with a portfolio of pictures we can add to the web site to show the capability of Trestle/FormsVBT.
 
The attached ZIP file contains the following files:
1.  splash_1440.bmp = the startup splash screen bitmap viewed at 1440x900 resolution.
 
2.  splash_1920.bmp = same bitmap as #1, but viewed at 1920x1200 resolution.  It is huge compared to #1.  Normally, when you increase resolution on the same screen, the images get smaller, but this time they get larger.
 
3.  aoi_1440.bmp = one of the windows viewed at 1440x900 resolution.
 
4.  aoi_1920.bmp = same window viewed at 1920x1200 resolution.  Notice that the black triangles in front of Polygon and Minutes are huge.  The text seems to be scaling fine, but the bitmaps are scaling much larger to be out of proportion with the text.  Also notice that the choice radio buttons in the Coordinates block are enlarged out of proportion.  If you look at the numeric in the lower right corner you will notice that the numeric text is elevated in the pixmap background rather than centered.  This is because the pixmap has been enlarged.  
 
Hope these screen shots help illustrate the types of problems I am having.  I have another window that has a number of Boolean choice boxes on it.  When you go to 1920x1200 these boolean pixmaps get enlarged so much that the window won't fit vertically on the screen anymore.  The OK, Close, Cancel buttons actually show off the screen, so the user can't even complete the interaction.  This same window at 1440x900 or lower looks fine and fits on the screen with no issue.
 
Any insight folks can supply on how to resolve this issue would be appreciated.
 
Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/831cb092/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pics.zip
Type: application/x-zip-compressed
Size: 419491 bytes
Desc: not available
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/831cb092/attachment.bin>

From jayk123 at hotmail.com  Tue Aug  5 13:40:12 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 5 Aug 2008 11:40:12 +0000
Subject: [M3devel] formsediit/macmodel problem
Message-ID: <COL101-W272B732C79E4B4AD2F0202E67B0@phx.gbl>


That's better, thanks!
I still have little idea what is going on here.
I can test it out a bit, can't vouch for it via code review,
at least not yet.

If you have multiple lines, of varying lengths..
not sure if this is due to word wrap or not,
and click in empty space past the end of one of the lines
and type, letters do not appear.

If you click at the end of the line ok.
I think clicking past the end of the line needs to pin the resulting
cursor location to the end of the line.

 I really don't know this code. :(
I think it was written by people who had implemented the same
things multiple times and by this time had all exactly in their head
just how to factor it perfectly for the right amount of flexibility.
"Right amount of flexibility" => "harder for newbies to understand.." :(
I need to read the green book and pay close attn the whole time. :)

I still get a sort of stray looking vertical red line when I first type after clicking.
But it can be deemed minor (depending on Randy's customer really).
Probably should focus on the pixmap problem.
Can I repro it on one machine???

Randy, you might want to try out the "emacs" model, perhaps it is better tested
and works ok. ?

 - Jay



> Date: Sun, 3 Aug 2008 11:44:54 +0000
> To: m3commit at elegosoft.com
> From: wagner at elego.de
> Subject: [M3commit] CVS Update: cm3
>
> CVSROOT: /usr/cvs
> Changes by: wagner at birch. 08/08/03 11:44:54
>
> Modified files:
> cm3/m3-ui/vbtkit/src/: m3overrides
> cm3/m3-ui/vbtkit/src/etext/: MacModel.m3 TextPort.m3
>
> Log message:
> tentative fix for text selection and insertion in the Mac TextPortModel:
>
> The strange behaviour reported by Randy Coleburn (mouse click, left, left,
> insert --> first character inserted at mouse click point) should now be gone;
> cursor up and down at the right end of ragged paragraphs still looks
> a bit strange, but that seems to be not worse than before. It still
> should be fixed though.
>
> These changes should be reviewed and tested by others; they seem to do
> the right thing for me, but I haven't done extensive testing, especially
> in other modes.
>


From wagner at elegosoft.com  Tue Aug  5 14:05:40 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 05 Aug 2008 14:05:40 +0200
Subject: [M3devel] formsediit/macmodel problem
In-Reply-To: <COL101-W272B732C79E4B4AD2F0202E67B0@phx.gbl>
References: <COL101-W272B732C79E4B4AD2F0202E67B0@phx.gbl>
Message-ID: <20080805140540.16dyn3kxc04ogkww@mail.elegosoft.com>

Quoting Jay <jayk123 at hotmail.com>:

> That's better, thanks!
> I still have little idea what is going on here.
> I can test it out a bit, can't vouch for it via code review,
> at least not yet.
>
> If you have multiple lines, of varying lengths..
> not sure if this is due to word wrap or not,
> and click in empty space past the end of one of the lines
> and type, letters do not appear.

Yes, the end-of-line behaviour is strange.

> If you click at the end of the line ok.
> I think clicking past the end of the line needs to pin the resulting
> cursor location to the end of the line.
>
>  I really don't know this code. :(

I doubt there is somebody around in our community who really does ;-)

> I think it was written by people who had implemented the same
> things multiple times and by this time had all exactly in their head
> just how to factor it perfectly for the right amount of flexibility.
> "Right amount of flexibility" => "harder for newbies to understand.." :(
> I need to read the green book and pay close attn the whole time. :)
>
> I still get a sort of stray looking vertical red line when I first   
> type after clicking.
> But it can be deemed minor (depending on Randy's customer really).
> Probably should focus on the pixmap problem.
> Can I repro it on one machine???
>
> Randy, you might want to try out the "emacs" model, perhaps it is   
> better tested
> and works ok. ?

I doubt that anybody used to working on Windows or Apple would like
to use the Emacs model...

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From hosking at cs.purdue.edu  Tue Aug  5 15:38:18 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 5 Aug 2008 09:38:18 -0400
Subject: [M3devel] formsediit/macmodel problem
In-Reply-To: <20080805140540.16dyn3kxc04ogkww@mail.elegosoft.com>
References: <COL101-W272B732C79E4B4AD2F0202E67B0@phx.gbl>
	<20080805140540.16dyn3kxc04ogkww@mail.elegosoft.com>
Message-ID: <109A2D6C-1849-4F77-8323-B55A97D5BB92@cs.purdue.edu>

I use emacs bindings all the time on OS X (it tends to support them in  
most apps).

On Aug 5, 2008, at 8:05 AM, Olaf Wagner wrote:

> Quoting Jay <jayk123 at hotmail.com>:
>
>> That's better, thanks!
>> I still have little idea what is going on here.
>> I can test it out a bit, can't vouch for it via code review,
>> at least not yet.
>>
>> If you have multiple lines, of varying lengths..
>> not sure if this is due to word wrap or not,
>> and click in empty space past the end of one of the lines
>> and type, letters do not appear.
>
> Yes, the end-of-line behaviour is strange.
>
>> If you click at the end of the line ok.
>> I think clicking past the end of the line needs to pin the resulting
>> cursor location to the end of the line.
>>
>> I really don't know this code. :(
>
> I doubt there is somebody around in our community who really does ;-)
>
>> I think it was written by people who had implemented the same
>> things multiple times and by this time had all exactly in their head
>> just how to factor it perfectly for the right amount of flexibility.
>> "Right amount of flexibility" => "harder for newbies to  
>> understand.." :(
>> I need to read the green book and pay close attn the whole time. :)
>>
>> I still get a sort of stray looking vertical red line when I first   
>> type after clicking.
>> But it can be deemed minor (depending on Randy's customer really).
>> Probably should focus on the pixmap problem.
>> Can I repro it on one machine???
>>
>> Randy, you might want to try out the "emacs" model, perhaps it is   
>> better tested
>> and works ok. ?
>
> I doubt that anybody used to working on Windows or Apple would like
> to use the Emacs model...
>
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin,  
> Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23  
> 45 86 95
>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz:  
> Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:  
> DE163214194
>



From jayk123 at hotmail.com  Tue Aug  5 15:01:54 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 5 Aug 2008 13:01:54 +0000
Subject: [M3devel] pixmap problem
Message-ID: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>



Randy, I'm pretty clueless here.
I don't do gui or graphics.
If anyone has a clue, please stand up.
If you can get us code to run, please do.
But I think I need multiple particularly configured machines too.

I'm curious what this code prints on the systems:

#include
#include

int main()
{
int pix_ver = { 0 };
int pix_hor = { 0 };
int mm_hor = { 0 };
int mm_ver = { 0 };
HWND hwnd = { 0 };
HDC hdc = { 0 };

hwnd = GetDesktopWindow();
hdc = GetDC(hwnd);
mm_hor = GetDeviceCaps(hdc, HORZSIZE);
mm_ver = GetDeviceCaps(hdc, VERTSIZE);
pix_hor = GetSystemMetrics(SM_CXSCREEN);
pix_ver = GetSystemMetrics(SM_CYSCREEN);

printf("horizonal pixels %d\n", pix_hor);
printf("veritical pixels SM_CYSCREEN %d\n", pix_ver);
printf("horizontal millimeters %d\n", mm_hor);
printf("veritical millimeters %d\n", mm_ver);

printf("horizontal pixels per millimeter %f\n", (((float) pix_hor) / ((float) mm_hor)));
printf("vertical pixels per millimeter %f\n", (((float) pix_ver) / ((float) mm_ver)));

printf("horizontal pixels per inch %f\n", (((float) pix_hor) / ((float) mm_hor) * 10.0 * 2.54));
printf("vertical pixels per inch %f\n", (((float) pix_ver) / ((float) mm_ver) * 10.0 * 2.54));

return 0;
}


for me:

$ gcc dpi.c -luser32 -lgdi32

jay at jay-win9 /dev2/j/dpi
$ ./a
horizonal pixels 1280
veritical pixels SM_CYSCREEN 800
horizontal millimeters 384
veritical millimeters 240
horizontal pixels per millimeter 3.333333
vertical pixels per millimeter 3.333333
horizontal pixels per inch 84.666667
vertical pixels per inch 84.666667

(Visual C++ is fine:
cl dpi.c user32.lib gdi32.lib
.\dpi
)

I wonder if lying in this code:

Searching for 'GetDeviceCaps'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(25): VAR res := NEW(T); n_colors := GetDeviceCaps (WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(32): res.depth := GetDeviceCaps(WinGDI.BITSPIXEL); (* John Karnak 8/3/98 *)
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(68): mm_hor = GetDeviceCaps (WinGDI.HORZSIZE),
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(69): mm_ver = GetDeviceCaps (WinGDI.VERTSIZE) DO

Searching for 'res.res[Axis.T.'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(71): res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(72): res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);


D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(89):PROCEDURE GetDeviceCaps (cap: Ctypes.int): INTEGER =
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(93): res := WinGDI.GetDeviceCaps (hdc, cap);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(98): END GetDeviceCaps;
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnColorMap.m3(268): cnt := WinGDI.GetDeviceCaps (hdc, WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnFont.m3(316): LogicalPixelsPerVertInch := WinGDI.GetDeviceCaps(er.hdc, WinGDI.LOGPIXELSY);
9 occurrence(s) have been found.


Searching for '1000.0'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(463): bmih.biXPelsPerMeter := ROUND (st.res[Axis.T.Hor] * 1000.0);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(464): bmih.biYPelsPerMeter := ROUND (st.res[Axis.T.Ver] * 1000.0);


and just claiming 96dpi is the way to go.
Can you try that??


Specifically try setting res.res[Axis.T.Hor] and .Ver to 3.779527559055118.
Or heck to 3.3333 like my laptop has.


Or maybe claiming ignorance and setting biXPelsPerMeter and biYPelsPerMeter to 0???
Claiming ignorance feels better than lying of course. :)

Hm, so throw in also:

printf("LogicalPixelsX %u\n", GetDeviceCaps(hdc, LOGPIXELSX));
printf("LogicalPixelsY %u\n", GetDeviceCaps(hdc, LOGPIXELSY));

I get the magic number 96.

- Jay
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dpi.c
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080805/2ec540e4/attachment.c>

From dabenavidesd at yahoo.es  Tue Aug  5 15:02:28 2008
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 5 Aug 2008 13:02:28 +0000 (GMT)
Subject: [M3devel] screen shots of pixmap problem
In-Reply-To: <489399D1.1E75.00D7.1@scires.com>
Message-ID: <46113.94040.qm@web27103.mail.ukl.yahoo.com>

Dear Randy:
Could you try to check (with cm3ide)
http://localhost:3800/public/vbtkit/src/lego/Image.i3/Raw#_DECL_ (or just on cm3/m3-ui/vbtkit/src/lego/Image.i3 )
see that line 43 has 
xres, yres: REAL := 75.0; (* in pixels per inch *) 
which is set from the sourcecode (not from the runtime variables).
you can calulate with 1920x1200 screen resolution pixels per inch
first, you apply pythogorean theorem with both catets 
Dp=sqrt(Wp^2+Wh^2)
Then PPI(or Pixels Per inch)=Dp/Di
where Di is the diagonal size in inches (the screen size), as Wikipedia says:
http://en.wikipedia.org/wiki/Pixels_per_inch
?In my case a SyncMaster 753DFX the PPI=96.42351792840054493 (Iguess the monitor you have should have more, rigth?). So you should fixed if needed the PPI rate in the source code or maybe use another variable that has the correct value.

I hope this helps, let me know
Thanks


--- El vie, 1/8/08, Randy Coleburn <rcoleburn at scires.com> escribi?:
De: Randy Coleburn <rcoleburn at scires.com>
Asunto: [M3devel] screen shots of pixmap problem
Para: m3devel at elegosoft.com
Fecha: viernes, 1 agosto, 2008 10:18


 
I managed to get the customer to grab a few screen images that illustrate the pixmap problem we are having.? These screen shots supplied by the customer don't show the full extent of the pixmap problem, but I do think they show the basic issues.? Quality of the bitmaps isn't great, but I think it illustrates the problem.? 
?
I think my whole application is fairly sophisticated in its use of Trestle/FormsVBT.? After the delivery, I'll try to provide the community with a portfolio of pictures we can add to the web site to show the capability of Trestle/FormsVBT.
?
The attached ZIP file contains the following files:
1.? splash_1440.bmp = the startup splash screen bitmap viewed at 1440x900 resolution.
?
2.? splash_1920.bmp = same bitmap as #1, but viewed at 1920x1200 resolution.? It is huge compared to #1.? Normally, when you increase resolution on the same screen, the images get smaller, but this time they get larger.
?
3.? aoi_1440.bmp = one of the windows viewed at 1440x900 resolution.
?
4.? aoi_1920.bmp = same window viewed at 1920x1200 resolution.? Notice that the black triangles in front of Polygon and Minutes are huge.? The text seems to be scaling fine, but the bitmaps are scaling much larger to be out of proportion with the text.? Also notice that the choice radio buttons in the Coordinates block are enlarged out of proportion.? If you look at the numeric in the lower right corner you will notice that the numeric text is elevated in the pixmap background rather than centered.? This is because the pixmap has been enlarged.? 
?
Hope these screen shots help illustrate the types of problems I am having.? I have another window that has a number of Boolean choice boxes on it.? When you go to 1920x1200 these boolean pixmaps get enlarged so much that the window won't fit vertically on the screen anymore.? The OK, Close, Cancel buttons actually show off the screen, so the user can't even complete the interaction.? This same window at 1440x900 or lower looks fine and fits on the screen with no issue.
?
Any insight folks can supply on how to resolve this issue would be appreciated.
?
Regards,
Randy


      ______________________________________________ 
Enviado desde Correo Yahoo! La bandeja de entrada m?s inteligente.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080805/054f3fd5/attachment.html>

From rcoleburn at scires.com  Tue Aug  5 16:00:54 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Tue, 05 Aug 2008 10:00:54 -0400
Subject: [M3devel] screen shots of pixmap problem
In-Reply-To: <46113.94040.qm@web27103.mail.ukl.yahoo.com>
References: <489399D1.1E75.00D7.1@scires.com>
	<46113.94040.qm@web27103.mail.ukl.yahoo.com>
Message-ID: <489824D0.1E75.00D7.1@scires.com>

Daniel:
 
Thanks, I will check this out today.
 
In my experience, the normal dpi setting on most all Windows computers
is 96 dpi.  If the source is fixing it at 75 dpi, that would be a
problem.
 
Regards,
Randy

>>> "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> 8/5/2008
9:02 AM >>>

Dear Randy:
Could you try to check (with cm3ide)
http://localhost:3800/public/vbtkit/src/lego/Image.i3/Raw#_DECL_ (or
just on cm3/m3-ui/vbtkit/src/lego/Image.i3 )
see that line 43 has 
xres, yres: REAL := 75.0; (* in pixels per inch *) 
which is set from the sourcecode (not from the runtime variables).
you can calulate with 1920x1200 screen resolution pixels per inch
first, you apply pythogorean theorem with both catets 
Dp=sqrt(Wp^2+Wh^2)
Then PPI(or Pixels Per inch)=Dp/Di
where Di is the diagonal size in inches (the screen size), as Wikipedia
says:
http://en.wikipedia.org/wiki/Pixels_per_inch 
 In my case a SyncMaster 753DFX the PPI=96.42351792840054493 (Iguess
the monitor you have should have more, rigth?). So you should fixed if
needed the PPI rate in the source code or maybe use another variable
that has the correct value.

I hope this helps, let me know
Thanks


--- El vie, 1/8/08, Randy Coleburn <rcoleburn at scires.com> escribi?:


De: Randy Coleburn <rcoleburn at scires.com>
Asunto: [M3devel] screen shots of pixmap problem
Para: m3devel at elegosoft.com 
Fecha: viernes, 1 agosto, 2008 10:18

I managed to get the customer to grab a few screen images that
illustrate the pixmap problem we are having.  These screen shots
supplied by the customer don't show the full extent of the pixmap
problem, but I do think they show the basic issues.  Quality of the
bitmaps isn't great, but I think it illustrates the problem.  
 
I think my whole application is fairly sophisticated in its use of
Trestle/FormsVBT.  After the delivery, I'll try to provide the community
with a portfolio of pictures we can add to the web site to show the
capability of Trestle/FormsVBT.
 
The attached ZIP file contains the following files:
1.  splash_1440.bmp = the startup splash screen bitmap viewed at
1440x900 resolution.
 
2.  splash_1920.bmp = same bitmap as #1, but viewed at 1920x1200
resolution.  It is huge compared to #1.  Normally, when you increase
resolution on the same screen, the images get smaller, but this time
they get larger.
 
3.  aoi_1440.bmp = one of the windows viewed at 1440x900 resolution.
 
4.  aoi_1920.bmp = same window viewed at 1920x1200 resolution.  Notice
that the black triangles in front of Polygon and Minutes are huge.  The
text seems to be scaling fine, but the bitmaps are scaling much larger
to be out of proportion with the text.  Also notice that the choice
radio buttons in the Coordinates block are enlarged out of proportion. 
If you look at the numeric in the lower right corner you will notice
that the numeric text is elevated in the pixmap background rather than
centered.  This is because the pixmap has been enlarged.  
 
Hope these screen shots help illustrate the types of problems I am
having.  I have another window that has a number of Boolean choice boxes
on it.  When you go to 1920x1200 these boolean pixmaps get enlarged so
much that the window won't fit vertically on the screen anymore.  The
OK, Close, Cancel buttons actually show off the screen, so the user
can't even complete the interaction.  This same window at 1440x900 or
lower looks fine and fits on the screen with no issue.
 
Any insight folks can supply on how to resolve this issue would be
appreciated.
 
Regards,
Randy



Enviado desde Correo Yahoo! (
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
)
La bandeja de entrada m?s inteligente.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080805/4f349ebe/attachment.html>

From rcoleburn at scires.com  Fri Aug  8 01:22:39 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Thu, 07 Aug 2008 19:22:39 -0400
Subject: [M3devel] pixmap problem
In-Reply-To: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>
References: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>
Message-ID: <489B4B79.1E75.00D7.1@scires.com>

Jay, I ran your program on a Lenovo/IBM ThinkPad T60 running at 1280x1024 resolution.  Here are the results:
 
horizonal pixels 1280
veritical pixels SM_CYSCREEN 1024
horizontal millimeters 375
veritical millimeters 300
horizontal pixels per millimeter 3.413333
vertical pixels per millimeter 3.413333
horizontal pixels per inch 86.698667
vertical pixels per inch 86.698667
 
I tried to run this program on the Dell M4300 system at 1920x1200, but I'm running into some stupid Microsoft problem.  I installed the VC_Redist, but it still doesn't work on this system.  Not sure what is wrong yet.
 
Regards,
Randy

>>> Jay <jayk123 at hotmail.com> 8/5/2008 9:01 AM >>>


Randy, I'm pretty clueless here.
I don't do gui or graphics.
If anyone has a clue, please stand up.
If you can get us code to run, please do.
But I think I need multiple particularly configured machines too.

I'm curious what this code prints on the systems:

#include
#include

int main()
{
int pix_ver = { 0 };
int pix_hor = { 0 };
int mm_hor = { 0 };
int mm_ver = { 0 };
HWND hwnd = { 0 };
HDC hdc = { 0 };

hwnd = GetDesktopWindow();
hdc = GetDC(hwnd);
mm_hor = GetDeviceCaps(hdc, HORZSIZE);
mm_ver = GetDeviceCaps(hdc, VERTSIZE);
pix_hor = GetSystemMetrics(SM_CXSCREEN);
pix_ver = GetSystemMetrics(SM_CYSCREEN);

printf("horizonal pixels %d\n", pix_hor);
printf("veritical pixels SM_CYSCREEN %d\n", pix_ver);
printf("horizontal millimeters %d\n", mm_hor);
printf("veritical millimeters %d\n", mm_ver);

printf("horizontal pixels per millimeter %f\n", (((float) pix_hor) / ((float) mm_hor)));
printf("vertical pixels per millimeter %f\n", (((float) pix_ver) / ((float) mm_ver)));

printf("horizontal pixels per inch %f\n", (((float) pix_hor) / ((float) mm_hor) * 10.0 * 2.54));
printf("vertical pixels per inch %f\n", (((float) pix_ver) / ((float) mm_ver) * 10.0 * 2.54));

return 0;
}


for me:

$ gcc dpi.c -luser32 -lgdi32

jay at jay-win9 /dev2/j/dpi
$ ./a
horizonal pixels 1280
veritical pixels SM_CYSCREEN 800
horizontal millimeters 384
veritical millimeters 240
horizontal pixels per millimeter 3.333333
vertical pixels per millimeter 3.333333
horizontal pixels per inch 84.666667
vertical pixels per inch 84.666667

(Visual C++ is fine:
cl dpi.c user32.lib gdi32.lib
.\dpi
)

I wonder if lying in this code:

Searching for 'GetDeviceCaps'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(25): VAR res := NEW(T); n_colors := GetDeviceCaps (WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(32): res.depth := GetDeviceCaps(WinGDI.BITSPIXEL); (* John Karnak 8/3/98 *)
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(68): mm_hor = GetDeviceCaps (WinGDI.HORZSIZE),
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(69): mm_ver = GetDeviceCaps (WinGDI.VERTSIZE) DO

Searching for 'res.res[Axis.T.'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(71): res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(72): res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);


D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(89):PROCEDURE GetDeviceCaps (cap: Ctypes.int): INTEGER =
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(93): res := WinGDI.GetDeviceCaps (hdc, cap);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(98): END GetDeviceCaps;
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnColorMap.m3(268): cnt := WinGDI.GetDeviceCaps (hdc, WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnFont.m3(316): LogicalPixelsPerVertInch := WinGDI.GetDeviceCaps(er.hdc, WinGDI.LOGPIXELSY);
9 occurrence(s) have been found.


Searching for '1000.0'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(463): bmih.biXPelsPerMeter := ROUND (st.res[Axis.T.Hor] * 1000.0);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(464): bmih.biYPelsPerMeter := ROUND (st.res[Axis.T.Ver] * 1000.0);


and just claiming 96dpi is the way to go.
Can you try that??


Specifically try setting res.res[Axis.T.Hor] and .Ver to 3.779527559055118.
Or heck to 3.3333 like my laptop has.


Or maybe claiming ignorance and setting biXPelsPerMeter and biYPelsPerMeter to 0???
Claiming ignorance feels better than lying of course. :)

Hm, so throw in also:

printf("LogicalPixelsX %u\n", GetDeviceCaps(hdc, LOGPIXELSX));
printf("LogicalPixelsY %u\n", GetDeviceCaps(hdc, LOGPIXELSY));

I get the magic number 96.

- Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080807/734b84fd/attachment.html>

From jayk123 at hotmail.com  Fri Aug  8 01:33:09 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 7 Aug 2008 23:33:09 +0000
Subject: [M3devel] pixmap problem
In-Reply-To: <489B4B79.1E75.00D7.1@scires.com>
References: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>
	<489B4B79.1E75.00D7.1@scires.com>
Message-ID: <COL101-W61DE171DBB93FC8E684658E6750@phx.gbl>


Randy, this might be useful, or it might be yanking your chain and wasting your time. I don't know.


Please try this:

Run my C code on "both" machines/settings, one that looks right, one that looks wrong.
Actually I'm not going to use that data as far as I can figure now, but I am curious.
Look at the Modula-3 code I showed, like where GetDeviceCaps is called.
Try out some hardcoded values.
See what the effect is on the display.
Bigger numbers look better?
Small numbers look better?
No difference?


Then again..I don't think the Modula-3 code any "scaling" ever, not of pixmaps,
probably not of text.
What it could do is pick different fonts, scale squares and other polygons, and
scale the location of pixmaps. It could perhaps scale their dimensions and let
underlying code scale. I have to look into this. But it'll be a bit.

If you see any calls to GetSystemMetrics in the Modula-3, dork around with those too.


 - Jay



________________________________

Date: Thu, 7 Aug 2008 19:22:39 -0400
From: rcoleburn at scires.com
To: m3devel at elegosoft.com; jayk123 at hotmail.com
Subject: Re: [M3devel] pixmap problem



Jay, I ran your program on a Lenovo/IBM ThinkPad T60 running at 1280x1024 resolution.  Here are the results:



horizonal pixels 1280
veritical pixels SM_CYSCREEN 1024
horizontal millimeters 375
veritical millimeters 300
horizontal pixels per millimeter 3.413333
vertical pixels per millimeter 3.413333
horizontal pixels per inch 86.698667
vertical pixels per inch 86.698667



I tried to run this program on the Dell M4300 system at 1920x1200, but I'm running into some stupid Microsoft problem.  I installed the VC_Redist, but it still doesn't work on this system.  Not sure what is wrong yet.



Regards,

Randy

>>> Jay  8/5/2008 9:01 AM>>>


Randy, I'm pretty clueless here.
I don't do gui or graphics.
If anyone has a clue, please stand up.
If you can get us code to run, please do.
But I think I need multiple particularly configured machines too.

I'm curious what this code prints on the systems:

#include
#include

int main()
{
int pix_ver = { 0 };
int pix_hor = { 0 };
int mm_hor = { 0 };
int mm_ver = { 0 };
HWND hwnd = { 0 };
HDC hdc = { 0 };

hwnd = GetDesktopWindow();
hdc = GetDC(hwnd);
mm_hor = GetDeviceCaps(hdc, HORZSIZE);
mm_ver = GetDeviceCaps(hdc, VERTSIZE);
pix_hor = GetSystemMetrics(SM_CXSCREEN);
pix_ver = GetSystemMetrics(SM_CYSCREEN);

printf("horizonal pixels %d\n", pix_hor);
printf("veritical pixels SM_CYSCREEN %d\n", pix_ver);
printf("horizontal millimeters %d\n", mm_hor);
printf("veritical millimeters %d\n", mm_ver);

printf("horizontal pixels per millimeter %f\n", (((float) pix_hor) / ((float) mm_hor)));
printf("vertical pixels per millimeter %f\n", (((float) pix_ver) / ((float) mm_ver)));

printf("horizontal pixels per inch %f\n", (((float) pix_hor) / ((float) mm_hor) * 10.0 * 2.54));
printf("vertical pixels per inch %f\n", (((float) pix_ver) / ((float) mm_ver) * 10.0 * 2.54));

return 0;
}


for me:

$ gcc dpi.c -luser32 -lgdi32

jay at jay-win9 /dev2/j/dpi
$ ./a
horizonal pixels 1280
veritical pixels SM_CYSCREEN 800
horizontal millimeters 384
veritical millimeters 240
horizontal pixels per millimeter 3.333333
vertical pixels per millimeter 3.333333
horizontal pixels per inch 84.666667
vertical pixels per inch 84.666667

(Visual C++ is fine:
cl dpi.c user32.lib gdi32.lib
.\dpi
)

I wonder if lying in this code:

Searching for 'GetDeviceCaps'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(25): VAR res := NEW(T); n_colors := GetDeviceCaps (WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(32): res.depth := GetDeviceCaps(WinGDI.BITSPIXEL); (* John Karnak 8/3/98 *)
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(68): mm_hor = GetDeviceCaps (WinGDI.HORZSIZE),
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(69): mm_ver = GetDeviceCaps (WinGDI.VERTSIZE) DO

Searching for 'res.res[Axis.T.'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(71): res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(72): res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);


D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(89):PROCEDURE GetDeviceCaps (cap: Ctypes.int): INTEGER =
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(93): res := WinGDI.GetDeviceCaps (hdc, cap);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(98): END GetDeviceCaps;
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnColorMap.m3(268): cnt := WinGDI.GetDeviceCaps (hdc, WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnFont.m3(316): LogicalPixelsPerVertInch := WinGDI.GetDeviceCaps(er.hdc, WinGDI.LOGPIXELSY);
9 occurrence(s) have been found.


Searching for '1000.0'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(463): bmih.biXPelsPerMeter := ROUND (st.res[Axis.T.Hor] * 1000.0);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(464): bmih.biYPelsPerMeter := ROUND (st.res[Axis.T.Ver] * 1000.0);


and just claiming 96dpi is the way to go.
Can you try that??


Specifically try setting res.res[Axis.T.Hor] and .Ver to 3.779527559055118.
Or heck to 3.3333 like my laptop has.


Or maybe claiming ignorance and setting biXPelsPerMeter and biYPelsPerMeter to 0???
Claiming ignorance feels better than lying of course. :)

Hm, so throw in also:

printf("LogicalPixelsX %u\n", GetDeviceCaps(hdc, LOGPIXELSX));
printf("LogicalPixelsY %u\n", GetDeviceCaps(hdc, LOGPIXELSY));

I get the magic number 96.

- Jay


From rcoleburn at scires.com  Fri Aug  8 01:42:33 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Thu, 07 Aug 2008 19:42:33 -0400
Subject: [M3devel] pixmap problem (some success)
In-Reply-To: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>
References: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>
Message-ID: <489B5023.1E75.00D7.1@scires.com>

Ok, I solved the Microsoft problem.
 
Here are the results on Dell M4300 at 1920x1200:
 
horizonal pixels 1920
veritical pixels SM_CYSCREEN 1200
horizontal millimeters 330
veritical millimeters 206
horizontal pixels per millimeter 5.818182
vertical pixels per millimeter 5.825243
horizontal pixels per inch 147.781818
vertical pixels per inch 147.961165
Wow!  these numbers are radically different than the IBM T60 at 1280x1024:
 
horizonal pixels 1280
veritical pixels SM_CYSCREEN 1024
horizontal millimeters 375
veritical millimeters 300
horizontal pixels per millimeter 3.413333
vertical pixels per millimeter 3.413333
horizontal pixels per inch 86.698667
vertical pixels per inch 86.698667
Now, if you look at the Windows dpi setting for the 1920x1200 machine, it says 96dpi, but this is in the General tab of the Display properties Advanced settings.  I suspect this is just the dpi setting applied to fonts.
 
I tried plugging the numbers into Image.i3 as suggested by Daniel:
TYPE
  Raw = OBJECT
      width, height: INTEGER;
      xres: REAL := 147.781818; (* in pixels per inch *)
      yres: REAL := 147.961165; (* in pixels per inch *)
    METHODS
      get (h, v: INTEGER): Pixel;
      set (h, v: INTEGER; pixel: Pixel);
    END;
When I do this, my pixmaps look correct on the 1920x1200 display!!!!!
 
Now, the problem I am faced with is how to come up with a way that the code will work on any type of monitor.  I can't edit Image.i3 for every resolution and produce a different binary.  Any ideas?
 
Regards,
Randy

>>> Jay <jayk123 at hotmail.com> 8/5/2008 9:01 AM >>>


Randy, I'm pretty clueless here.
I don't do gui or graphics.
If anyone has a clue, please stand up.
If you can get us code to run, please do.
But I think I need multiple particularly configured machines too.

I'm curious what this code prints on the systems:

#include
#include

int main()
{
int pix_ver = { 0 };
int pix_hor = { 0 };
int mm_hor = { 0 };
int mm_ver = { 0 };
HWND hwnd = { 0 };
HDC hdc = { 0 };

hwnd = GetDesktopWindow();
hdc = GetDC(hwnd);
mm_hor = GetDeviceCaps(hdc, HORZSIZE);
mm_ver = GetDeviceCaps(hdc, VERTSIZE);
pix_hor = GetSystemMetrics(SM_CXSCREEN);
pix_ver = GetSystemMetrics(SM_CYSCREEN);

printf("horizonal pixels %d\n", pix_hor);
printf("veritical pixels SM_CYSCREEN %d\n", pix_ver);
printf("horizontal millimeters %d\n", mm_hor);
printf("veritical millimeters %d\n", mm_ver);

printf("horizontal pixels per millimeter %f\n", (((float) pix_hor) / ((float) mm_hor)));
printf("vertical pixels per millimeter %f\n", (((float) pix_ver) / ((float) mm_ver)));

printf("horizontal pixels per inch %f\n", (((float) pix_hor) / ((float) mm_hor) * 10.0 * 2.54));
printf("vertical pixels per inch %f\n", (((float) pix_ver) / ((float) mm_ver) * 10.0 * 2.54));

return 0;
}


for me:

$ gcc dpi.c -luser32 -lgdi32

jay at jay-win9 /dev2/j/dpi
$ ./a
horizonal pixels 1280
veritical pixels SM_CYSCREEN 800
horizontal millimeters 384
veritical millimeters 240
horizontal pixels per millimeter 3.333333
vertical pixels per millimeter 3.333333
horizontal pixels per inch 84.666667
vertical pixels per inch 84.666667

(Visual C++ is fine:
cl dpi.c user32.lib gdi32.lib
.\dpi
)

I wonder if lying in this code:

Searching for 'GetDeviceCaps'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(25): VAR res := NEW(T); n_colors := GetDeviceCaps (WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(32): res.depth := GetDeviceCaps(WinGDI.BITSPIXEL); (* John Karnak 8/3/98 *)
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(68): mm_hor = GetDeviceCaps (WinGDI.HORZSIZE),
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(69): mm_ver = GetDeviceCaps (WinGDI.VERTSIZE) DO

Searching for 'res.res[Axis.T.'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(71): res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(72): res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);


D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(89):PROCEDURE GetDeviceCaps (cap: Ctypes.int): INTEGER =
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(93): res := WinGDI.GetDeviceCaps (hdc, cap);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(98): END GetDeviceCaps;
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnColorMap.m3(268): cnt := WinGDI.GetDeviceCaps (hdc, WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnFont.m3(316): LogicalPixelsPerVertInch := WinGDI.GetDeviceCaps(er.hdc, WinGDI.LOGPIXELSY);
9 occurrence(s) have been found.


Searching for '1000.0'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(463): bmih.biXPelsPerMeter := ROUND (st.res[Axis.T.Hor] * 1000.0);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(464): bmih.biYPelsPerMeter := ROUND (st.res[Axis.T.Ver] * 1000.0);


and just claiming 96dpi is the way to go.
Can you try that??


Specifically try setting res.res[Axis.T.Hor] and .Ver to 3.779527559055118.
Or heck to 3.3333 like my laptop has.


Or maybe claiming ignorance and setting biXPelsPerMeter and biYPelsPerMeter to 0???
Claiming ignorance feels better than lying of course. :)

Hm, so throw in also:

printf("LogicalPixelsX %u\n", GetDeviceCaps(hdc, LOGPIXELSX));
printf("LogicalPixelsY %u\n", GetDeviceCaps(hdc, LOGPIXELSY));

I get the magic number 96.

- Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080807/86bd50b5/attachment.html>

From jayk123 at hotmail.com  Fri Aug  8 02:12:24 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 8 Aug 2008 00:12:24 +0000
Subject: [M3devel] pixmap problem
In-Reply-To: <489B4B79.1E75.00D7.1@scires.com>
References: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>
	<489B4B79.1E75.00D7.1@scires.com> 
Message-ID: <COL101-W9A274E937044BF90CB8B0E6740@phx.gbl>


 > Then again..I don't think the Modula-3 code any "scaling" ever, not of pixmaps, 
False.
 
m3-ui\vbtkit\src\lego\Image.m3 is very much in the business of scalling.
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080808/982de9d6/attachment.html>

From jayk123 at hotmail.com  Fri Aug  8 02:16:49 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 8 Aug 2008 00:16:49 +0000
Subject: [M3devel] pixmap problem (some success)
In-Reply-To: <489B5023.1E75.00D7.1@scires.com>
References: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>
	<489B5023.1E75.00D7.1@scires.com>
Message-ID: <COL101-W279710F3EF9B814B1DA853E6740@phx.gbl>


Awesome. I expect it is easy from here. Thanks David!

I *assume* the 75 should have been 86 in the one case,
but close enough that nobody noticed.
So these numbers come pretty directly from the GetDeviceCaps / GetSystemMetrics.

And then X Windows too.
Does anyone have a high DPI monitor running X Windows?
Probably easy enough to do this blind.

I'm trying to ignore the fact that systems have multiple
monitors, with varying dpi. You are supposed to loop your
drawing over monitors and compute what it looks like per-monitor.
I'm just making that up, right? :)

 - Jay

________________________________

Date: Thu, 7 Aug 2008 19:42:33 -0400
From: rcoleburn at scires.com
To: m3devel at elegosoft.com; jayk123 at hotmail.com; dabenavidesd at yahoo.es
Subject: Re: [M3devel] pixmap problem (some success)



Ok, I solved the Microsoft problem.



Here are the results on Dell M4300 at 1920x1200:



horizonal pixels 1920
veritical pixels SM_CYSCREEN 1200
horizontal millimeters 330
veritical millimeters 206
horizontal pixels per millimeter 5.818182
vertical pixels per millimeter 5.825243
horizontal pixels per inch 147.781818
vertical pixels per inch 147.961165

Wow!  these numbers are radically different than the IBM T60 at 1280x1024:



horizonal pixels 1280
veritical pixels SM_CYSCREEN 1024
horizontal millimeters 375
veritical millimeters 300
horizontal pixels per millimeter 3.413333
vertical pixels per millimeter 3.413333
horizontal pixels per inch 86.698667
vertical pixels per inch 86.698667

Now, if you look at the Windows dpi setting for the 1920x1200 machine, it says 96dpi, but this is in the General tab of the Display properties Advanced settings.  I suspect this is just the dpi setting applied to fonts.



I tried plugging the numbers into Image.i3 as suggested by Daniel:

TYPE
  Raw = OBJECT
      width, height: INTEGER;
      xres: REAL := 147.781818; (* in pixels per inch *)
      yres: REAL := 147.961165; (* in pixels per inch *)
    METHODS
      get (h, v: INTEGER): Pixel;
      set (h, v: INTEGER; pixel: Pixel);
    END;

When I do this, my pixmaps look correct on the 1920x1200 display!!!!!



Now, the problem I am faced with is how to come up with a way that the code will work on any type of monitor.  I can't edit Image.i3 for every resolution and produce a different binary.  Any ideas?



Regards,

Randy


>>> Jay  8/5/2008 9:01 AM>>>


Randy, I'm pretty clueless here.
I don't do gui or graphics.
If anyone has a clue, please stand up.
If you can get us code to run, please do.
But I think I need multiple particularly configured machines too.

I'm curious what this code prints on the systems:

#include
#include

int main()
{
int pix_ver = { 0 };
int pix_hor = { 0 };
int mm_hor = { 0 };
int mm_ver = { 0 };
HWND hwnd = { 0 };
HDC hdc = { 0 };

hwnd = GetDesktopWindow();
hdc = GetDC(hwnd);
mm_hor = GetDeviceCaps(hdc, HORZSIZE);
mm_ver = GetDeviceCaps(hdc, VERTSIZE);
pix_hor = GetSystemMetrics(SM_CXSCREEN);
pix_ver = GetSystemMetrics(SM_CYSCREEN);

printf("horizonal pixels %d\n", pix_hor);
printf("veritical pixels SM_CYSCREEN %d\n", pix_ver);
printf("horizontal millimeters %d\n", mm_hor);
printf("veritical millimeters %d\n", mm_ver);

printf("horizontal pixels per millimeter %f\n", (((float) pix_hor) / ((float) mm_hor)));
printf("vertical pixels per millimeter %f\n", (((float) pix_ver) / ((float) mm_ver)));

printf("horizontal pixels per inch %f\n", (((float) pix_hor) / ((float) mm_hor) * 10.0 * 2.54));
printf("vertical pixels per inch %f\n", (((float) pix_ver) / ((float) mm_ver) * 10.0 * 2.54));

return 0;
}


for me:

$ gcc dpi.c -luser32 -lgdi32

jay at jay-win9 /dev2/j/dpi
$ ./a
horizonal pixels 1280
veritical pixels SM_CYSCREEN 800
horizontal millimeters 384
veritical millimeters 240
horizontal pixels per millimeter 3.333333
vertical pixels per millimeter 3.333333
horizontal pixels per inch 84.666667
vertical pixels per inch 84.666667

(Visual C++ is fine:
cl dpi.c user32.lib gdi32.lib
.\dpi
)

I wonder if lying in this code:

Searching for 'GetDeviceCaps'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(25): VAR res := NEW(T); n_colors := GetDeviceCaps (WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(32): res.depth := GetDeviceCaps(WinGDI.BITSPIXEL); (* John Karnak 8/3/98 *)
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(68): mm_hor = GetDeviceCaps (WinGDI.HORZSIZE),
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(69): mm_ver = GetDeviceCaps (WinGDI.VERTSIZE) DO

Searching for 'res.res[Axis.T.'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(71): res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(72): res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);


D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(89):PROCEDURE GetDeviceCaps (cap: Ctypes.int): INTEGER =
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(93): res := WinGDI.GetDeviceCaps (hdc, cap);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(98): END GetDeviceCaps;
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnColorMap.m3(268): cnt := WinGDI.GetDeviceCaps (hdc, WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnFont.m3(316): LogicalPixelsPerVertInch := WinGDI.GetDeviceCaps(er.hdc, WinGDI.LOGPIXELSY);
9 occurrence(s) have been found.


Searching for '1000.0'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(463): bmih.biXPelsPerMeter := ROUND (st.res[Axis.T.Hor] * 1000.0);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(464): bmih.biYPelsPerMeter := ROUND (st.res[Axis.T.Ver] * 1000.0);


and just claiming 96dpi is the way to go.
Can you try that??


Specifically try setting res.res[Axis.T.Hor] and .Ver to 3.779527559055118.
Or heck to 3.3333 like my laptop has.


Or maybe claiming ignorance and setting biXPelsPerMeter and biYPelsPerMeter to 0???
Claiming ignorance feels better than lying of course. :)

Hm, so throw in also:

printf("LogicalPixelsX %u\n", GetDeviceCaps(hdc, LOGPIXELSX));
printf("LogicalPixelsY %u\n", GetDeviceCaps(hdc, LOGPIXELSY));

I get the magic number 96.

- Jay


From rcoleburn at scires.com  Fri Aug  8 02:26:13 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Thu, 07 Aug 2008 20:26:13 -0400
Subject: [M3devel] pixmap problem (some success)
In-Reply-To: <COL101-W279710F3EF9B814B1DA853E6740@phx.gbl>
References: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>
	<489B5023.1E75.00D7.1@scires.com>
	<COL101-W279710F3EF9B814B1DA853E6740@phx.gbl>
Message-ID: <489B5A5F.1E75.00D7.1@scires.com>

Well, I hope to soon share your optimism for "easy".  
 
Since these numbers wind up being default values for the xres/yres and since changing the defaults has made a big difference in the results, it would seem that most code must not be computing these, but relying on the default values to be correct.  
 
Since these numbers may be different for every program run on a different monitor (potentially), the question becomes how to effect a change that will work in all cases without having to recompile vbtkit.
 
Does this mean we have to track down each use of Image.Raw and put in code to compute the dpi?  Or is there some way we can do this during an initialization sequence? but alas, how to deal with the defaults supplied in the declaration?
 
Regards,
Randy

>>> Jay <jayk123 at hotmail.com> 8/7/2008 8:16 PM >>>

Awesome. I expect it is easy from here. Thanks David!

I *assume* the 75 should have been 86 in the one case,
but close enough that nobody noticed.
So these numbers come pretty directly from the GetDeviceCaps / GetSystemMetrics.

And then X Windows too.
Does anyone have a high DPI monitor running X Windows?
Probably easy enough to do this blind.

I'm trying to ignore the fact that systems have multiple
monitors, with varying dpi. You are supposed to loop your
drawing over monitors and compute what it looks like per-monitor.
I'm just making that up, right? :)

- Jay

________________________________

Date: Thu, 7 Aug 2008 19:42:33 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com; jayk123 at hotmail.com; dabenavidesd at yahoo.es 
Subject: Re: [M3devel] pixmap problem (some success)



Ok, I solved the Microsoft problem.



Here are the results on Dell M4300 at 1920x1200:



horizonal pixels 1920
veritical pixels SM_CYSCREEN 1200
horizontal millimeters 330
veritical millimeters 206
horizontal pixels per millimeter 5.818182
vertical pixels per millimeter 5.825243
horizontal pixels per inch 147.781818
vertical pixels per inch 147.961165

Wow!  these numbers are radically different than the IBM T60 at 1280x1024:



horizonal pixels 1280
veritical pixels SM_CYSCREEN 1024
horizontal millimeters 375
veritical millimeters 300
horizontal pixels per millimeter 3.413333
vertical pixels per millimeter 3.413333
horizontal pixels per inch 86.698667
vertical pixels per inch 86.698667

Now, if you look at the Windows dpi setting for the 1920x1200 machine, it says 96dpi, but this is in the General tab of the Display properties Advanced settings.  I suspect this is just the dpi setting applied to fonts.



I tried plugging the numbers into Image.i3 as suggested by Daniel:

TYPE
  Raw = OBJECT
      width, height: INTEGER;
      xres: REAL := 147.781818; (* in pixels per inch *)
      yres: REAL := 147.961165; (* in pixels per inch *)
    METHODS
      get (h, v: INTEGER): Pixel;
      set (h, v: INTEGER; pixel: Pixel);
    END;

When I do this, my pixmaps look correct on the 1920x1200 display!!!!!



Now, the problem I am faced with is how to come up with a way that the code will work on any type of monitor.  I can't edit Image.i3 for every resolution and produce a different binary.  Any ideas?



Regards,

Randy


>>> Jay  8/5/2008 9:01 AM>>>


Randy, I'm pretty clueless here.
I don't do gui or graphics.
If anyone has a clue, please stand up.
If you can get us code to run, please do.
But I think I need multiple particularly configured machines too.

I'm curious what this code prints on the systems:

#include
#include

int main()
{
int pix_ver = { 0 };
int pix_hor = { 0 };
int mm_hor = { 0 };
int mm_ver = { 0 };
HWND hwnd = { 0 };
HDC hdc = { 0 };

hwnd = GetDesktopWindow();
hdc = GetDC(hwnd);
mm_hor = GetDeviceCaps(hdc, HORZSIZE);
mm_ver = GetDeviceCaps(hdc, VERTSIZE);
pix_hor = GetSystemMetrics(SM_CXSCREEN);
pix_ver = GetSystemMetrics(SM_CYSCREEN);

printf("horizonal pixels %d\n", pix_hor);
printf("veritical pixels SM_CYSCREEN %d\n", pix_ver);
printf("horizontal millimeters %d\n", mm_hor);
printf("veritical millimeters %d\n", mm_ver);

printf("horizontal pixels per millimeter %f\n", (((float) pix_hor) / ((float) mm_hor)));
printf("vertical pixels per millimeter %f\n", (((float) pix_ver) / ((float) mm_ver)));

printf("horizontal pixels per inch %f\n", (((float) pix_hor) / ((float) mm_hor) * 10.0 * 2.54));
printf("vertical pixels per inch %f\n", (((float) pix_ver) / ((float) mm_ver) * 10.0 * 2.54));

return 0;
}


for me:

$ gcc dpi.c -luser32 -lgdi32

jay at jay-win9 /dev2/j/dpi
$ ./a
horizonal pixels 1280
veritical pixels SM_CYSCREEN 800
horizontal millimeters 384
veritical millimeters 240
horizontal pixels per millimeter 3.333333
vertical pixels per millimeter 3.333333
horizontal pixels per inch 84.666667
vertical pixels per inch 84.666667

(Visual C++ is fine:
cl dpi.c user32.lib gdi32.lib
.\dpi
)

I wonder if lying in this code:

Searching for 'GetDeviceCaps'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(25): VAR res := NEW(T); n_colors := GetDeviceCaps (WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(32): res.depth := GetDeviceCaps(WinGDI.BITSPIXEL); (* John Karnak 8/3/98 *)
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(68): mm_hor = GetDeviceCaps (WinGDI.HORZSIZE),
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(69): mm_ver = GetDeviceCaps (WinGDI.VERTSIZE) DO

Searching for 'res.res[Axis.T.'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(71): res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(72): res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);


D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(89):PROCEDURE GetDeviceCaps (cap: Ctypes.int): INTEGER =
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(93): res := WinGDI.GetDeviceCaps (hdc, cap);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(98): END GetDeviceCaps;
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnColorMap.m3(268): cnt := WinGDI.GetDeviceCaps (hdc, WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnFont.m3(316): LogicalPixelsPerVertInch := WinGDI.GetDeviceCaps(er.hdc, WinGDI.LOGPIXELSY);
9 occurrence(s) have been found.


Searching for '1000.0'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(463): bmih.biXPelsPerMeter := ROUND (st.res[Axis.T.Hor] * 1000.0);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(464): bmih.biYPelsPerMeter := ROUND (st.res[Axis.T.Ver] * 1000.0);


and just claiming 96dpi is the way to go.
Can you try that??


Specifically try setting res.res[Axis.T.Hor] and .Ver to 3.779527559055118.
Or heck to 3.3333 like my laptop has.


Or maybe claiming ignorance and setting biXPelsPerMeter and biYPelsPerMeter to 0???
Claiming ignorance feels better than lying of course. :)

Hm, so throw in also:

printf("LogicalPixelsX %u\n", GetDeviceCaps(hdc, LOGPIXELSX));
printf("LogicalPixelsY %u\n", GetDeviceCaps(hdc, LOGPIXELSY));

I get the magic number 96.

- Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080807/576a96e4/attachment.html>

From jayk123 at hotmail.com  Fri Aug  8 03:35:10 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 8 Aug 2008 01:35:10 +0000
Subject: [M3devel] pixmap problem (some success)
In-Reply-To: <489B5A5F.1E75.00D7.1@scires.com>
References: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>
	<489B5023.1E75.00D7.1@scires.com>
	<COL101-W279710F3EF9B814B1DA853E6740@phx.gbl> 
	<489B5A5F.1E75.00D7.1@scires.com>
Message-ID: <COL101-W76DCEA23FC2EA0FD299A3DE6740@phx.gbl>


Computing the values is probably easy. It appears we already have the code to do that -- the program I had you run and report the numbers.

It is true there is a *small* problem of computing them early enough, but..yeah, I expect that's just done in the module initializer. I really don't like "global initialization" code ala C++ global constructors/destructors, but Modula-3 is rife with them and they aren't going away, so I'll just pile in a few more bits.

I don't know if is legal Modula-3 code, but if fields can be initialized from globals, that's about all it takes.

SOMETHING LIKE (don't castigate me where I am wrong)
In the platform-independent code, add two private globals:
DefaultXRes : INTEGER;
DefaultYRes : INTEGER;

heck, default them to 75, for the Posix case.

In the platform independent interface, functions to set them:
PROCEDURE SetDefaultXRes(a: INTEGER);
PROCEDURE SetDefaultYRes(a: INTEGER);

Nothing else on Posix, for now.

On Windows, add another module WinImage.m3 that imports Image and just has a module initializer:

BEGIN
  Image.SetDefaultXRes(ComputedSomehowNotDifficult());
  Image.SetDefaultYRes(ComputedSomehowNotDifficult());
END.

If fields cannot be initialized from globals (or function calls..heh, that has a niceness!), then you have to search out all the uses and change them to function calls, possibly a lot, possibly tedious, definitely a "breaking change", but probably just fine, really.

And then, if fields can be initialized from functions, that'd be better -- that way no module initializer.


Module initializers are "bad" in that they cause a startup cost for "everyone", even if they aren't needed for a particular scenario. It is "best" imho to have constant initialization as much as possible, and where values must be computed, use an explicit function call when needed. You can still cache the values upon first computation.


> would seem that most code must not be computing these, but relying on the default values to be correct.

Or that "most code" doesn't care what the values are, doesn't use them at all.
Like, maybe they are only used for pixmaps and not text or lines?

Anyway, I can't look into this now, but hopefully "soon".
If your customer is antsy, "the problem is mostly understood and a fix will definitely be available soon".
I think "patch Tuesday" is coming up. Let's make it by then? :)


Really, I can't believe they'd call for a rewrite over this small issue.
Presumably they really want the rewrite and are looking for any excuse they can find.
Also, if you removed the "advertising" from the splash screen, they might not have even noticed?
Or, I guess if this is Windows only, the odd look could not be noticed.
But if they also want it on X and you showed it there, and it looked the same on Windows, well...
(Really this is just a general dilemna -- app looks the same as app on all platforms, or app looks like the platform on all platforms.)


 - Jay

________________________________

Date: Thu, 7 Aug 2008 20:26:13 -0400
From: rcoleburn at scires.com
To: m3devel at elegosoft.com; jayk123 at hotmail.com; dabenavidesd at yahoo.es
Subject: RE: [M3devel] pixmap problem (some success)



Well, I hope to soon share your optimism for "easy".



Since these numbers wind up being default values for the xres/yres and since changing the defaults has made a big difference in the results, it would seem that most code must not be computing these, but relying on the default values to be correct.



Since these numbers may be different for every program run on a different monitor (potentially), the question becomes how to effect a change that will work in all cases without having to recompile vbtkit.



Does this mean we have to track down each use of Image.Raw and put in code to compute the dpi?  Or is there some way we can do this during an initialization sequence? but alas, how to deal with the defaults supplied in the declaration?



Regards,

Randy

>>> Jay  8/7/2008 8:16 PM>>>

Awesome. I expect it is easy from here. Thanks David!

I *assume* the 75 should have been 86 in the one case,
but close enough that nobody noticed.
So these numbers come pretty directly from the GetDeviceCaps / GetSystemMetrics.

And then X Windows too.
Does anyone have a high DPI monitor running X Windows?
Probably easy enough to do this blind.

I'm trying to ignore the fact that systems have multiple
monitors, with varying dpi. You are supposed to loop your
drawing over monitors and compute what it looks like per-monitor.
I'm just making that up, right? :)

- Jay

________________________________

Date: Thu, 7 Aug 2008 19:42:33 -0400
From: rcoleburn at scires.com
To: m3devel at elegosoft.com; jayk123 at hotmail.com; dabenavidesd at yahoo.es
Subject: Re: [M3devel] pixmap problem (some success)



Ok, I solved the Microsoft problem.



Here are the results on Dell M4300 at 1920x1200:



horizonal pixels 1920
veritical pixels SM_CYSCREEN 1200
horizontal millimeters 330
veritical millimeters 206
horizontal pixels per millimeter 5.818182
vertical pixels per millimeter 5.825243
horizontal pixels per inch 147.781818
vertical pixels per inch 147.961165

Wow!  these numbers are radically different than the IBM T60 at 1280x1024:



horizonal pixels 1280
veritical pixels SM_CYSCREEN 1024
horizontal millimeters 375
veritical millimeters 300
horizontal pixels per millimeter 3.413333
vertical pixels per millimeter 3.413333
horizontal pixels per inch 86.698667
vertical pixels per inch 86.698667

Now, if you look at the Windows dpi setting for the 1920x1200 machine, it says 96dpi, but this is in the General tab of the Display properties Advanced settings.  I suspect this is just the dpi setting applied to fonts.



I tried plugging the numbers into Image.i3 as suggested by Daniel:

TYPE
  Raw = OBJECT
      width, height: INTEGER;
      xres: REAL := 147.781818; (* in pixels per inch *)
      yres: REAL := 147.961165; (* in pixels per inch *)
    METHODS
      get (h, v: INTEGER): Pixel;
      set (h, v: INTEGER; pixel: Pixel);
    END;

When I do this, my pixmaps look correct on the 1920x1200 display!!!!!



Now, the problem I am faced with is how to come up with a way that the code will work on any type of monitor.  I can't edit Image.i3 for every resolution and produce a different binary.  Any ideas?



Regards,

Randy


>>> Jay  8/5/2008 9:01 AM>>>


Randy, I'm pretty clueless here.
I don't do gui or graphics.
If anyone has a clue, please stand up.
If you can get us code to run, please do.
But I think I need multiple particularly configured machines too.

I'm curious what this code prints on the systems:

#include
#include

int main()
{
int pix_ver = { 0 };
int pix_hor = { 0 };
int mm_hor = { 0 };
int mm_ver = { 0 };
HWND hwnd = { 0 };
HDC hdc = { 0 };

hwnd = GetDesktopWindow();
hdc = GetDC(hwnd);
mm_hor = GetDeviceCaps(hdc, HORZSIZE);
mm_ver = GetDeviceCaps(hdc, VERTSIZE);
pix_hor = GetSystemMetrics(SM_CXSCREEN);
pix_ver = GetSystemMetrics(SM_CYSCREEN);

printf("horizonal pixels %d\n", pix_hor);
printf("veritical pixels SM_CYSCREEN %d\n", pix_ver);
printf("horizontal millimeters %d\n", mm_hor);
printf("veritical millimeters %d\n", mm_ver);

printf("horizontal pixels per millimeter %f\n", (((float) pix_hor) / ((float) mm_hor)));
printf("vertical pixels per millimeter %f\n", (((float) pix_ver) / ((float) mm_ver)));

printf("horizontal pixels per inch %f\n", (((float) pix_hor) / ((float) mm_hor) * 10.0 * 2.54));
printf("vertical pixels per inch %f\n", (((float) pix_ver) / ((float) mm_ver) * 10.0 * 2.54));

return 0;
}


for me:

$ gcc dpi.c -luser32 -lgdi32

jay at jay-win9 /dev2/j/dpi
$ ./a
horizonal pixels 1280
veritical pixels SM_CYSCREEN 800
horizontal millimeters 384
veritical millimeters 240
horizontal pixels per millimeter 3.333333
vertical pixels per millimeter 3.333333
horizontal pixels per inch 84.666667
vertical pixels per inch 84.666667

(Visual C++ is fine:
cl dpi.c user32.lib gdi32.lib
.\dpi
)

I wonder if lying in this code:

Searching for 'GetDeviceCaps'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(25): VAR res := NEW(T); n_colors := GetDeviceCaps (WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(32): res.depth := GetDeviceCaps(WinGDI.BITSPIXEL); (* John Karnak 8/3/98 *)
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(68): mm_hor = GetDeviceCaps (WinGDI.HORZSIZE),
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(69): mm_ver = GetDeviceCaps (WinGDI.VERTSIZE) DO

Searching for 'res.res[Axis.T.'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(71): res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(72): res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);


D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(89):PROCEDURE GetDeviceCaps (cap: Ctypes.int): INTEGER =
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(93): res := WinGDI.GetDeviceCaps (hdc, cap);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(98): END GetDeviceCaps;
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnColorMap.m3(268): cnt := WinGDI.GetDeviceCaps (hdc, WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnFont.m3(316): LogicalPixelsPerVertInch := WinGDI.GetDeviceCaps(er.hdc, WinGDI.LOGPIXELSY);
9 occurrence(s) have been found.


Searching for '1000.0'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(463): bmih.biXPelsPerMeter := ROUND (st.res[Axis.T.Hor] * 1000.0);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(464): bmih.biYPelsPerMeter := ROUND (st.res[Axis.T.Ver] * 1000.0);


and just claiming 96dpi is the way to go.
Can you try that??


Specifically try setting res.res[Axis.T.Hor] and .Ver to 3.779527559055118.
Or heck to 3.3333 like my laptop has.


Or maybe claiming ignorance and setting biXPelsPerMeter and biYPelsPerMeter to 0???
Claiming ignorance feels better than lying of course. :)

Hm, so throw in also:

printf("LogicalPixelsX %u\n", GetDeviceCaps(hdc, LOGPIXELSX));
printf("LogicalPixelsY %u\n", GetDeviceCaps(hdc, LOGPIXELSY));

I get the magic number 96.

- Jay



From rcoleburn at scires.com  Fri Aug  8 03:59:07 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Thu, 07 Aug 2008 21:59:07 -0400
Subject: [M3devel] pixmap problem (some success)
In-Reply-To: <COL101-W76DCEA23FC2EA0FD299A3DE6740@phx.gbl>
References: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>
	<489B5023.1E75.00D7.1@scires.com>
	<COL101-W279710F3EF9B814B1DA853E6740@phx.gbl>
	<489B5A5F.1E75.00D7.1@scires.com>
	<COL101-W76DCEA23FC2EA0FD299A3DE6740@phx.gbl>
Message-ID: <489B7025.1E75.00D7.1@scires.com>

Jay,
 
The splash screen is not the major issue.  The pixmaps used for boolean choices, radio choices, numerics, etc. get enlarged to the point that some windows won't fit on the screen.  Also, it looks really bad--like both a first-grader with a big marker and a college-student with a fine tip pencil worked on the same window.
 
I've tried very hard to make Trestle/FormsVBT look and act like Windows GUI, but it is indeed different.  For example, on menus, you have to hold down the mouse to keep the menu open.  All these were small issues 10 years ago, but now they seem to be looming large in the customer's mind.
 
So, bottom line is that if I can't fix what they deem to be functional problems, they will indeed call for a rewrite.
 
Now that we've got the typein problem solved (thanks Olaf) and are on track for the pixmap issue, I feel better.  I have recently discovered that the numeric keys on the numeric keypad aren't accepted, so I have yet to track that problem down.
 
As for your idea of using a variable as the default initializer for xres/yres, this is not legal Modula-3.  You will get a compile error that the default is not constant.  Otherwise, it was a good idea.
 
Since Raw is an object and objects are created dynamically and new subtypes can be created (inheritance), I think the problem of how to properly set xres/yres is complicated.
 
Seems like what we need is some way to adjust these fields when the object is created initially.  Alas, Raw does not have an init() method!
 
Regards,
Randy

>>> Jay <jayk123 at hotmail.com> 8/7/2008 9:35 PM >>>

Computing the values is probably easy. It appears we already have the code to do that -- the program I had you run and report the numbers.

It is true there is a *small* problem of computing them early enough, but..yeah, I expect that's just done in the module initializer. I really don't like "global initialization" code ala C++ global constructors/destructors, but Modula-3 is rife with them and they aren't going away, so I'll just pile in a few more bits.

I don't know if is legal Modula-3 code, but if fields can be initialized from globals, that's about all it takes.

SOMETHING LIKE (don't castigate me where I am wrong)
In the platform-independent code, add two private globals:
DefaultXRes : INTEGER;
DefaultYRes : INTEGER;

heck, default them to 75, for the Posix case.

In the platform independent interface, functions to set them:
PROCEDURE SetDefaultXRes(a: INTEGER);
PROCEDURE SetDefaultYRes(a: INTEGER);

Nothing else on Posix, for now.

On Windows, add another module WinImage.m3 that imports Image and just has a module initializer:

BEGIN
  Image.SetDefaultXRes(ComputedSomehowNotDifficult());
  Image.SetDefaultYRes(ComputedSomehowNotDifficult());
END.

If fields cannot be initialized from globals (or function calls..heh, that has a niceness!), then you have to search out all the uses and change them to function calls, possibly a lot, possibly tedious, definitely a "breaking change", but probably just fine, really.

And then, if fields can be initialized from functions, that'd be better -- that way no module initializer.


Module initializers are "bad" in that they cause a startup cost for "everyone", even if they aren't needed for a particular scenario. It is "best" imho to have constant initialization as much as possible, and where values must be computed, use an explicit function call when needed. You can still cache the values upon first computation.


> would seem that most code must not be computing these, but relying on the default values to be correct.

Or that "most code" doesn't care what the values are, doesn't use them at all.
Like, maybe they are only used for pixmaps and not text or lines?

Anyway, I can't look into this now, but hopefully "soon".
If your customer is antsy, "the problem is mostly understood and a fix will definitely be available soon".
I think "patch Tuesday" is coming up. Let's make it by then? :)


Really, I can't believe they'd call for a rewrite over this small issue.
Presumably they really want the rewrite and are looking for any excuse they can find.
Also, if you removed the "advertising" from the splash screen, they might not have even noticed?
Or, I guess if this is Windows only, the odd look could not be noticed.
But if they also want it on X and you showed it there, and it looked the same on Windows, well...
(Really this is just a general dilemna -- app looks the same as app on all platforms, or app looks like the platform on all platforms.)


- Jay

________________________________

Date: Thu, 7 Aug 2008 20:26:13 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com; jayk123 at hotmail.com; dabenavidesd at yahoo.es 
Subject: RE: [M3devel] pixmap problem (some success)



Well, I hope to soon share your optimism for "easy".



Since these numbers wind up being default values for the xres/yres and since changing the defaults has made a big difference in the results, it would seem that most code must not be computing these, but relying on the default values to be correct.



Since these numbers may be different for every program run on a different monitor (potentially), the question becomes how to effect a change that will work in all cases without having to recompile vbtkit.



Does this mean we have to track down each use of Image.Raw and put in code to compute the dpi?  Or is there some way we can do this during an initialization sequence? but alas, how to deal with the defaults supplied in the declaration?



Regards,

Randy

>>> Jay  8/7/2008 8:16 PM>>>

Awesome. I expect it is easy from here. Thanks David!

I *assume* the 75 should have been 86 in the one case,
but close enough that nobody noticed.
So these numbers come pretty directly from the GetDeviceCaps / GetSystemMetrics.

And then X Windows too.
Does anyone have a high DPI monitor running X Windows?
Probably easy enough to do this blind.

I'm trying to ignore the fact that systems have multiple
monitors, with varying dpi. You are supposed to loop your
drawing over monitors and compute what it looks like per-monitor.
I'm just making that up, right? :)

- Jay

________________________________

Date: Thu, 7 Aug 2008 19:42:33 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com; jayk123 at hotmail.com; dabenavidesd at yahoo.es 
Subject: Re: [M3devel] pixmap problem (some success)



Ok, I solved the Microsoft problem.



Here are the results on Dell M4300 at 1920x1200:



horizonal pixels 1920
veritical pixels SM_CYSCREEN 1200
horizontal millimeters 330
veritical millimeters 206
horizontal pixels per millimeter 5.818182
vertical pixels per millimeter 5.825243
horizontal pixels per inch 147.781818
vertical pixels per inch 147.961165

Wow!  these numbers are radically different than the IBM T60 at 1280x1024:



horizonal pixels 1280
veritical pixels SM_CYSCREEN 1024
horizontal millimeters 375
veritical millimeters 300
horizontal pixels per millimeter 3.413333
vertical pixels per millimeter 3.413333
horizontal pixels per inch 86.698667
vertical pixels per inch 86.698667

Now, if you look at the Windows dpi setting for the 1920x1200 machine, it says 96dpi, but this is in the General tab of the Display properties Advanced settings.  I suspect this is just the dpi setting applied to fonts.



I tried plugging the numbers into Image.i3 as suggested by Daniel:

TYPE
  Raw = OBJECT
      width, height: INTEGER;
      xres: REAL := 147.781818; (* in pixels per inch *)
      yres: REAL := 147.961165; (* in pixels per inch *)
    METHODS
      get (h, v: INTEGER): Pixel;
      set (h, v: INTEGER; pixel: Pixel);
    END;

When I do this, my pixmaps look correct on the 1920x1200 display!!!!!



Now, the problem I am faced with is how to come up with a way that the code will work on any type of monitor.  I can't edit Image.i3 for every resolution and produce a different binary.  Any ideas?



Regards,

Randy


>>> Jay  8/5/2008 9:01 AM>>>


Randy, I'm pretty clueless here.
I don't do gui or graphics.
If anyone has a clue, please stand up.
If you can get us code to run, please do.
But I think I need multiple particularly configured machines too.

I'm curious what this code prints on the systems:

#include
#include

int main()
{
int pix_ver = { 0 };
int pix_hor = { 0 };
int mm_hor = { 0 };
int mm_ver = { 0 };
HWND hwnd = { 0 };
HDC hdc = { 0 };

hwnd = GetDesktopWindow();
hdc = GetDC(hwnd);
mm_hor = GetDeviceCaps(hdc, HORZSIZE);
mm_ver = GetDeviceCaps(hdc, VERTSIZE);
pix_hor = GetSystemMetrics(SM_CXSCREEN);
pix_ver = GetSystemMetrics(SM_CYSCREEN);

printf("horizonal pixels %d\n", pix_hor);
printf("veritical pixels SM_CYSCREEN %d\n", pix_ver);
printf("horizontal millimeters %d\n", mm_hor);
printf("veritical millimeters %d\n", mm_ver);

printf("horizontal pixels per millimeter %f\n", (((float) pix_hor) / ((float) mm_hor)));
printf("vertical pixels per millimeter %f\n", (((float) pix_ver) / ((float) mm_ver)));

printf("horizontal pixels per inch %f\n", (((float) pix_hor) / ((float) mm_hor) * 10.0 * 2.54));
printf("vertical pixels per inch %f\n", (((float) pix_ver) / ((float) mm_ver) * 10.0 * 2.54));

return 0;
}


for me:

$ gcc dpi.c -luser32 -lgdi32

jay at jay-win9 /dev2/j/dpi
$ ./a
horizonal pixels 1280
veritical pixels SM_CYSCREEN 800
horizontal millimeters 384
veritical millimeters 240
horizontal pixels per millimeter 3.333333
vertical pixels per millimeter 3.333333
horizontal pixels per inch 84.666667
vertical pixels per inch 84.666667

(Visual C++ is fine:
cl dpi.c user32.lib gdi32.lib
.\dpi
)

I wonder if lying in this code:

Searching for 'GetDeviceCaps'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(25): VAR res := NEW(T); n_colors := GetDeviceCaps (WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(32): res.depth := GetDeviceCaps(WinGDI.BITSPIXEL); (* John Karnak 8/3/98 *)
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(68): mm_hor = GetDeviceCaps (WinGDI.HORZSIZE),
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(69): mm_ver = GetDeviceCaps (WinGDI.VERTSIZE) DO

Searching for 'res.res[Axis.T.'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(71): res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(72): res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);


D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(89):PROCEDURE GetDeviceCaps (cap: Ctypes.int): INTEGER =
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(93): res := WinGDI.GetDeviceCaps (hdc, cap);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(98): END GetDeviceCaps;
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnColorMap.m3(268): cnt := WinGDI.GetDeviceCaps (hdc, WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnFont.m3(316): LogicalPixelsPerVertInch := WinGDI.GetDeviceCaps(er.hdc, WinGDI.LOGPIXELSY);
9 occurrence(s) have been found.


Searching for '1000.0'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(463): bmih.biXPelsPerMeter := ROUND (st.res[Axis.T.Hor] * 1000.0);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(464): bmih.biYPelsPerMeter := ROUND (st.res[Axis.T.Ver] * 1000.0);


and just claiming 96dpi is the way to go.
Can you try that??


Specifically try setting res.res[Axis.T.Hor] and .Ver to 3.779527559055118.
Or heck to 3.3333 like my laptop has.


Or maybe claiming ignorance and setting biXPelsPerMeter and biYPelsPerMeter to 0???
Claiming ignorance feels better than lying of course. :)

Hm, so throw in also:

printf("LogicalPixelsX %u\n", GetDeviceCaps(hdc, LOGPIXELSX));
printf("LogicalPixelsY %u\n", GetDeviceCaps(hdc, LOGPIXELSY));

I get the magic number 96.

- Jay


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080807/9548b783/attachment.html>

From jayk123 at hotmail.com  Fri Aug  8 16:05:15 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 8 Aug 2008 14:05:15 +0000
Subject: [M3devel] pixmap problem (some success)
In-Reply-To: <489B7025.1E75.00D7.1@scires.com>
References: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>
	<489B5023.1E75.00D7.1@scires.com>
	<COL101-W279710F3EF9B814B1DA853E6740@phx.gbl>
	<489B5A5F.1E75.00D7.1@scires.com>
	<COL101-W76DCEA23FC2EA0FD299A3DE6740@phx.gbl> 
	<489B7025.1E75.00D7.1@scires.com>
Message-ID: <COL101-W49AB1574C557B5343D724DE6740@phx.gbl>


I committed a possible fix here.
Please see how it fairs.

I have a few Modula-3 questions related to the fix.

 - Did I have to expose the functions in the .i3 file
  that implement the methods? That seems "wrong".


   - Could I have used "stronger language opacity" instead
    of "informal privacy"? That is, could I have used an
    opaque type?

   - Will the change break pickles?
     "Both" due to the addition of data "or" methods?
     ie: What breaks pickles?
     Do I need to think in the mindset of
      C:
       typedef struct {
         int a,b;
       } foo_t;

       foo_t f;
       fwrite(&f, sizeof(f), 1, file);

      and not breaking such code? 
     Only if the type is "branded"? Or if types derived from it are branded?
        There could be derived types not in the cm3 tree though.
        How much do we care about breaking code outside the cm3 tree?
        e.g. in this change, I had to change every use of .xres and .yres.
       I did that, but only in the code "we have". There could be more out there.
       Personally, I get quite frustrated by this issue. I'm very willng to "fix"
        and maybe test pretty large amounts of code -- pay the price for fixing things with
        "breaking" changes, or else not make the change, but if I don't have the code, I can't.

  If this breaks pickles, I can restate the fix in a slightly "weaker" way,
    that has some risk of missing code paths, but will likely suffice.

    That is, initialize to a distinguished value like 0 or -1
     and get rid of the booleans. And, i necessary for pickling,
     put the fields back out in "public".


 The name of the ImageInit module, I wonder what it should be.


   - Jay
     


________________________________

Date: Thu, 7 Aug 2008 21:59:07 -0400
From: rcoleburn at scires.com
To: m3devel at elegosoft.com; jayk123 at hotmail.com; dabenavidesd at yahoo.es
Subject: RE: [M3devel] pixmap problem (some success)



Jay,



The splash screen is not the major issue.  The pixmaps used for boolean choices, radio choices, numerics, etc. get enlarged to the point that some windows won't fit on the screen.  Also, it looks really bad--like both a first-grader with a big marker and a college-student with a fine tip pencil worked on the same window.



I've tried very hard to make Trestle/FormsVBT look and act like Windows GUI, but it is indeed different.  For example, on menus, you have to hold down the mouse to keep the menu open.  All these were small issues 10 years ago, but now they seem to be looming large in the customer's mind.



So, bottom line is that if I can't fix what they deem to be functional problems, they will indeed call for a rewrite.



Now that we've got the typein problem solved (thanks Olaf) and are on track for the pixmap issue, I feel better.  I have recently discovered that the numeric keys on the numeric keypad aren't accepted, so I have yet to track that problem down.



As for your idea of using a variable as the default initializer for xres/yres, this is not legal Modula-3.  You will get a compile error that the default is not constant.  Otherwise, it was a good idea.



Since Raw is an object and objects are created dynamically and new subtypes can be created (inheritance), I think the problem of how to properly set xres/yres is complicated.



Seems like what we need is some way to adjust these fields when the object is created initially.  Alas, Raw does not have an init() method!



Regards,

Randy

>>> Jay  8/7/2008 9:35 PM>>>

Computing the values is probably easy. It appears we already have the code to do that -- the program I had you run and report the numbers.

It is true there is a *small* problem of computing them early enough, but..yeah, I expect that's just done in the module initializer. I really don't like "global initialization" code ala C++ global constructors/destructors, but Modula-3 is rife with them and they aren't going away, so I'll just pile in a few more bits.

I don't know if is legal Modula-3 code, but if fields can be initialized from globals, that's about all it takes.

SOMETHING LIKE (don't castigate me where I am wrong)
In the platform-independent code, add two private globals:
DefaultXRes : INTEGER;
DefaultYRes : INTEGER;

heck, default them to 75, for the Posix case.

In the platform independent interface, functions to set them:
PROCEDURE SetDefaultXRes(a: INTEGER);
PROCEDURE SetDefaultYRes(a: INTEGER);

Nothing else on Posix, for now.

On Windows, add another module WinImage.m3 that imports Image and just has a module initializer:

BEGIN
  Image.SetDefaultXRes(ComputedSomehowNotDifficult());
  Image.SetDefaultYRes(ComputedSomehowNotDifficult());
END.

If fields cannot be initialized from globals (or function calls..heh, that has a niceness!), then you have to search out all the uses and change them to function calls, possibly a lot, possibly tedious, definitely a "breaking change", but probably just fine, really.

And then, if fields can be initialized from functions, that'd be better -- that way no module initializer.


Module initializers are "bad" in that they cause a startup cost for "everyone", even if they aren't needed for a particular scenario. It is "best" imho to have constant initialization as much as possible, and where values must be computed, use an explicit function call when needed. You can still cache the values upon first computation.


> would seem that most code must not be computing these, but relying on the default values to be correct.

Or that "most code" doesn't care what the values are, doesn't use them at all.
Like, maybe they are only used for pixmaps and not text or lines?

Anyway, I can't look into this now, but hopefully "soon".
If your customer is antsy, "the problem is mostly understood and a fix will definitely be available soon".
I think "patch Tuesday" is coming up. Let's make it by then? :)


Really, I can't believe they'd call for a rewrite over this small issue.
Presumably they really want the rewrite and are looking for any excuse they can find.
Also, if you removed the "advertising" from the splash screen, they might not have even noticed?
Or, I guess if this is Windows only, the odd look could not be noticed.
But if they also want it on X and you showed it there, and it looked the same on Windows, well...
(Really this is just a general dilemna -- app looks the same as app on all platforms, or app looks like the platform on all platforms.)


- Jay

________________________________

Date: Thu, 7 Aug 2008 20:26:13 -0400
From: rcoleburn at scires.com
To: m3devel at elegosoft.com; jayk123 at hotmail.com; dabenavidesd at yahoo.es
Subject: RE: [M3devel] pixmap problem (some success)



Well, I hope to soon share your optimism for "easy".



Since these numbers wind up being default values for the xres/yres and since changing the defaults has made a big difference in the results, it would seem that most code must not be computing these, but relying on the default values to be correct.



Since these numbers may be different for every program run on a different monitor (potentially), the question becomes how to effect a change that will work in all cases without having to recompile vbtkit.



Does this mean we have to track down each use of Image.Raw and put in code to compute the dpi?  Or is there some way we can do this during an initialization sequence? but alas, how to deal with the defaults supplied in the declaration?



Regards,

Randy

>>> Jay  8/7/2008 8:16 PM>>>

Awesome. I expect it is easy from here. Thanks David!

I *assume* the 75 should have been 86 in the one case,
but close enough that nobody noticed.
So these numbers come pretty directly from the GetDeviceCaps / GetSystemMetrics.

And then X Windows too.
Does anyone have a high DPI monitor running X Windows?
Probably easy enough to do this blind.

I'm trying to ignore the fact that systems have multiple
monitors, with varying dpi. You are supposed to loop your
drawing over monitors and compute what it looks like per-monitor.
I'm just making that up, right? :)

- Jay

________________________________

Date: Thu, 7 Aug 2008 19:42:33 -0400
From: rcoleburn at scires.com
To: m3devel at elegosoft.com; jayk123 at hotmail.com; dabenavidesd at yahoo.es
Subject: Re: [M3devel] pixmap problem (some success)



Ok, I solved the Microsoft problem.



Here are the results on Dell M4300 at 1920x1200:



horizonal pixels 1920
veritical pixels SM_CYSCREEN 1200
horizontal millimeters 330
veritical millimeters 206
horizontal pixels per millimeter 5.818182
vertical pixels per millimeter 5.825243
horizontal pixels per inch 147.781818
vertical pixels per inch 147.961165

Wow!  these numbers are radically different than the IBM T60 at 1280x1024:



horizonal pixels 1280
veritical pixels SM_CYSCREEN 1024
horizontal millimeters 375
veritical millimeters 300
horizontal pixels per millimeter 3.413333
vertical pixels per millimeter 3.413333
horizontal pixels per inch 86.698667
vertical pixels per inch 86.698667

Now, if you look at the Windows dpi setting for the 1920x1200 machine, it says 96dpi, but this is in the General tab of the Display properties Advanced settings.  I suspect this is just the dpi setting applied to fonts.



I tried plugging the numbers into Image.i3 as suggested by Daniel:

TYPE
  Raw = OBJECT
      width, height: INTEGER;
      xres: REAL := 147.781818; (* in pixels per inch *)
      yres: REAL := 147.961165; (* in pixels per inch *)
    METHODS
      get (h, v: INTEGER): Pixel;
      set (h, v: INTEGER; pixel: Pixel);
    END;

When I do this, my pixmaps look correct on the 1920x1200 display!!!!!



Now, the problem I am faced with is how to come up with a way that the code will work on any type of monitor.  I can't edit Image.i3 for every resolution and produce a different binary.  Any ideas?



Regards,

Randy


>>> Jay  8/5/2008 9:01 AM>>>


Randy, I'm pretty clueless here.
I don't do gui or graphics.
If anyone has a clue, please stand up.
If you can get us code to run, please do.
But I think I need multiple particularly configured machines too.

I'm curious what this code prints on the systems:

#include
#include

int main()
{
int pix_ver = { 0 };
int pix_hor = { 0 };
int mm_hor = { 0 };
int mm_ver = { 0 };
HWND hwnd = { 0 };
HDC hdc = { 0 };

hwnd = GetDesktopWindow();
hdc = GetDC(hwnd);
mm_hor = GetDeviceCaps(hdc, HORZSIZE);
mm_ver = GetDeviceCaps(hdc, VERTSIZE);
pix_hor = GetSystemMetrics(SM_CXSCREEN);
pix_ver = GetSystemMetrics(SM_CYSCREEN);

printf("horizonal pixels %d\n", pix_hor);
printf("veritical pixels SM_CYSCREEN %d\n", pix_ver);
printf("horizontal millimeters %d\n", mm_hor);
printf("veritical millimeters %d\n", mm_ver);

printf("horizontal pixels per millimeter %f\n", (((float) pix_hor) / ((float) mm_hor)));
printf("vertical pixels per millimeter %f\n", (((float) pix_ver) / ((float) mm_ver)));

printf("horizontal pixels per inch %f\n", (((float) pix_hor) / ((float) mm_hor) * 10.0 * 2.54));
printf("vertical pixels per inch %f\n", (((float) pix_ver) / ((float) mm_ver) * 10.0 * 2.54));

return 0;
}


for me:

$ gcc dpi.c -luser32 -lgdi32

jay at jay-win9 /dev2/j/dpi
$ ./a
horizonal pixels 1280
veritical pixels SM_CYSCREEN 800
horizontal millimeters 384
veritical millimeters 240
horizontal pixels per millimeter 3.333333
vertical pixels per millimeter 3.333333
horizontal pixels per inch 84.666667
vertical pixels per inch 84.666667

(Visual C++ is fine:
cl dpi.c user32.lib gdi32.lib
.\dpi
)

I wonder if lying in this code:

Searching for 'GetDeviceCaps'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(25): VAR res := NEW(T); n_colors := GetDeviceCaps (WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(32): res.depth := GetDeviceCaps(WinGDI.BITSPIXEL); (* John Karnak 8/3/98 *)
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(68): mm_hor = GetDeviceCaps (WinGDI.HORZSIZE),
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(69): mm_ver = GetDeviceCaps (WinGDI.VERTSIZE) DO

Searching for 'res.res[Axis.T.'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(71): res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(72): res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);


D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(89):PROCEDURE GetDeviceCaps (cap: Ctypes.int): INTEGER =
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(93): res := WinGDI.GetDeviceCaps (hdc, cap);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(98): END GetDeviceCaps;
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnColorMap.m3(268): cnt := WinGDI.GetDeviceCaps (hdc, WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnFont.m3(316): LogicalPixelsPerVertInch := WinGDI.GetDeviceCaps(er.hdc, WinGDI.LOGPIXELSY);
9 occurrence(s) have been found.


Searching for '1000.0'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(463): bmih.biXPelsPerMeter := ROUND (st.res[Axis.T.Hor] * 1000.0);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(464): bmih.biYPelsPerMeter := ROUND (st.res[Axis.T.Ver] * 1000.0);


and just claiming 96dpi is the way to go.
Can you try that??


Specifically try setting res.res[Axis.T.Hor] and .Ver to 3.779527559055118.
Or heck to 3.3333 like my laptop has.


Or maybe claiming ignorance and setting biXPelsPerMeter and biYPelsPerMeter to 0???
Claiming ignorance feels better than lying of course. :)

Hm, so throw in also:

printf("LogicalPixelsX %u\n", GetDeviceCaps(hdc, LOGPIXELSX));
printf("LogicalPixelsY %u\n", GetDeviceCaps(hdc, LOGPIXELSY));

I get the magic number 96.

- Jay




From rcoleburn at scires.com  Sat Aug  9 07:48:15 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Sat, 09 Aug 2008 01:48:15 -0400
Subject: [M3devel] pixmap problem (! big success !)
In-Reply-To: <COL101-W49AB1574C557B5343D724DE6740@phx.gbl>
References: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>
	<489B5023.1E75.00D7.1@scires.com>
	<COL101-W279710F3EF9B814B1DA853E6740@phx.gbl>
	<489B5A5F.1E75.00D7.1@scires.com>
	<COL101-W76DCEA23FC2EA0FD299A3DE6740@phx.gbl>
	<489B7025.1E75.00D7.1@scires.com>
	<COL101-W49AB1574C557B5343D724DE6740@phx.gbl>
Message-ID: <489CF759.1E75.00D7.1@scires.com>

Jay:
 
Thanks so much for your work on this issue!!!  In my sleep-deprived state I didn't think of switching these fields to be "accessor-based."
 
I've tested your changes and they seem to work fine for me.  I've rebuilt all of cm3 just to make sure there were no compile-time errors.
 
I also had to adjust my scroll bar implementation on Windows to scale the scroll bar slider.  (The slider was not a pixmap and was being drawn based on a default size in millimeters.  Since the arrow buttons at the top and bottom of the scroll bar are pixmaps, I had to ensure the slider and margins didn't exceed the width of these pixmaps.)  Your procedures in ImageInit made this easy for me.  The revised code is now checked into the repository.
 
I probably need to make the same fix to the slider in the Posix implementation, but since we aren't yet dealing with resolution differences on Posix, maybe it doesn't matter for now.  Also, there are no arrow buttons on the Posix scroll bar, so it will probably be okay to just let the slider be the default width in millimeters.  The reason I had trouble on Windows was that the slider was wider than the arrow pixmaps when rendered on the hi-res display.
 
After reflecting on your comments and discussion, I will volunteer with your kind permission to adjust your Image.i3/Image.m3 implementation to be "more in the spirit of Modula-3".  Namely, I do think it makes sense to make these fields truly opaque so that access must be governed by the methods.  I feel pretty good about the fact that your change didn't break any of the rest of the code in the cm3 tree, so I think there will be few, if any, code breaks in other client code.
 
Also, I did notice that in ImageInit.m3 you declare a global var "init" but never assign the default value of "FALSE" to this variable before it is tested in the two procedures.  Shouldn't this be set to FALSE, or are you relying on something of which I'm unaware?  
 
Also, in ImageInit.m3 you call WinNT.MemoryBarrier().  I looked in the WinNT.i3 file, but there is no comment describing this function.  I'm unfamiliar with this function, so I would welcome any explanation you can offer as to what it does.
 
As for pickles, I don't see how any of your changes would break pickles.  The pickler should still be able to pickle these types.  Of course, anyone who is using pickles will need to recompile to see the new format, but there should not be any source code changes required.
 
I also need to thank Daniel for cluing us into the pixmap scaling problem in the first place by pointing out the xres/yres constants of 75.0.
 
At some point, I do think it makes sense to make a similar set of fixes on Posix because I'm sure that the 75 dpi is not going to be accurate for most modern displays.  Of course, we will need to find a way to come up with the right value in a platform-independent way.
 
Regards,
Randy

>>> Jay <jayk123 at hotmail.com> 8/8/2008 10:05 AM >>>

I committed a possible fix here.
Please see how it fairs.

I have a few Modula-3 questions related to the fix.

- Did I have to expose the functions in the .i3 file
  that implement the methods? That seems "wrong".


   - Could I have used "stronger language opacity" instead
    of "informal privacy"? That is, could I have used an
    opaque type?

   - Will the change break pickles?
     "Both" due to the addition of data "or" methods?
     ie: What breaks pickles?
     Do I need to think in the mindset of
      C:
       typedef struct {
         int a,b;
       } foo_t;

       foo_t f;
       fwrite(&f, sizeof(f), 1, file);

      and not breaking such code? 
     Only if the type is "branded"? Or if types derived from it are branded?
        There could be derived types not in the cm3 tree though.
        How much do we care about breaking code outside the cm3 tree?
        e.g. in this change, I had to change every use of .xres and .yres.
       I did that, but only in the code "we have". There could be more out there.
       Personally, I get quite frustrated by this issue. I'm very willng to "fix"
        and maybe test pretty large amounts of code -- pay the price for fixing things with
        "breaking" changes, or else not make the change, but if I don't have the code, I can't.

  If this breaks pickles, I can restate the fix in a slightly "weaker" way,
    that has some risk of missing code paths, but will likely suffice.

    That is, initialize to a distinguished value like 0 or -1
     and get rid of the booleans. And, i necessary for pickling,
     put the fields back out in "public".


The name of the ImageInit module, I wonder what it should be.


   - Jay
     


________________________________

Date: Thu, 7 Aug 2008 21:59:07 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com; jayk123 at hotmail.com; dabenavidesd at yahoo.es 
Subject: RE: [M3devel] pixmap problem (some success)



Jay,



The splash screen is not the major issue.  The pixmaps used for boolean choices, radio choices, numerics, etc. get enlarged to the point that some windows won't fit on the screen.  Also, it looks really bad--like both a first-grader with a big marker and a college-student with a fine tip pencil worked on the same window.



I've tried very hard to make Trestle/FormsVBT look and act like Windows GUI, but it is indeed different.  For example, on menus, you have to hold down the mouse to keep the menu open.  All these were small issues 10 years ago, but now they seem to be looming large in the customer's mind.



So, bottom line is that if I can't fix what they deem to be functional problems, they will indeed call for a rewrite.



Now that we've got the typein problem solved (thanks Olaf) and are on track for the pixmap issue, I feel better.  I have recently discovered that the numeric keys on the numeric keypad aren't accepted, so I have yet to track that problem down.



As for your idea of using a variable as the default initializer for xres/yres, this is not legal Modula-3.  You will get a compile error that the default is not constant.  Otherwise, it was a good idea.



Since Raw is an object and objects are created dynamically and new subtypes can be created (inheritance), I think the problem of how to properly set xres/yres is complicated.



Seems like what we need is some way to adjust these fields when the object is created initially.  Alas, Raw does not have an init() method!



Regards,

Randy

>>> Jay  8/7/2008 9:35 PM>>>

Computing the values is probably easy. It appears we already have the code to do that -- the program I had you run and report the numbers.

It is true there is a *small* problem of computing them early enough, but..yeah, I expect that's just done in the module initializer. I really don't like "global initialization" code ala C++ global constructors/destructors, but Modula-3 is rife with them and they aren't going away, so I'll just pile in a few more bits.

I don't know if is legal Modula-3 code, but if fields can be initialized from globals, that's about all it takes.

SOMETHING LIKE (don't castigate me where I am wrong)
In the platform-independent code, add two private globals:
DefaultXRes : INTEGER;
DefaultYRes : INTEGER;

heck, default them to 75, for the Posix case.

In the platform independent interface, functions to set them:
PROCEDURE SetDefaultXRes(a: INTEGER);
PROCEDURE SetDefaultYRes(a: INTEGER);

Nothing else on Posix, for now.

On Windows, add another module WinImage.m3 that imports Image and just has a module initializer:

BEGIN
  Image.SetDefaultXRes(ComputedSomehowNotDifficult());
  Image.SetDefaultYRes(ComputedSomehowNotDifficult());
END.

If fields cannot be initialized from globals (or function calls..heh, that has a niceness!), then you have to search out all the uses and change them to function calls, possibly a lot, possibly tedious, definitely a "breaking change", but probably just fine, really.

And then, if fields can be initialized from functions, that'd be better -- that way no module initializer.


Module initializers are "bad" in that they cause a startup cost for "everyone", even if they aren't needed for a particular scenario. It is "best" imho to have constant initialization as much as possible, and where values must be computed, use an explicit function call when needed. You can still cache the values upon first computation.


> would seem that most code must not be computing these, but relying on the default values to be correct.

Or that "most code" doesn't care what the values are, doesn't use them at all.
Like, maybe they are only used for pixmaps and not text or lines?

Anyway, I can't look into this now, but hopefully "soon".
If your customer is antsy, "the problem is mostly understood and a fix will definitely be available soon".
I think "patch Tuesday" is coming up. Let's make it by then? :)


Really, I can't believe they'd call for a rewrite over this small issue.
Presumably they really want the rewrite and are looking for any excuse they can find.
Also, if you removed the "advertising" from the splash screen, they might not have even noticed?
Or, I guess if this is Windows only, the odd look could not be noticed.
But if they also want it on X and you showed it there, and it looked the same on Windows, well...
(Really this is just a general dilemna -- app looks the same as app on all platforms, or app looks like the platform on all platforms.)


- Jay

________________________________

Date: Thu, 7 Aug 2008 20:26:13 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com; jayk123 at hotmail.com; dabenavidesd at yahoo.es 
Subject: RE: [M3devel] pixmap problem (some success)



Well, I hope to soon share your optimism for "easy".



Since these numbers wind up being default values for the xres/yres and since changing the defaults has made a big difference in the results, it would seem that most code must not be computing these, but relying on the default values to be correct.



Since these numbers may be different for every program run on a different monitor (potentially), the question becomes how to effect a change that will work in all cases without having to recompile vbtkit.



Does this mean we have to track down each use of Image.Raw and put in code to compute the dpi?  Or is there some way we can do this during an initialization sequence? but alas, how to deal with the defaults supplied in the declaration?



Regards,

Randy

>>> Jay  8/7/2008 8:16 PM>>>

Awesome. I expect it is easy from here. Thanks David!

I *assume* the 75 should have been 86 in the one case,
but close enough that nobody noticed.
So these numbers come pretty directly from the GetDeviceCaps / GetSystemMetrics.

And then X Windows too.
Does anyone have a high DPI monitor running X Windows?
Probably easy enough to do this blind.

I'm trying to ignore the fact that systems have multiple
monitors, with varying dpi. You are supposed to loop your
drawing over monitors and compute what it looks like per-monitor.
I'm just making that up, right? :)

- Jay

________________________________

Date: Thu, 7 Aug 2008 19:42:33 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com; jayk123 at hotmail.com; dabenavidesd at yahoo.es 
Subject: Re: [M3devel] pixmap problem (some success)



Ok, I solved the Microsoft problem.



Here are the results on Dell M4300 at 1920x1200:



horizonal pixels 1920
veritical pixels SM_CYSCREEN 1200
horizontal millimeters 330
veritical millimeters 206
horizontal pixels per millimeter 5.818182
vertical pixels per millimeter 5.825243
horizontal pixels per inch 147.781818
vertical pixels per inch 147.961165

Wow!  these numbers are radically different than the IBM T60 at 1280x1024:



horizonal pixels 1280
veritical pixels SM_CYSCREEN 1024
horizontal millimeters 375
veritical millimeters 300
horizontal pixels per millimeter 3.413333
vertical pixels per millimeter 3.413333
horizontal pixels per inch 86.698667
vertical pixels per inch 86.698667

Now, if you look at the Windows dpi setting for the 1920x1200 machine, it says 96dpi, but this is in the General tab of the Display properties Advanced settings.  I suspect this is just the dpi setting applied to fonts.



I tried plugging the numbers into Image.i3 as suggested by Daniel:

TYPE
  Raw = OBJECT
      width, height: INTEGER;
      xres: REAL := 147.781818; (* in pixels per inch *)
      yres: REAL := 147.961165; (* in pixels per inch *)
    METHODS
      get (h, v: INTEGER): Pixel;
      set (h, v: INTEGER; pixel: Pixel);
    END;

When I do this, my pixmaps look correct on the 1920x1200 display!!!!!



Now, the problem I am faced with is how to come up with a way that the code will work on any type of monitor.  I can't edit Image.i3 for every resolution and produce a different binary.  Any ideas?



Regards,

Randy


>>> Jay  8/5/2008 9:01 AM>>>


Randy, I'm pretty clueless here.
I don't do gui or graphics.
If anyone has a clue, please stand up.
If you can get us code to run, please do.
But I think I need multiple particularly configured machines too.

I'm curious what this code prints on the systems:

#include
#include

int main()
{
int pix_ver = { 0 };
int pix_hor = { 0 };
int mm_hor = { 0 };
int mm_ver = { 0 };
HWND hwnd = { 0 };
HDC hdc = { 0 };

hwnd = GetDesktopWindow();
hdc = GetDC(hwnd);
mm_hor = GetDeviceCaps(hdc, HORZSIZE);
mm_ver = GetDeviceCaps(hdc, VERTSIZE);
pix_hor = GetSystemMetrics(SM_CXSCREEN);
pix_ver = GetSystemMetrics(SM_CYSCREEN);

printf("horizonal pixels %d\n", pix_hor);
printf("veritical pixels SM_CYSCREEN %d\n", pix_ver);
printf("horizontal millimeters %d\n", mm_hor);
printf("veritical millimeters %d\n", mm_ver);

printf("horizontal pixels per millimeter %f\n", (((float) pix_hor) / ((float) mm_hor)));
printf("vertical pixels per millimeter %f\n", (((float) pix_ver) / ((float) mm_ver)));

printf("horizontal pixels per inch %f\n", (((float) pix_hor) / ((float) mm_hor) * 10.0 * 2.54));
printf("vertical pixels per inch %f\n", (((float) pix_ver) / ((float) mm_ver) * 10.0 * 2.54));

return 0;
}


for me:

$ gcc dpi.c -luser32 -lgdi32

jay at jay-win9 /dev2/j/dpi
$ ./a
horizonal pixels 1280
veritical pixels SM_CYSCREEN 800
horizontal millimeters 384
veritical millimeters 240
horizontal pixels per millimeter 3.333333
vertical pixels per millimeter 3.333333
horizontal pixels per inch 84.666667
vertical pixels per inch 84.666667

(Visual C++ is fine:
cl dpi.c user32.lib gdi32.lib
.\dpi
)

I wonder if lying in this code:

Searching for 'GetDeviceCaps'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(25): VAR res := NEW(T); n_colors := GetDeviceCaps (WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(32): res.depth := GetDeviceCaps(WinGDI.BITSPIXEL); (* John Karnak 8/3/98 *)
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(68): mm_hor = GetDeviceCaps (WinGDI.HORZSIZE),
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(69): mm_ver = GetDeviceCaps (WinGDI.VERTSIZE) DO

Searching for 'res.res[Axis.T.'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(71): res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(72): res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);


D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(89):PROCEDURE GetDeviceCaps (cap: Ctypes.int): INTEGER =
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(93): res := WinGDI.GetDeviceCaps (hdc, cap);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(98): END GetDeviceCaps;
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnColorMap.m3(268): cnt := WinGDI.GetDeviceCaps (hdc, WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnFont.m3(316): LogicalPixelsPerVertInch := WinGDI.GetDeviceCaps(er.hdc, WinGDI.LOGPIXELSY);
9 occurrence(s) have been found.


Searching for '1000.0'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(463): bmih.biXPelsPerMeter := ROUND (st.res[Axis.T.Hor] * 1000.0);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(464): bmih.biYPelsPerMeter := ROUND (st.res[Axis.T.Ver] * 1000.0);


and just claiming 96dpi is the way to go.
Can you try that??


Specifically try setting res.res[Axis.T.Hor] and .Ver to 3.779527559055118.
Or heck to 3.3333 like my laptop has.


Or maybe claiming ignorance and setting biXPelsPerMeter and biYPelsPerMeter to 0???
Claiming ignorance feels better than lying of course. :)

Hm, so throw in also:

printf("LogicalPixelsX %u\n", GetDeviceCaps(hdc, LOGPIXELSX));
printf("LogicalPixelsY %u\n", GetDeviceCaps(hdc, LOGPIXELSY));

I get the magic number 96.

- Jay



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080809/00e22eca/attachment.html>

From rodney.bates at wichita.edu  Sat Aug  9 17:45:45 2008
From: rodney.bates at wichita.edu (Rodney M. Bates)
Date: Sat, 09 Aug 2008 10:45:45 -0500
Subject: [M3devel] pixmap problem (some success)
In-Reply-To: <COL101-W49AB1574C557B5343D724DE6740@phx.gbl>
References: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>
	<489B5023.1E75.00D7.1@scires.com>
	<COL101-W279710F3EF9B814B1DA853E6740@phx.gbl>
	<489B5A5F.1E75.00D7.1@scires.com>
	<COL101-W76DCEA23FC2EA0FD299A3DE6740@phx.gbl>
	<489B7025.1E75.00D7.1@scires.com>
	<COL101-W49AB1574C557B5343D724DE6740@phx.gbl>
Message-ID: <489DBBA9.8020109@wichita.edu>



Jay wrote:
> I committed a possible fix here.
> Please see how it fairs.
> 
> I have a few Modula-3 questions related to the fix.
> 
>  - Did I have to expose the functions in the .i3 file
>   that implement the methods? That seems "wrong".
> 
> 
>    - Could I have used "stronger language opacity" instead
>     of "informal privacy"? That is, could I have used an
>     opaque type?

I have a number of comments on this.
Here are 3 examples of different styles of coding in Modula-3.

---------------------------------------------------------------------------------
INTERFACE M1
; TYPE T <: REFANY
; PROCEDURE Op ( Arg : T )
; END M1 .

MODULE M1
; REVEAL T = BRANDED REF RECORD (
                * Fields of T, hidden from clients. *)
              END (* T *)
; PROCEDURE Op ( Arg : T ) = (* A body that uses the fields of T. *)
; BEGIN END M1 .

; MODULE Client1 EXPORTS Main
; IMPORT M1
; VAR Obj := NEW ( M1 . T )
; BEGIN
     M1 . Op ( Obj )
   END Client1 .

I would call this the _abstract data type_ style.  It uses a plain procedure Op,
not a method.  The type T is opaque in the interface, so clients can manipulate
values of it only by calling Op (and, presumably, other procedures whose signatures
would also be given in the interface).

-------------------------------------------------------------------------------
INTERFACE M2
; TYPE T <: Public
; TYPE Public = OBJECT METHODS op ( ) (* No default method body given here. *)
                 END (* Public *)
; END M2 .

MODULE M2
; REVEAL T = Public BRANDED OBJECT (* Same fields as M1.T. *)
                     OVERRIDES op := Op (* Provide the method body for op. *)
                     END (* T *)
; PROCEDURE Op ( Arg : T ) = (* Pretty much the same as M1.Op, maybe even exactly. *)
; BEGIN END M2 .

; MODULE Client2 EXPORTS Main
; IMPORT M2
; VAR Obj : M2 . T := NEW ( M2 . T )
; BEGIN
     Obj . op ( )
   END Client2 .

This is the OO style.  The operation is an overridable method.  Clients can still
manipulate objects of type T only by using the operation op, but here, op is a
method, not a procedure, so they must use a method call.  It will dispatch, but
without further code, it will always dispatch to M2.Op.

But, if client code were to:
1) declare a subtype Sub, of M2.T,
2) which has a method override for op, say procedure OpSub,
3) provide OpSub,
4) then allocate an object of type Sub,
5) but assign this object to variable Client2.Obj (whose type is M2.T, not Sub),
then the method call Obj.op() would dispatch to OpSub.

-------------------------------------------------------------------------------
Here is a side point that I think is confusing about Modula-3 opaque types.  At least
it took me years to fully understand.  The same subtype mechanism is used in Modula-3
in two different ways.  One is for creating a hierarchy of dynamically typed objects.
This is the usual OO use.  The other is in opaque types.  When used in the usual way,
actual objects of opaque type Public are never allocated.  Public is only a static
structure to hold the subset of the properties of type T that are known everywhere.

When you execute NEW(M2.T), you get a complete object of type T, with all its fields and
method overrides, even though you are in a context where these are not known.  In a
sense, these things are hidden only from the programmer of this client code.  But the
compiler may have to know at least some of the hidden information at the site of the
NEW call.

(Actually, through clever implementation techniques, I think the compiler needs to
know at most the size of fully revealed type T and could probably do without that.
The messages about recompiling modules because of new opaque info are, I am sure,
the compiler generating better code by using revelations it didn't have the first time.)

-------------------------------------------------------------------------------
INTERFACE M3
; TYPE T <: Public
; TYPE Public = OBJECT METHODS op ( )
                                := Op (* Specify the body of op, here in the interface. *)
                 END (* Public *)
; PROCEDURE Op ( Arg : T ) = (* A body that uses the fields of T. *)
; END M3 .

MODULE M3
; REVEAL T = Public BRANDED OBJECT (* Same fields as M1.T and M2.T. *)
                     (* No override for op needed. Its body was already
                        given in type Public. *)
                     END T
; PROCEDURE Op ( Arg : T ) = (* Pretty much the same as M1.Op. *)
; BEGIN END M3 .

; MODULE Client3 EXPORTS Main
; IMPORT M3
; VAR Obj := NEW ( M3 . T )
; BEGIN
     Obj . op ( )
   ; M3 . Op ( Obj )
   END Client3 .

This is a hybrid.  Still opaque, as before.  But a client can either call plain
procedure M3.Op, which will be statically known to always invoke Op, or a method
call on op, which might  dispatch to Op or OpSub, if the latter exists.

------------------------------------------------------------------------------------
An OO purist would say that every programmer-defined type should be opaque, hiding its
fields, and that every operation should always be a method, in case some later code
has a need to create a subtype and override the methods.

The problem with (dispatching) methods is it makes tracking down bugs a nightmare.  The
whole abstraction idea works great when designing one layer at a time, or even testing
one layer at a time.  But when you have a specific bug, you can't do it a layer at a time.
You often have to trace, mentally or with actual execution, in and out of the calls and
returns, through the layers.

If you see a procedure call, it is statically known and quite direct, at least in a
modular language, to find the code that is called.  Every time you see a method call,
there is a big tangential process to try to figure out if there are overrides, what
subtype the object might be, etc., and the results may be dynamic.  This can make an
otherwise sstraightforward process extremely tedious.

I am a strong believer in using methods when there is a good reason, i.e., you know
or reasonably suspect there will be a need to actually create overrides and have
nontrivial dispatching happen.  Otherwise, stick to static procedure calls.  The
pickle code, for example, uses methods all over the place.  Nearly all of them always
dispatch to exactly one place, but for each such, it takes a lot of work to ascertain
this.  It is very hard code to vet.

-------------------------------------------------------------------------------------
The hybrid approach, perhaps surprisingly, is sometimes very useful.  For example,
you have a complex tree with several node types that are different subtypes of a
common parent node type.  In some places, you have a node pointer that could be
any of the subtypes.  Then you would want to make a method call.  In other places,
you already know exactly what type node you have, perhaps because you are inside
a TYPECASE or a procedure that was already dispatched-to.  Here, I prefer to use
a non-dispatching call.  Aside from saving a tiny bit of runtime overhead for the
dispatch (which is minor), you avoid the debug problem above.


> 
>    - Will the change break pickles?
>      "Both" due to the addition of data "or" methods?
>      ie: What breaks pickles?
>      Do I need to think in the mindset of
>       C:
>        typedef struct {
>          int a,b;
>        } foo_t;
> 
>        foo_t f;
>        fwrite(&f, sizeof(f), 1, file);
> 
>       and not breaking such code? 
>      Only if the type is "branded"? Or if types derived from it are branded?
>         There could be derived types not in the cm3 tree though.
>         How much do we care about breaking code outside the cm3 tree?
>         e.g. in this change, I had to change every use of .xres and .yres

If by "break pickles" you mean invalidating existing pickle _data_ that was written
before the change, then yes.  When reading an object from a pickle, the reading
program must contain a type that is exactly the same type as was used to write
the object.  So if the program that reads the pickle is recompiled after the change,
then existing pickle data will have to be rewritten.

A change to anything that is a property of a type, according to the rules of
the language, will cause this.  For example, changes in brandedness, changes in
the string value of the brand, or, probably, the use of an anonymous brand would
all change the type.  Note that the full revelation of any opaque type is required
by the language to be branded, though not necessarily with a string value.

Also, note that the names of fields are part of a record or object type, so
changing .xres to a different name will invalidate existing pickle data.  This
does not necessarily mean it's a bad idea.

On the other hand, if you are willing/able to recompile and rerun both the program
that writes and the program that reads the pickle data, such changes will work fine.
Neither the source code in the Pickle library nor its client code will break.

We definitely do care about breaking code outside the cm3 tree.  Randy's application
would be a good example.  So removing functions, constants, etc. just because they
are unused in cm3 would not be good.  Nor would merging differently-named things,
just because they always have the same properties in cm3, because they could have
different properties in other code.


-- 
-------------------------------------------------------------
Rodney M. Bates, retired assistant professor
Dept. of Computer Science, Wichita State University
Wichita, KS 67260-0083
316-978-3922
rodney.bates at wichita.edu


From jayk123 at hotmail.com  Sat Aug  9 20:41:36 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 9 Aug 2008 18:41:36 +0000
Subject: [M3devel] pixmap problem (some success)
In-Reply-To: <489DBBA9.8020109@wichita.edu>
References: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>
	<489B5023.1E75.00D7.1@scires.com>
	<COL101-W279710F3EF9B814B1DA853E6740@phx.gbl>
	<489B5A5F.1E75.00D7.1@scires.com>
	<COL101-W76DCEA23FC2EA0FD299A3DE6740@phx.gbl>
	<489B7025.1E75.00D7.1@scires.com>
	<COL101-W49AB1574C557B5343D724DE6740@phx.gbl> 
	<489DBBA9.8020109@wichita.edu>
Message-ID: <COL101-W25A5930EE4E6CFB7E6BA7AE6770@phx.gbl>


Thanks Rodney, good summary. I have been "almost aware" of much of this.I didn't think you could derive from opaque types for some reason.
So I instead relied on "gentleman's agreement", naming things "private".
Like how Modula-3 doesn't have constructors, but relies on people to call "init".Randy, go ahead and change what you want. I don't like red tape myself.
  You're welcome and definitely thanks to David.
Regarding pickles, are we to consider all types as likely to be pickled?
And therefore we are very stuck unable to change?Or only branded types? Or ...?
Or we don't believe people build up significant investment in pickle files
and can throw them all away upon rebuilding their code from current source?
 
This change could be restarted without breaking pickles.
As it is currently stated, it deliberately breaks existing code in order to
be certain the fix works, to be absolutely sure the wrong values aren't used.
That is, I didn't want to rely on any particular preexisting function call
being made before the values are read. There is no way to do that
given the "fully unprotected" form that was there before.
 
Agreed -- layering is great for design, and "agility" (ability to change),
but more code = more bugs, more code = more code to read when debugging,
more code = more code to understand when maintaining.
 
I don't think you need to know the size of things at the NEW site.
In a general "if I were designing the system" sense, not in the
"I know how Modula-3 works" (I don't yet).
NEW(T) could include within it a function call, or global read, to get the size of T.
Or heck, NEW(T) could call a function that passes the size on to
the next level down.
That is, in C, it could look like one of:
 
original code:
client:
 T* t = NEW(T) 
 
option 1 - function call
client:
T* t = (T*) malloc(GetSizeOfT());
 
implementation:
size_T GetSizeOfT() { return 42; }
 
option 2 - global read 
client:
T* t = (T*) malloc(SizeOfT);
 
implementation:
extern const SizeOfT = 42;
 
option 3 - 
client:
T* t = NewT();
 
implementation:
T* NewT(void) { return (T*) malloc(sizeof(T)); }
 
The compiler could go back later and recompile things to
client, or sometimes it could do this the first time:
t = (T*) malloc(sizeof(T));
 
Though option 3 potentially generates smaller code, if there are
many places that make a T.
This is just the usual "inlining can bloat code size" point.
"Make functions out of frequently occuring blocks of code
to reduce code size".
 
Option 3 becomes "better" as there are more used default
field initializers.
That is:
T = RECORD
  a := 1; b:= 2; c:=3; d:=4;e:=5;f:=6;
END;
 
If there are lots of NEW(T), without
replacements for the initial values (not sure you can do that,
but I think so), then one function to call malloc and fill in
all the values could be a win over inlining the initialization
everywhere, due to code size.
 
Code size is usually important for performance.
You want the code to be small to fit in cache.
And to reduce the cost of paging it in.
 
 - Jay> Date: Sat, 9 Aug 2008 10:45:45 -0500> From: rodney.bates at wichita.edu> To: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem (some success)> > > > Jay wrote:> > I committed a possible fix here.> > Please see how it fairs.> > > > I have a few Modula-3 questions related to the fix.> > > > - Did I have to expose the functions in the .i3 file> > that implement the methods? That seems "wrong".> > > > > > - Could I have used "stronger language opacity" instead> > of "informal privacy"? That is, could I have used an> > opaque type?> > I have a number of comments on this.> Here are 3 examples of different styles of coding in Modula-3.> > ---------------------------------------------------------------------------------> INTERFACE M1> ; TYPE T <: REFANY> ; PROCEDURE Op ( Arg : T )> ; END M1 .> > MODULE M1> ; REVEAL T = BRANDED REF RECORD (> * Fields of T, hidden from clients. *)> END (* T *)> ; PROCEDURE Op ( Arg : T ) = (* A body that uses the fields of T. *)> ; BEGIN END M1 .> > ; MODULE Client1 EXPORTS Main> ; IMPORT M1> ; VAR Obj := NEW ( M1 . T )> ; BEGIN> M1 . Op ( Obj )> END Client1 .> > I would call this the _abstract data type_ style. It uses a plain procedure Op,> not a method. The type T is opaque in the interface, so clients can manipulate> values of it only by calling Op (and, presumably, other procedures whose signatures> would also be given in the interface).> > -------------------------------------------------------------------------------> INTERFACE M2> ; TYPE T <: Public> ; TYPE Public = OBJECT METHODS op ( ) (* No default method body given here. *)> END (* Public *)> ; END M2 .> > MODULE M2> ; REVEAL T = Public BRANDED OBJECT (* Same fields as M1.T. *)> OVERRIDES op := Op (* Provide the method body for op. *)> END (* T *)> ; PROCEDURE Op ( Arg : T ) = (* Pretty much the same as M1.Op, maybe even exactly. *)> ; BEGIN END M2 .> > ; MODULE Client2 EXPORTS Main> ; IMPORT M2> ; VAR Obj : M2 . T := NEW ( M2 . T )> ; BEGIN> Obj . op ( )> END Client2 .> > This is the OO style. The operation is an overridable method. Clients can still> manipulate objects of type T only by using the operation op, but here, op is a> method, not a procedure, so they must use a method call. It will dispatch, but> without further code, it will always dispatch to M2.Op.> > But, if client code were to:> 1) declare a subtype Sub, of M2.T,> 2) which has a method override for op, say procedure OpSub,> 3) provide OpSub,> 4) then allocate an object of type Sub,> 5) but assign this object to variable Client2.Obj (whose type is M2.T, not Sub),> then the method call Obj.op() would dispatch to OpSub.> > -------------------------------------------------------------------------------> Here is a side point that I think is confusing about Modula-3 opaque types. At least> it took me years to fully understand. The same subtype mechanism is used in Modula-3> in two different ways. One is for creating a hierarchy of dynamically typed objects.> This is the usual OO use. The other is in opaque types. When used in the usual way,> actual objects of opaque type Public are never allocated. Public is only a static> structure to hold the subset of the properties of type T that are known everywhere.> > When you execute NEW(M2.T), you get a complete object of type T, with all its fields and> method overrides, even though you are in a context where these are not known. In a> sense, these things are hidden only from the programmer of this client code. But the> compiler may have to know at least some of the hidden information at the site of the> NEW call.> > (Actually, through clever implementation techniques, I think the compiler needs to> know at most the size of fully revealed type T and could probably do without that.> The messages about recompiling modules because of new opaque info are, I am sure,> the compiler generating better code by using revelations it didn't have the first time.)> > -------------------------------------------------------------------------------> INTERFACE M3> ; TYPE T <: Public> ; TYPE Public = OBJECT METHODS op ( )> := Op (* Specify the body of op, here in the interface. *)> END (* Public *)> ; PROCEDURE Op ( Arg : T ) = (* A body that uses the fields of T. *)> ; END M3 .> > MODULE M3> ; REVEAL T = Public BRANDED OBJECT (* Same fields as M1.T and M2.T. *)> (* No override for op needed. Its body was already> given in type Public. *)> END T> ; PROCEDURE Op ( Arg : T ) = (* Pretty much the same as M1.Op. *)> ; BEGIN END M3 .> > ; MODULE Client3 EXPORTS Main> ; IMPORT M3> ; VAR Obj := NEW ( M3 . T )> ; BEGIN> Obj . op ( )> ; M3 . Op ( Obj )> END Client3 .> > This is a hybrid. Still opaque, as before. But a client can either call plain> procedure M3.Op, which will be statically known to always invoke Op, or a method> call on op, which might dispatch to Op or OpSub, if the latter exists.> > ------------------------------------------------------------------------------------> An OO purist would say that every programmer-defined type should be opaque, hiding its> fields, and that every operation should always be a method, in case some later code> has a need to create a subtype and override the methods.> > The problem with (dispatching) methods is it makes tracking down bugs a nightmare. The> whole abstraction idea works great when designing one layer at a time, or even testing> one layer at a time. But when you have a specific bug, you can't do it a layer at a time.> You often have to trace, mentally or with actual execution, in and out of the calls and> returns, through the layers.> > If you see a procedure call, it is statically known and quite direct, at least in a> modular language, to find the code that is called. Every time you see a method call,> there is a big tangential process to try to figure out if there are overrides, what> subtype the object might be, etc., and the results may be dynamic. This can make an> otherwise sstraightforward process extremely tedious.> > I am a strong believer in using methods when there is a good reason, i.e., you know> or reasonably suspect there will be a need to actually create overrides and have> nontrivial dispatching happen. Otherwise, stick to static procedure calls. The> pickle code, for example, uses methods all over the place. Nearly all of them always> dispatch to exactly one place, but for each such, it takes a lot of work to ascertain> this. It is very hard code to vet.> > -------------------------------------------------------------------------------------> The hybrid approach, perhaps surprisingly, is sometimes very useful. For example,> you have a complex tree with several node types that are different subtypes of a> common parent node type. In some places, you have a node pointer that could be> any of the subtypes. Then you would want to make a method call. In other places,> you already know exactly what type node you have, perhaps because you are inside> a TYPECASE or a procedure that was already dispatched-to. Here, I prefer to use> a non-dispatching call. Aside from saving a tiny bit of runtime overhead for the> dispatch (which is minor), you avoid the debug problem above.> > > > > > - Will the change break pickles?> > "Both" due to the addition of data "or" methods?> > ie: What breaks pickles?> > Do I need to think in the mindset of> > C:> > typedef struct {> > int a,b;> > } foo_t;> > > > foo_t f;> > fwrite(&f, sizeof(f), 1, file);> > > > and not breaking such code? > > Only if the type is "branded"? Or if types derived from it are branded?> > There could be derived types not in the cm3 tree though.> > How much do we care about breaking code outside the cm3 tree?> > e.g. in this change, I had to change every use of .xres and .yres> > If by "break pickles" you mean invalidating existing pickle _data_ that was written> before the change, then yes. When reading an object from a pickle, the reading> program must contain a type that is exactly the same type as was used to write> the object. So if the program that reads the pickle is recompiled after the change,> then existing pickle data will have to be rewritten.> > A change to anything that is a property of a type, according to the rules of> the language, will cause this. For example, changes in brandedness, changes in> the string value of the brand, or, probably, the use of an anonymous brand would> all change the type. Note that the full revelation of any opaque type is required> by the language to be branded, though not necessarily with a string value.> > Also, note that the names of fields are part of a record or object type, so> changing .xres to a different name will invalidate existing pickle data. This> does not necessarily mean it's a bad idea.> > On the other hand, if you are willing/able to recompile and rerun both the program> that writes and the program that reads the pickle data, such changes will work fine.> Neither the source code in the Pickle library nor its client code will break.> > We definitely do care about breaking code outside the cm3 tree. Randy's application> would be a good example. So removing functions, constants, etc. just because they> are unused in cm3 would not be good. Nor would merging differently-named things,> just because they always have the same properties in cm3, because they could have> different properties in other code.> > > -- > -------------------------------------------------------------> Rodney M. Bates, retired assistant professor> Dept. of Computer Science, Wichita State University> Wichita, KS 67260-0083> 316-978-3922> rodney.bates at wichita.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080809/86c51ed0/attachment.html>

From rcoleburn at scires.com  Mon Aug 11 21:23:17 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Mon, 11 Aug 2008 15:23:17 -0400
Subject: [M3devel] strange problem w/new Image/ImageInit
In-Reply-To: <COL101-W13606B4823978F6670D3C9E6710@phx.gbl>
References: <489FAA38.1E75.00D7.1@scires.com>
	<COL101-W158F68823847D036260F0FE6710@phx.gbl>
	<48A02D67.1E75.00D7.1@scires.com>
	<COL101-W13606B4823978F6670D3C9E6710@phx.gbl>
Message-ID: <48A05960.1E75.00D7.1@scires.com>

Jay:
 
I have been experimenting quite a bit and I've come up with some "new old" information.
 
I say "new old" because, after spending the time to read some of the comments in the original code (before we modified it), I think I now have a better idea of what the designers intended and why I had/have a problem.
 
If you read carefully, the xres/yres fields in Image.Raw are supposed to represent the resolution at which the pixmap was originally DEVELOPED, not the resolution of the current screen.  It seems the designers went to great lengths to represent everything as screen-independent until it is actually rendered.  
 
The Image interface gives 3 ways of dealing with pixmaps:  (1) unscaled, (2) scaled, and (3) scaled to "most appropriate".  The change you and I conspired actually changes this behavior to make #2 (scaled) work as #1 (unscaled).  (It probably also changes #3.)  This is the behavior I want for my current program, but it changes the intent of the original interface, so I'm afraid we are going to have to revert all those changes.
 
Digging deeper into Image.m3, I've discovered that it is smart-enough already to deduce the screen resolution.  If you look into the ApplyScaled1 procedure, you see that it converts the current screen resolution in millimeters to pixels in order to scale the pixmap.  The change we introduced, namely making Raw.xres/yres equal to the current screen resolution, effectively caused the Scaled procedure to do nothing since (ScreenDPI / ImageDPI) = 1.
 
The problem that brought all this on in the first place is that my GUI was looking bad on the 1920x1200 screen.  The reason I have discovered *now* is that FormsVBT apparently uses the #2 (scaled) version for pixmaps.  In the old code, the interface defaulted the developed resolution of the pixmaps to be 75 dpi.  At my 147+ dpi screen, the scaled implementation would effectively double the size of the pixmap when rendered on the screen in an effort to make the pixmap look the same size on the 147dpi screen that it appeared on a 75 dpi screen.
 
All of this to say that the changes to Image.i3/m3 need to be undone in order to get back the original intent of the developers.
 
Of course, once these changes are undone, my problem returns with the GUI looking bad on 1920x1200 at 147+ dpi.  So, how to solve it properly now requires more thought.
 
I need to do some more reading of the code I guess to see if there is a way already to cause FormsVBT to use unscaled for all pixmaps.  Otherwise, a quick fix would be to add a new procedure to the interface that would force use of the unscaled implementation.
 
Now, back to the problem of not being able to drag the subwindows, I'm still puzzled.  To test my "understanding" as related above, I went back to the original Image.i3/m3, but this time changed the Scaled procedure to effectively do the same thing as Unscaled.  The pixmaps render fine on the 1920x1200 monitor, but the subwindows still can't be dragged.  If I back out my change to Scaled (effectively, revert to the original Image.m3), the subwindows drag with ease on the 1920x1200 monitor, but of course the pixmaps look bad.  I can't explain this behavior yet.  Any ideas?
 
Regards,
Randy

>>> Jay <jay.krell at cornell.edu> 8/11/2008 2:41 PM >>>

MemoryBarrier ensures that all the reads and writes before it finish before any reads and writes after it.
Look at winnt.h or MSDN, as well the comment I put in explains it.
It probably has no effect, since our compiler is not aggressive.
What is confusing in these cases is the compiler and processor both need to be informed.
There is a concurrency issue and the barrier should make extra certain to solve it.

Multiple monitors are not considered.
Do you have them?

Randy, please experiment.
Change the code to return hard coded numbers -- like the old 75.
   Either without the globals, or initialize the globals.
And then add in the the various calls one at a time, ignoring their return values.  

Furthermore, I guess you could just say:

    IF xres = 0 THEN Init() END;

and

    IF yres = 0 THEN Init() END;

and maybe change the globals to INTEGER.
Though REAL should be 32 bits and be written atomatically.

The idea is, even if the code does run multiple times concurrently, it should always return the same information.

Anyway, like I said, try various or every combination between the two and find
out which part triggers the difference, then we can think more about just that.

I might be able to get an expert friend to give me some help, later.

- Jay


________________________________

Date: Mon, 11 Aug 2008 12:15:40 -0400
From: rcoleburn at scires.com 
To: jay.krell at cornell.edu 
CC: wagner at elegosoft.com 
Subject: RE: strange problem w/new Image/ImageInit



Jay:



I tested your change, but it has no effect on the problem I am having.  I also tried having the accessor functions just return a hardcoded number, but again, no effect on the problem.  This is real strange to me, because if I remove ImageInit and revert Image.i3/m3 back to the way it was before, the problem disappears.



Questions,

1.  What does the WinNT.MemoryBarrier() call do?

2.  What would happen if this code was run by multiple threads?  Are there any concurrency issues that need to be guarded?

3.  What would happen in the case of multiple monitors at different resolutions?



Regards,

Randy

>>> Jay  8/11/2008 6:46 AM>>>

Also try the change I just commited with ReleaseDC.

- Jay


> From: jayk123 at hotmail.com 
> To: rcoleburn at scires.com 
> CC: wagner at elegosoft.com 
> Subject: RE: strange problem w/new Image/ImageInit
> Date: Mon, 11 Aug 2008 07:51:52 +0000
>
>
> Randy, this makes no sense to me.
> What happens if you just hardcode the numbers instead of computing them?
>
>
> - Jay
>
>
>
>
>
>
> ________________________________
>
>
>
> Date: Mon, 11 Aug 2008 02:55:56 -0400
> From: rcoleburn at scires.com 
> To: jayk123 at hotmail.com 
> CC: Olaf Wagner


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080811/ead5acd5/attachment.html>

From jay.krell at cornell.edu  Mon Aug 11 21:52:52 2008
From: jay.krell at cornell.edu (Jay)
Date: Mon, 11 Aug 2008 19:52:52 +0000
Subject: [M3devel] strange problem w/new Image/ImageInit
In-Reply-To: <48A05960.1E75.00D7.1@scires.com>
References: <489FAA38.1E75.00D7.1@scires.com>
	<COL101-W158F68823847D036260F0FE6710@phx.gbl>
	<48A02D67.1E75.00D7.1@scires.com>
	<COL101-W13606B4823978F6670D3C9E6710@phx.gbl> 
	<48A05960.1E75.00D7.1@scires.com>
Message-ID: <COL101-W65ECE9C2B48E275288EAF0E6710@phx.gbl>


Hm. Ok then, where does it get the screen resolution from?

Probably here?

WinScreenType.m3:

PROCEDURE InnerNew ((* IN-OUT *) res: T) =
  BEGIN
    WITH pix_hor = WinUser.GetSystemMetrics(WinUser.SM_CXSCREEN),
         pix_ver = WinUser.GetSystemMetrics(WinUser.SM_CYSCREEN),
         mm_hor  = GetDeviceCaps (WinGDI.HORZSIZE),
         mm_ver  = GetDeviceCaps (WinGDI.VERTSIZE) DO
      res.rootDom := Rect.FromSize(pix_hor, pix_ver);
      res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
      res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);

ok.

Perhaps we should accept the numbers that Windows makes up instead?

GetDeviceCaps(LOGPIXELSX)
and GetDeviceCaps(LOGPIXELSY)

Please try that, in the WinScreenType.m3 code.
With removing ImageInit (or just have it hardcoded at 75).

This will most likely be 96 even on your high dpi system, unless you are on Vista
and tell the system you are high dpi aware.

I think there is disagreement in drawing vs. hit test as to where you are clicking.
Try making ImageInit always 75.
Try making the above convert from a hardcoded 96.
And then try GetDeviceCaps(LOGPIXELSX and Y) -- which I expect always returns 96 for you.
You can plug that into my dpi.c to see what it prints.

I think part of what is happening is that Modula-3 was very rare in doing the right thing for high dpi
monitors. But so much code is wrong that Windows has to counteract the wrongness,
which means Modula-3 needs to go along and do things wrong in order for the counteraction
to leave it doing the right thing also.
I'm not sure.
Oh, and presumably other places in Modula-3 are wrong, and the counteraction works for them.
That's a bit of a mystery -- drawing of pixmaps vs. drawing of everything else.

 - Jay


________________________________

Date: Mon, 11 Aug 2008 15:23:17 -0400
From: rcoleburn at scires.com
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com; wagner at elegosoft.com
Subject: RE: strange problem w/new Image/ImageInit



Jay:



I have been experimenting quite a bit and I've come up with some "new old" information.



I say "new old" because, after spending the time to read some of the comments in the original code (before we modified it), I think I now have a better idea of what the designers intended and why I had/have a problem.



If you read carefully, the xres/yres fields in Image.Raw are supposed to represent the resolution at which the pixmap was originally DEVELOPED, not the resolution of the current screen.  It seems the designers went to great lengths to represent everything as screen-independent until it is actually rendered.



The Image interface gives 3 ways of dealing with pixmaps:  (1) unscaled, (2) scaled, and (3) scaled to "most appropriate".  The change you and I conspired actually changes this behavior to make #2 (scaled) work as #1 (unscaled).  (It probably also changes #3.)  This is the behavior I want for my current program, but it changes the intent of the original interface, so I'm afraid we are going to have to revert all those changes.



Digging deeper into Image.m3, I've discovered that it is smart-enough already to deduce the screen resolution.  If you look into the ApplyScaled1 procedure, you see that it converts the current screen resolution in millimeters to pixels in order to scale the pixmap.  The change we introduced, namely making Raw.xres/yres equal to the current screen resolution, effectively caused the Scaled procedure to do nothing since (ScreenDPI / ImageDPI) = 1.



The problem that brought all this on in the first place is that my GUI was looking bad on the 1920x1200 screen.  The reason I have discovered *now* is that FormsVBT apparently uses the #2 (scaled) version for pixmaps.  In the old code, the interface defaulted the developed resolution of the pixmaps to be 75 dpi.  At my 147+ dpi screen, the scaled implementation would effectively double the size of the pixmap when rendered on the screen in an effort to make the pixmap look the same size on the 147dpi screen that it appeared on a 75 dpi screen.



All of this to say that the changes to Image.i3/m3 need to be undone in order to get back the original intent of the developers.



Of course, once these changes are undone, my problem returns with the GUI looking bad on 1920x1200 at 147+ dpi.  So, how to solve it properly now requires more thought.



I need to do some more reading of the code I guess to see if there is a way already to cause FormsVBT to use unscaled for all pixmaps.  Otherwise, a quick fix would be to add a new procedure to the interface that would force use of the unscaled implementation.



Now, back to the problem of not being able to drag the subwindows, I'm still puzzled.  To test my "understanding" as related above, I went back to the original Image.i3/m3, but this time changed the Scaled procedure to effectively do the same thing as Unscaled.  The pixmaps render fine on the 1920x1200 monitor, but the subwindows still can't be dragged.  If I back out my change to Scaled (effectively, revert to the original Image.m3), the subwindows drag with ease on the 1920x1200 monitor, but of course the pixmaps look bad.  I can't explain this behavior yet.  Any ideas?



Regards,

Randy

>>> Jay  8/11/2008 2:41 PM>>>

MemoryBarrier ensures that all the reads and writes before it finish before any reads and writes after it.
Look at winnt.h or MSDN, as well the comment I put in explains it.
It probably has no effect, since our compiler is not aggressive.
What is confusing in these cases is the compiler and processor both need to be informed.
There is a concurrency issue and the barrier should make extra certain to solve it.

Multiple monitors are not considered.
Do you have them?

Randy, please experiment.
Change the code to return hard coded numbers -- like the old 75.
   Either without the globals, or initialize the globals.
And then add in the the various calls one at a time, ignoring their return values.

Furthermore, I guess you could just say:

    IF xres = 0 THEN Init() END;

and

    IF yres = 0 THEN Init() END;

and maybe change the globals to INTEGER.
Though REAL should be 32 bits and be written atomatically.

The idea is, even if the code does run multiple times concurrently, it should always return the same information.

Anyway, like I said, try various or every combination between the two and find
out which part triggers the difference, then we can think more about just that.

I might be able to get an expert friend to give me some help, later.

- Jay


________________________________

Date: Mon, 11 Aug 2008 12:15:40 -0400
From: rcoleburn at scires.com
To: jay.krell at cornell.edu
CC: wagner at elegosoft.com
Subject: RE: strange problem w/new Image/ImageInit



Jay:



I tested your change, but it has no effect on the problem I am having.  I also tried having the accessor functions just return a hardcoded number, but again, no effect on the problem.  This is real strange to me, because if I remove ImageInit and revert Image.i3/m3 back to the way it was before, the problem disappears.



Questions,

1.  What does the WinNT.MemoryBarrier() call do?

2.  What would happen if this code was run by multiple threads?  Are there any concurrency issues that need to be guarded?

3.  What would happen in the case of multiple monitors at different resolutions?



Regards,

Randy

>>> Jay  8/11/2008 6:46 AM>>>

Also try the change I just commited with ReleaseDC.

- Jay


> From: jayk123 at hotmail.com
> To: rcoleburn at scires.com
> CC: wagner at elegosoft.com
> Subject: RE: strange problem w/new Image/ImageInit
> Date: Mon, 11 Aug 2008 07:51:52 +0000
>
>
> Randy, this makes no sense to me.
> What happens if you just hardcode the numbers instead of computing them?
>
>
> - Jay
>
>
>
>
>
>
> ________________________________
>
>
>
> Date: Mon, 11 Aug 2008 02:55:56 -0400
> From: rcoleburn at scires.com
> To: jayk123 at hotmail.com
> CC: Olaf Wagner




From rcoleburn at scires.com  Tue Aug 12 10:25:11 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Tue, 12 Aug 2008 04:25:11 -0400
Subject: [M3devel] strange problem w/new Image/ImageInit
In-Reply-To: <COL101-W65ECE9C2B48E275288EAF0E6710@phx.gbl>
References: <489FAA38.1E75.00D7.1@scires.com>
	<COL101-W158F68823847D036260F0FE6710@phx.gbl>
	<48A02D67.1E75.00D7.1@scires.com>
	<COL101-W13606B4823978F6670D3C9E6710@phx.gbl>
	<48A05960.1E75.00D7.1@scires.com>
	<COL101-W65ECE9C2B48E275288EAF0E6710@phx.gbl>
Message-ID: <48A110A3.1E75.00D7.1@scires.com>

Jay:
 
For LOGPIXELS X & Y, I get 96 on the hi-res Dell M4300 system and also on my ThinkPad T60.
 
I've put together revised versions of Image.i3/m3 and my ScrollerVBTClass.m3.  The good news is that I've managed to get the scroll bar to look correct in both scaled and unscaled modes.  
 
I've added a new procedure to Image.i3/m3 that will force subsequent calls to Scaled() to behave like Unscaled().  Using this, I can get the appearance I need on the hi-res monitor without resorting to changes in the original intent of the Image interface.  The advantage of this procedure is that it does not change the Image interface (except for addition of the procedure) and it therefore won't have any affect on pickles or anyone else's code.  Plus, it lets the programmer override use of Scaled() in all library modules without having to modify any source code.
 
Before I commit any of these changes, I want to do some more testing and to fix the problem with subwindows (ZChassisVBT) not being able to move.
 
Alas, my problem of the ZChassisVBTs not being able to move on the hi-res monitor persists with these changes, even though I left the xres/yres at 75.  Of course, these numbers are ignored for Unscaled images anyway.
 
I'm at a loss to explain this behavior.  Here is what I know based on testing:
1.  Using Scaled images and Image.Raw.xres/yres = 75.0, ZChassisVBT movement works on the hi-res monitor.
2.  Using Scaled images and Image.Raw.xres/yres set to 86.xxx or to 147.xxx, ZChassisVBT movement does not work on the hi-res 147.xxx dpi monitor, but it still works on my 86.xxx dpi monitor
3.  Using Unscaled images, ZChassisVBT movement does not work on the hi-res 147.xxx dpi monitor, but it still works on my 86.xxx dpi monitor
 
So, there seems to be something in the implementation somewhere of ZChassisVBT, or maybe ZMoveVBT, that doesn't like 147.xxx dpi monitors unless you scale all images assuming they were designed at 75 dpi.  At the 147 dpi, the 75 dpi pixmaps will be scaled by a factor of 2, which corresponds to what I am seeing on the screen.
 
I'm too sleepy to make any more progress for now.  If anyone has an idea on what to do next, please let me know.  I'm stumped at this point.
 
Regards,
Randy

>>> Jay <jay.krell at cornell.edu> 8/11/2008 3:52 PM >>>

Hm. Ok then, where does it get the screen resolution from?

Probably here?

WinScreenType.m3:

PROCEDURE InnerNew ((* IN-OUT *) res: T) =
  BEGIN
    WITH pix_hor = WinUser.GetSystemMetrics(WinUser.SM_CXSCREEN),
         pix_ver = WinUser.GetSystemMetrics(WinUser.SM_CYSCREEN),
         mm_hor  = GetDeviceCaps (WinGDI.HORZSIZE),
         mm_ver  = GetDeviceCaps (WinGDI.VERTSIZE) DO
      res.rootDom := Rect.FromSize(pix_hor, pix_ver);
      res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
      res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);

ok.

Perhaps we should accept the numbers that Windows makes up instead?

GetDeviceCaps(LOGPIXELSX)
and GetDeviceCaps(LOGPIXELSY)

Please try that, in the WinScreenType.m3 code.
With removing ImageInit (or just have it hardcoded at 75).

This will most likely be 96 even on your high dpi system, unless you are on Vista
and tell the system you are high dpi aware.

I think there is disagreement in drawing vs. hit test as to where you are clicking.
Try making ImageInit always 75.
Try making the above convert from a hardcoded 96.
And then try GetDeviceCaps(LOGPIXELSX and Y) -- which I expect always returns 96 for you.
You can plug that into my dpi.c to see what it prints.

I think part of what is happening is that Modula-3 was very rare in doing the right thing for high dpi
monitors. But so much code is wrong that Windows has to counteract the wrongness,
which means Modula-3 needs to go along and do things wrong in order for the counteraction
to leave it doing the right thing also.
I'm not sure.
Oh, and presumably other places in Modula-3 are wrong, and the counteraction works for them.
That's a bit of a mystery -- drawing of pixmaps vs. drawing of everything else.

- Jay


________________________________

Date: Mon, 11 Aug 2008 15:23:17 -0400
From: rcoleburn at scires.com 
To: jay.krell at cornell.edu 
CC: m3devel at elegosoft.com; wagner at elegosoft.com 
Subject: RE: strange problem w/new Image/ImageInit



Jay:



I have been experimenting quite a bit and I've come up with some "new old" information.



I say "new old" because, after spending the time to read some of the comments in the original code (before we modified it), I think I now have a better idea of what the designers intended and why I had/have a problem.



If you read carefully, the xres/yres fields in Image.Raw are supposed to represent the resolution at which the pixmap was originally DEVELOPED, not the resolution of the current screen.  It seems the designers went to great lengths to represent everything as screen-independent until it is actually rendered.



The Image interface gives 3 ways of dealing with pixmaps:  (1) unscaled, (2) scaled, and (3) scaled to "most appropriate".  The change you and I conspired actually changes this behavior to make #2 (scaled) work as #1 (unscaled).  (It probably also changes #3.)  This is the behavior I want for my current program, but it changes the intent of the original interface, so I'm afraid we are going to have to revert all those changes.



Digging deeper into Image.m3, I've discovered that it is smart-enough already to deduce the screen resolution.  If you look into the ApplyScaled1 procedure, you see that it converts the current screen resolution in millimeters to pixels in order to scale the pixmap.  The change we introduced, namely making Raw.xres/yres equal to the current screen resolution, effectively caused the Scaled procedure to do nothing since (ScreenDPI / ImageDPI) = 1.



The problem that brought all this on in the first place is that my GUI was looking bad on the 1920x1200 screen.  The reason I have discovered *now* is that FormsVBT apparently uses the #2 (scaled) version for pixmaps.  In the old code, the interface defaulted the developed resolution of the pixmaps to be 75 dpi.  At my 147+ dpi screen, the scaled implementation would effectively double the size of the pixmap when rendered on the screen in an effort to make the pixmap look the same size on the 147dpi screen that it appeared on a 75 dpi screen.



All of this to say that the changes to Image.i3/m3 need to be undone in order to get back the original intent of the developers.



Of course, once these changes are undone, my problem returns with the GUI looking bad on 1920x1200 at 147+ dpi.  So, how to solve it properly now requires more thought.



I need to do some more reading of the code I guess to see if there is a way already to cause FormsVBT to use unscaled for all pixmaps.  Otherwise, a quick fix would be to add a new procedure to the interface that would force use of the unscaled implementation.



Now, back to the problem of not being able to drag the subwindows, I'm still puzzled.  To test my "understanding" as related above, I went back to the original Image.i3/m3, but this time changed the Scaled procedure to effectively do the same thing as Unscaled.  The pixmaps render fine on the 1920x1200 monitor, but the subwindows still can't be dragged.  If I back out my change to Scaled (effectively, revert to the original Image.m3), the subwindows drag with ease on the 1920x1200 monitor, but of course the pixmaps look bad.  I can't explain this behavior yet.  Any ideas?



Regards,

Randy

>>> Jay  8/11/2008 2:41 PM>>>

MemoryBarrier ensures that all the reads and writes before it finish before any reads and writes after it.
Look at winnt.h or MSDN, as well the comment I put in explains it.
It probably has no effect, since our compiler is not aggressive.
What is confusing in these cases is the compiler and processor both need to be informed.
There is a concurrency issue and the barrier should make extra certain to solve it.

Multiple monitors are not considered.
Do you have them?

Randy, please experiment.
Change the code to return hard coded numbers -- like the old 75.
   Either without the globals, or initialize the globals.
And then add in the the various calls one at a time, ignoring their return values.

Furthermore, I guess you could just say:

    IF xres = 0 THEN Init() END;

and

    IF yres = 0 THEN Init() END;

and maybe change the globals to INTEGER.
Though REAL should be 32 bits and be written atomatically.

The idea is, even if the code does run multiple times concurrently, it should always return the same information.

Anyway, like I said, try various or every combination between the two and find
out which part triggers the difference, then we can think more about just that.

I might be able to get an expert friend to give me some help, later.

- Jay


________________________________

Date: Mon, 11 Aug 2008 12:15:40 -0400
From: rcoleburn at scires.com 
To: jay.krell at cornell.edu 
CC: wagner at elegosoft.com 
Subject: RE: strange problem w/new Image/ImageInit



Jay:



I tested your change, but it has no effect on the problem I am having.  I also tried having the accessor functions just return a hardcoded number, but again, no effect on the problem.  This is real strange to me, because if I remove ImageInit and revert Image.i3/m3 back to the way it was before, the problem disappears.



Questions,

1.  What does the WinNT.MemoryBarrier() call do?

2.  What would happen if this code was run by multiple threads?  Are there any concurrency issues that need to be guarded?

3.  What would happen in the case of multiple monitors at different resolutions?



Regards,

Randy

>>> Jay  8/11/2008 6:46 AM>>>

Also try the change I just commited with ReleaseDC.

- Jay


> From: jayk123 at hotmail.com 
> To: rcoleburn at scires.com 
> CC: wagner at elegosoft.com 
> Subject: RE: strange problem w/new Image/ImageInit
> Date: Mon, 11 Aug 2008 07:51:52 +0000
>
>
> Randy, this makes no sense to me.
> What happens if you just hardcode the numbers instead of computing them?
>
>
> - Jay
>
>
>
>
>
>
> ________________________________
>
>
>
> Date: Mon, 11 Aug 2008 02:55:56 -0400
> From: rcoleburn at scires.com 
> To: jayk123 at hotmail.com 
> CC: Olaf Wagner



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080812/e2ceef31/attachment.html>

From jay.krell at cornell.edu  Tue Aug 12 12:49:18 2008
From: jay.krell at cornell.edu (Jay)
Date: Tue, 12 Aug 2008 10:49:18 +0000
Subject: [M3devel] strange problem w/new Image/ImageInit
In-Reply-To: <48A110A3.1E75.00D7.1@scires.com>
References: <489FAA38.1E75.00D7.1@scires.com>
	<COL101-W158F68823847D036260F0FE6710@phx.gbl>
	<48A02D67.1E75.00D7.1@scires.com>
	<COL101-W13606B4823978F6670D3C9E6710@phx.gbl>
	<48A05960.1E75.00D7.1@scires.com>
	<COL101-W65ECE9C2B48E275288EAF0E6710@phx.gbl> 
	<48A110A3.1E75.00D7.1@scires.com>
Message-ID: <COL101-W48D58C2FBDE5BCD3163650E6700@phx.gbl>


Randy I don't think you need to add a way to use the unscaled data.
I think the fix is
a) go back to Image hardcoding 75
b) Have WinScreenType hardcode 96 or use GetDeviceCaps(LOGPIXELSX Y) -- same thing really.
And then see what happens.

Basically, the scale of pixmaps and the scale of screens has always been close to 1:1.
75:96, close enough.
Therefore, unscaled has been the norm.

Most GUI code uses GetDeviceCaps(LOGPIXELSX Y) I believe.
However, most code is not prepared to get back anything other than 96 from it.

Modula-3, at least for the pixmap code, was computing LOGPIXELSX and Y via a seemingly redundant equivalent way.
However, my believe is that LOGPIXELSX and Y is forced to lie, but the other route is not.
It seems an arbitrary discprecancy, but not beyond imagination.

By switching to the lying method, we will get back the nearly unscaled 75:96 behavior.

Vista adds a way for an application to declare that it is "high dpi aware", which then makes GetDeviceCaps(LOGPIXELX and Y) report the truth presumably. You can see, by the very existance of this ability to declare that you are high dpi aware -- to declare that your code is merely correct -- that most code is not correct.

What remains to be determined is why Modula-3 pixmaps behave "differently" than Modula-3 buttons, text, etc.

I also think there is a likely disconnect between painting and hit testing, but this is gross speculation.
I should fiddle with the numbers myself.

I will go ahead with a+b fairly soon.
I will verify the numbers computed in #b before and after.
I don't have any high dpi systems, so I expect the numbers to be roughly the same either way.
I think the only systems that will see a change are high dpi, and they will see an improvement.

Sorry for the back and forth regarding ImageInit -- a medium size change is going to be completely undone.

 - Jay

________________________________

Date: Tue, 12 Aug 2008 04:25:11 -0400
From: rcoleburn at scires.com
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] strange problem w/new Image/ImageInit



Jay:



For LOGPIXELS X & Y, I get 96 on the hi-res Dell M4300 system and also on my ThinkPad T60.



I've put together revised versions of Image.i3/m3 and my ScrollerVBTClass.m3.  The good news is that I've managed to get the scroll bar to look correct in both scaled and unscaled modes.



I've added a new procedure to Image.i3/m3 that will force subsequent calls to Scaled() to behave like Unscaled().  Using this, I can get the appearance I need on the hi-res monitor without resorting to changes in the original intent of the Image interface.  The advantage of this procedure is that it does not change the Image interface (except for addition of the procedure) and it therefore won't have any affect on pickles or anyone else's code.  Plus, it lets the programmer override use of Scaled() in all library modules without having to modify any source code.



Before I commit any of these changes, I want to do some more testing and to fix the problem with subwindows (ZChassisVBT) not being able to move.



Alas, my problem of the ZChassisVBTs not being able to move on the hi-res monitor persists with these changes, even though I left the xres/yres at 75.  Of course, these numbers are ignored for Unscaled images anyway.



I'm at a loss to explain this behavior.  Here is what I know based on testing:

1.  Using Scaled images and Image.Raw.xres/yres = 75.0, ZChassisVBT movement works on the hi-res monitor.

2.  Using Scaled images and Image.Raw.xres/yres set to 86.xxx or to 147.xxx, ZChassisVBT movement does not work on the hi-res 147.xxx dpi monitor, but it still works on my 86.xxx dpi monitor

3.  Using Unscaled images, ZChassisVBT movement does not work on the hi-res 147.xxx dpi monitor, but it still works on my 86.xxx dpi monitor



So, there seems to be something in the implementation somewhere of ZChassisVBT, or maybe ZMoveVBT, that doesn't like 147.xxx dpi monitors unless you scale all images assuming they were designed at 75 dpi.  At the 147 dpi, the 75 dpi pixmaps will be scaled by a factor of 2, which corresponds to what I am seeing on the screen.



I'm too sleepy to make any more progress for now.  If anyone has an idea on what to do next, please let me know.  I'm stumped at this point.



Regards,

Randy

>>> Jay  8/11/2008 3:52 PM>>>

Hm. Ok then, where does it get the screen resolution from?

Probably here?

WinScreenType.m3:

PROCEDURE InnerNew ((* IN-OUT *) res: T) =
  BEGIN
    WITH pix_hor = WinUser.GetSystemMetrics(WinUser.SM_CXSCREEN),
         pix_ver = WinUser.GetSystemMetrics(WinUser.SM_CYSCREEN),
         mm_hor  = GetDeviceCaps (WinGDI.HORZSIZE),
         mm_ver  = GetDeviceCaps (WinGDI.VERTSIZE) DO
      res.rootDom := Rect.FromSize(pix_hor, pix_ver);
      res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
      res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);

ok.

Perhaps we should accept the numbers that Windows makes up instead?

GetDeviceCaps(LOGPIXELSX)
and GetDeviceCaps(LOGPIXELSY)

Please try that, in the WinScreenType.m3 code.
With removing ImageInit (or just have it hardcoded at 75).

This will most likely be 96 even on your high dpi system, unless you are on Vista
and tell the system you are high dpi aware.

I think there is disagreement in drawing vs. hit test as to where you are clicking.
Try making ImageInit always 75.
Try making the above convert from a hardcoded 96.
And then try GetDeviceCaps(LOGPIXELSX and Y) -- which I expect always returns 96 for you.
You can plug that into my dpi.c to see what it prints.

I think part of what is happening is that Modula-3 was very rare in doing the right thing for high dpi
monitors. But so much code is wrong that Windows has to counteract the wrongness,
which means Modula-3 needs to go along and do things wrong in order for the counteraction
to leave it doing the right thing also.
I'm not sure.
Oh, and presumably other places in Modula-3 are wrong, and the counteraction works for them.
That's a bit of a mystery -- drawing of pixmaps vs. drawing of everything else.

- Jay


________________________________

Date: Mon, 11 Aug 2008 15:23:17 -0400
From: rcoleburn at scires.com
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com; wagner at elegosoft.com
Subject: RE: strange problem w/new Image/ImageInit



Jay:



I have been experimenting quite a bit and I've come up with some "new old" information.



I say "new old" because, after spending the time to read some of the comments in the original code (before we modified it), I think I now have a better idea of what the designers intended and why I had/have a problem.



If you read carefully, the xres/yres fields in Image.Raw are supposed to represent the resolution at which the pixmap was originally DEVELOPED, not the resolution of the current screen.  It seems the designers went to great lengths to represent everything as screen-independent until it is actually rendered.



The Image interface gives 3 ways of dealing with pixmaps:  (1) unscaled, (2) scaled, and (3) scaled to "most appropriate".  The change you and I conspired actually changes this behavior to make #2 (scaled) work as #1 (unscaled).  (It probably also changes #3.)  This is the behavior I want for my current program, but it changes the intent of the original interface, so I'm afraid we are going to have to revert all those changes.



Digging deeper into Image.m3, I've discovered that it is smart-enough already to deduce the screen resolution.  If you look into the ApplyScaled1 procedure, you see that it converts the current screen resolution in millimeters to pixels in order to scale the pixmap.  The change we introduced, namely making Raw.xres/yres equal to the current screen resolution, effectively caused the Scaled procedure to do nothing since (ScreenDPI / ImageDPI) = 1.



The problem that brought all this on in the first place is that my GUI was looking bad on the 1920x1200 screen.  The reason I have discovered *now* is that FormsVBT apparently uses the #2 (scaled) version for pixmaps.  In the old code, the interface defaulted the developed resolution of the pixmaps to be 75 dpi.  At my 147+ dpi screen, the scaled implementation would effectively double the size of the pixmap when rendered on the screen in an effort to make the pixmap look the same size on the 147dpi screen that it appeared on a 75 dpi screen.



All of this to say that the changes to Image.i3/m3 need to be undone in order to get back the original intent of the developers.



Of course, once these changes are undone, my problem returns with the GUI looking bad on 1920x1200 at 147+ dpi.  So, how to solve it properly now requires more thought.



I need to do some more reading of the code I guess to see if there is a way already to cause FormsVBT to use unscaled for all pixmaps.  Otherwise, a quick fix would be to add a new procedure to the interface that would force use of the unscaled implementation.



Now, back to the problem of not being able to drag the subwindows, I'm still puzzled.  To test my "understanding" as related above, I went back to the original Image.i3/m3, but this time changed the Scaled procedure to effectively do the same thing as Unscaled.  The pixmaps render fine on the 1920x1200 monitor, but the subwindows still can't be dragged.  If I back out my change to Scaled (effectively, revert to the original Image.m3), the subwindows drag with ease on the 1920x1200 monitor, but of course the pixmaps look bad.  I can't explain this behavior yet.  Any ideas?



Regards,

Randy

>>> Jay  8/11/2008 2:41 PM>>>

MemoryBarrier ensures that all the reads and writes before it finish before any reads and writes after it.
Look at winnt.h or MSDN, as well the comment I put in explains it.
It probably has no effect, since our compiler is not aggressive.
What is confusing in these cases is the compiler and processor both need to be informed.
There is a concurrency issue and the barrier should make extra certain to solve it.

Multiple monitors are not considered.
Do you have them?

Randy, please experiment.
Change the code to return hard coded numbers -- like the old 75.
   Either without the globals, or initialize the globals.
And then add in the the various calls one at a time, ignoring their return values.

Furthermore, I guess you could just say:

    IF xres = 0 THEN Init() END;

and

    IF yres = 0 THEN Init() END;

and maybe change the globals to INTEGER.
Though REAL should be 32 bits and be written atomatically.

The idea is, even if the code does run multiple times concurrently, it should always return the same information.

Anyway, like I said, try various or every combination between the two and find
out which part triggers the difference, then we can think more about just that.

I might be able to get an expert friend to give me some help, later.

- Jay


________________________________

Date: Mon, 11 Aug 2008 12:15:40 -0400
From: rcoleburn at scires.com
To: jay.krell at cornell.edu
CC: wagner at elegosoft.com
Subject: RE: strange problem w/new Image/ImageInit



Jay:



I tested your change, but it has no effect on the problem I am having.  I also tried having the accessor functions just return a hardcoded number, but again, no effect on the problem.  This is real strange to me, because if I remove ImageInit and revert Image.i3/m3 back to the way it was before, the problem disappears.



Questions,

1.  What does the WinNT.MemoryBarrier() call do?

2.  What would happen if this code was run by multiple threads?  Are there any concurrency issues that need to be guarded?

3.  What would happen in the case of multiple monitors at different resolutions?



Regards,

Randy

>>> Jay  8/11/2008 6:46 AM>>>

Also try the change I just commited with ReleaseDC.

- Jay


> From: jayk123 at hotmail.com
> To: rcoleburn at scires.com
> CC: wagner at elegosoft.com
> Subject: RE: strange problem w/new Image/ImageInit
> Date: Mon, 11 Aug 2008 07:51:52 +0000
>
>
> Randy, this makes no sense to me.
> What happens if you just hardcode the numbers instead of computing them?
>
>
> - Jay
>
>
>
>
>
>
> ________________________________
>
>
>
> Date: Mon, 11 Aug 2008 02:55:56 -0400
> From: rcoleburn at scires.com
> To: jayk123 at hotmail.com
> CC: Olaf Wagner





From jay.krell at cornell.edu  Tue Aug 12 12:54:27 2008
From: jay.krell at cornell.edu (Jay)
Date: Tue, 12 Aug 2008 10:54:27 +0000
Subject: [M3devel] strange problem w/new Image/ImageInit
In-Reply-To: <48A110A3.1E75.00D7.1@scires.com>
References: <489FAA38.1E75.00D7.1@scires.com>
	<COL101-W158F68823847D036260F0FE6710@phx.gbl>
	<48A02D67.1E75.00D7.1@scires.com>
	<COL101-W13606B4823978F6670D3C9E6710@phx.gbl>
	<48A05960.1E75.00D7.1@scires.com>
	<COL101-W65ECE9C2B48E275288EAF0E6710@phx.gbl> 
	<48A110A3.1E75.00D7.1@scires.com> 
Message-ID: <COL101-W731093036BEC825D730370E6700@phx.gbl>


ps: Randy, does the high dpi system run XP or Vista?
I suppose I should try to acquire a high dpi system but I'd rather not waste the money.

(I'd rather waste on getting HP-UX/IA64/AIX/VMS systems to bring Modula-3 back up on them
and put out current releases. : )) (I have an Irix system, haven't powered it up yet.)

On Vista there is a way to get the "real" dpi via this same api.
You have to declare you are high dpi "aware".

 - Jay


From rcoleburn at scires.com  Tue Aug 12 17:01:23 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Tue, 12 Aug 2008 11:01:23 -0400
Subject: [M3devel] strange problem w/new Image/ImageInit
In-Reply-To: <COL101-W731093036BEC825D730370E6700@phx.gbl>
References: <489FAA38.1E75.00D7.1@scires.com>
	<COL101-W158F68823847D036260F0FE6710@phx.gbl>
	<48A02D67.1E75.00D7.1@scires.com>
	<COL101-W13606B4823978F6670D3C9E6710@phx.gbl>
	<48A05960.1E75.00D7.1@scires.com>
	<COL101-W65ECE9C2B48E275288EAF0E6710@phx.gbl>
	<48A110A3.1E75.00D7.1@scires.com>
	<COL101-W731093036BEC825D730370E6700@phx.gbl>
Message-ID: <48A16D7B.1E75.00D7.1@scires.com>

Jay:
 
I am running XP, not Vista.
 
Regards,
Randy

>>> Jay <jay.krell at cornell.edu> 8/12/2008 6:54 AM >>>

ps: Randy, does the high dpi system run XP or Vista?
I suppose I should try to acquire a high dpi system but I'd rather not waste the money.

(I'd rather waste on getting HP-UX/IA64/AIX/VMS systems to bring Modula-3 back up on them
and put out current releases. : )) (I have an Irix system, haven't powered it up yet.)

On Vista there is a way to get the "real" dpi via this same api.
You have to declare you are high dpi "aware".

- Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080812/d17ec5bd/attachment.html>

From rcoleburn at scires.com  Tue Aug 12 17:51:25 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Tue, 12 Aug 2008 11:51:25 -0400
Subject: [M3devel] strange problem w/new Image/ImageInit
In-Reply-To: <COL101-W48D58C2FBDE5BCD3163650E6700@phx.gbl>
References: <489FAA38.1E75.00D7.1@scires.com>
	<COL101-W158F68823847D036260F0FE6710@phx.gbl>
	<48A02D67.1E75.00D7.1@scires.com>
	<COL101-W13606B4823978F6670D3C9E6710@phx.gbl>
	<48A05960.1E75.00D7.1@scires.com>
	<COL101-W65ECE9C2B48E275288EAF0E6710@phx.gbl>
	<48A110A3.1E75.00D7.1@scires.com>
	<COL101-W48D58C2FBDE5BCD3163650E6700@phx.gbl>
Message-ID: <48A17936.1E75.00D7.1@scires.com>

Jay:
 
Thanks for your insights here.  I'll try some more tests and see what I come up with.  I've attached my current Image.i3/Image.m3 and Win32/ScrollerVBTClass.m3 for your reference.  I've removed use of ImageInit from all of these.  And yes, I have reverted to the 75.0 hardcoded value.
 
Based on my limited understanding of the code, I still think I will get scaled behavior even if Modula-3 thinks the dpi is 96, because 147 / 96 =  1.53125, which rounds to 2.  So my pixmaps will still appear double-size.
 
In actuality, I think Modula-3 is trying to do the right thing with the scaling.  At some point on a high-enough dpi monitor, the pixmaps will be so tiny that you can't really see them if they are unscaled.  I've already observed this with some of my boolean and choice indicators--I had to reduce the shadowsize in order to tell whether the boolean/choice was TRUE or FALSE.  From the way Trestle/FormsVBT are set up, it appears that the designers wanted to get approximately the same size rendering on different dpi screens.  That's why you see millimeters everywhere in the code being converted to pixels.  Indeed, VBT has a procedure MMToPixels that is dependent on getting the screen type of the underlying VBT.T so it can get the ppm setting for this screen and do the computation.  Provided that the underlying implementation gives correct ppm info to Modula-3 for each screen, the current Trestle/FormsVBT should do the right thing even in multiple monitor situations.  I haven't tested this, but I should be able to drag a window from a monitor at one dpi onto a monitor at a different dpi and have everything scale to look correct on the new monitor.
 
The problem in my case with the 1920x1200 monitor is that the scaled pixmaps look huge in proportion to the text and other features of the window.  Maybe this other stuff isn't being scaled the same way pixmaps are scaled.
 
Does LOGPIXELSX stand for Logical Pixels X-Axis ?  I know that Windows has a dpi setting for fonts.  If set to normal, fonts are supposed to render at 96 dpi, but you can switch to large mode and have them rendered at 120 dpi, or you can make up a custom number.  This Windows setting applies only to fonts, not graphical elements.
 
You say that Modula-3 is computing LOGPIXELS via a "seemingly redundant equivalent way."  In my reading of the code in WinScreenType, it appears that Modula-3 is requesting from Windows the actual number of pixels in both axes and also the number of millimeters in both axes.  It uses these to compute the resolution in pixels per millimeter (ppm).  The ppm is what is stored and used internally when scaling pixmaps.  When necessary, ppm is converted to dpi using the formula (dpi = ppm x 25.4).
 
On my 4:3 aspect ratio IBM T60 at 1280x1024, the ppm is 3.41333 in both axes yielding a dpi of 86.698667.
 
On the widescreen (16:10 aspect ratio) Dell 4300 at 1920x1200 the ppm is slightly different in each axis, but is close to 5.8xxx yielding at dpi of 147.xxx  (again, the fractional part is different in each axis).
 
I don't mind running a test program for you on the hi-res system here--just send it to me via email.  I have the VC++ 2008 redistributables installed.
 
I think you are on the west coast and I'm on the east coast, so we have a time difference of 3 hours, but lately I've been working round the clock seemingly, so I'll try to respond with test results as soon as I can.
 
Regards,
Randy

>>> Jay <jay.krell at cornell.edu> 8/12/2008 6:49 AM >>>

Randy I don't think you need to add a way to use the unscaled data.
I think the fix is
a) go back to Image hardcoding 75
b) Have WinScreenType hardcode 96 or use GetDeviceCaps(LOGPIXELSX Y) -- same thing really.
And then see what happens.

Basically, the scale of pixmaps and the scale of screens has always been close to 1:1.
75:96, close enough.
Therefore, unscaled has been the norm.

Most GUI code uses GetDeviceCaps(LOGPIXELSX Y) I believe.
However, most code is not prepared to get back anything other than 96 from it.

Modula-3, at least for the pixmap code, was computing LOGPIXELSX and Y via a seemingly redundant equivalent way.
However, my believe is that LOGPIXELSX and Y is forced to lie, but the other route is not.
It seems an arbitrary discprecancy, but not beyond imagination.

By switching to the lying method, we will get back the nearly unscaled 75:96 behavior.

Vista adds a way for an application to declare that it is "high dpi aware", which then makes GetDeviceCaps(LOGPIXELX and Y) report the truth presumably. You can see, by the very existance of this ability to declare that you are high dpi aware -- to declare that your code is merely correct -- that most code is not correct.

What remains to be determined is why Modula-3 pixmaps behave "differently" than Modula-3 buttons, text, etc.

I also think there is a likely disconnect between painting and hit testing, but this is gross speculation.
I should fiddle with the numbers myself.

I will go ahead with a+b fairly soon.
I will verify the numbers computed in #b before and after.
I don't have any high dpi systems, so I expect the numbers to be roughly the same either way.
I think the only systems that will see a change are high dpi, and they will see an improvement.

Sorry for the back and forth regarding ImageInit -- a medium size change is going to be completely undone.

- Jay

________________________________

Date: Tue, 12 Aug 2008 04:25:11 -0400
From: rcoleburn at scires.com 
To: jay.krell at cornell.edu 
CC: m3devel at elegosoft.com 
Subject: Re: [M3devel] strange problem w/new Image/ImageInit



Jay:



For LOGPIXELS X & Y, I get 96 on the hi-res Dell M4300 system and also on my ThinkPad T60.



I've put together revised versions of Image.i3/m3 and my ScrollerVBTClass.m3.  The good news is that I've managed to get the scroll bar to look correct in both scaled and unscaled modes.



I've added a new procedure to Image.i3/m3 that will force subsequent calls to Scaled() to behave like Unscaled().  Using this, I can get the appearance I need on the hi-res monitor without resorting to changes in the original intent of the Image interface.  The advantage of this procedure is that it does not change the Image interface (except for addition of the procedure) and it therefore won't have any affect on pickles or anyone else's code.  Plus, it lets the programmer override use of Scaled() in all library modules without having to modify any source code.



Before I commit any of these changes, I want to do some more testing and to fix the problem with subwindows (ZChassisVBT) not being able to move.



Alas, my problem of the ZChassisVBTs not being able to move on the hi-res monitor persists with these changes, even though I left the xres/yres at 75.  Of course, these numbers are ignored for Unscaled images anyway.



I'm at a loss to explain this behavior.  Here is what I know based on testing:

1.  Using Scaled images and Image.Raw.xres/yres = 75.0, ZChassisVBT movement works on the hi-res monitor.

2.  Using Scaled images and Image.Raw.xres/yres set to 86.xxx or to 147.xxx, ZChassisVBT movement does not work on the hi-res 147.xxx dpi monitor, but it still works on my 86.xxx dpi monitor

3.  Using Unscaled images, ZChassisVBT movement does not work on the hi-res 147.xxx dpi monitor, but it still works on my 86.xxx dpi monitor



So, there seems to be something in the implementation somewhere of ZChassisVBT, or maybe ZMoveVBT, that doesn't like 147.xxx dpi monitors unless you scale all images assuming they were designed at 75 dpi.  At the 147 dpi, the 75 dpi pixmaps will be scaled by a factor of 2, which corresponds to what I am seeing on the screen.



I'm too sleepy to make any more progress for now.  If anyone has an idea on what to do next, please let me know.  I'm stumped at this point.



Regards,

Randy

>>> Jay  8/11/2008 3:52 PM>>>

Hm. Ok then, where does it get the screen resolution from?

Probably here?

WinScreenType.m3:

PROCEDURE InnerNew ((* IN-OUT *) res: T) =
  BEGIN
    WITH pix_hor = WinUser.GetSystemMetrics(WinUser.SM_CXSCREEN),
         pix_ver = WinUser.GetSystemMetrics(WinUser.SM_CYSCREEN),
         mm_hor  = GetDeviceCaps (WinGDI.HORZSIZE),
         mm_ver  = GetDeviceCaps (WinGDI.VERTSIZE) DO
      res.rootDom := Rect.FromSize(pix_hor, pix_ver);
      res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
      res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);

ok.

Perhaps we should accept the numbers that Windows makes up instead?

GetDeviceCaps(LOGPIXELSX)
and GetDeviceCaps(LOGPIXELSY)

Please try that, in the WinScreenType.m3 code.
With removing ImageInit (or just have it hardcoded at 75).

This will most likely be 96 even on your high dpi system, unless you are on Vista
and tell the system you are high dpi aware.

I think there is disagreement in drawing vs. hit test as to where you are clicking.
Try making ImageInit always 75.
Try making the above convert from a hardcoded 96.
And then try GetDeviceCaps(LOGPIXELSX and Y) -- which I expect always returns 96 for you.
You can plug that into my dpi.c to see what it prints.

I think part of what is happening is that Modula-3 was very rare in doing the right thing for high dpi
monitors. But so much code is wrong that Windows has to counteract the wrongness,
which means Modula-3 needs to go along and do things wrong in order for the counteraction
to leave it doing the right thing also.
I'm not sure.
Oh, and presumably other places in Modula-3 are wrong, and the counteraction works for them.
That's a bit of a mystery -- drawing of pixmaps vs. drawing of everything else.

- Jay


________________________________

Date: Mon, 11 Aug 2008 15:23:17 -0400
From: rcoleburn at scires.com 
To: jay.krell at cornell.edu 
CC: m3devel at elegosoft.com; wagner at elegosoft.com 
Subject: RE: strange problem w/new Image/ImageInit



Jay:



I have been experimenting quite a bit and I've come up with some "new old" information.



I say "new old" because, after spending the time to read some of the comments in the original code (before we modified it), I think I now have a better idea of what the designers intended and why I had/have a problem.



If you read carefully, the xres/yres fields in Image.Raw are supposed to represent the resolution at which the pixmap was originally DEVELOPED, not the resolution of the current screen.  It seems the designers went to great lengths to represent everything as screen-independent until it is actually rendered.



The Image interface gives 3 ways of dealing with pixmaps:  (1) unscaled, (2) scaled, and (3) scaled to "most appropriate".  The change you and I conspired actually changes this behavior to make #2 (scaled) work as #1 (unscaled).  (It probably also changes #3.)  This is the behavior I want for my current program, but it changes the intent of the original interface, so I'm afraid we are going to have to revert all those changes.



Digging deeper into Image.m3, I've discovered that it is smart-enough already to deduce the screen resolution.  If you look into the ApplyScaled1 procedure, you see that it converts the current screen resolution in millimeters to pixels in order to scale the pixmap.  The change we introduced, namely making Raw.xres/yres equal to the current screen resolution, effectively caused the Scaled procedure to do nothing since (ScreenDPI / ImageDPI) = 1.



The problem that brought all this on in the first place is that my GUI was looking bad on the 1920x1200 screen.  The reason I have discovered *now* is that FormsVBT apparently uses the #2 (scaled) version for pixmaps.  In the old code, the interface defaulted the developed resolution of the pixmaps to be 75 dpi.  At my 147+ dpi screen, the scaled implementation would effectively double the size of the pixmap when rendered on the screen in an effort to make the pixmap look the same size on the 147dpi screen that it appeared on a 75 dpi screen.



All of this to say that the changes to Image.i3/m3 need to be undone in order to get back the original intent of the developers.



Of course, once these changes are undone, my problem returns with the GUI looking bad on 1920x1200 at 147+ dpi.  So, how to solve it properly now requires more thought.



I need to do some more reading of the code I guess to see if there is a way already to cause FormsVBT to use unscaled for all pixmaps.  Otherwise, a quick fix would be to add a new procedure to the interface that would force use of the unscaled implementation.



Now, back to the problem of not being able to drag the subwindows, I'm still puzzled.  To test my "understanding" as related above, I went back to the original Image.i3/m3, but this time changed the Scaled procedure to effectively do the same thing as Unscaled.  The pixmaps render fine on the 1920x1200 monitor, but the subwindows still can't be dragged.  If I back out my change to Scaled (effectively, revert to the original Image.m3), the subwindows drag with ease on the 1920x1200 monitor, but of course the pixmaps look bad.  I can't explain this behavior yet.  Any ideas?



Regards,

Randy

>>> Jay  8/11/2008 2:41 PM>>>

MemoryBarrier ensures that all the reads and writes before it finish before any reads and writes after it.
Look at winnt.h or MSDN, as well the comment I put in explains it.
It probably has no effect, since our compiler is not aggressive.
What is confusing in these cases is the compiler and processor both need to be informed.
There is a concurrency issue and the barrier should make extra certain to solve it.

Multiple monitors are not considered.
Do you have them?

Randy, please experiment.
Change the code to return hard coded numbers -- like the old 75.
   Either without the globals, or initialize the globals.
And then add in the the various calls one at a time, ignoring their return values.

Furthermore, I guess you could just say:

    IF xres = 0 THEN Init() END;

and

    IF yres = 0 THEN Init() END;

and maybe change the globals to INTEGER.
Though REAL should be 32 bits and be written atomatically.

The idea is, even if the code does run multiple times concurrently, it should always return the same information.

Anyway, like I said, try various or every combination between the two and find
out which part triggers the difference, then we can think more about just that.

I might be able to get an expert friend to give me some help, later.

- Jay


________________________________

Date: Mon, 11 Aug 2008 12:15:40 -0400
From: rcoleburn at scires.com 
To: jay.krell at cornell.edu 
CC: wagner at elegosoft.com 
Subject: RE: strange problem w/new Image/ImageInit



Jay:



I tested your change, but it has no effect on the problem I am having.  I also tried having the accessor functions just return a hardcoded number, but again, no effect on the problem.  This is real strange to me, because if I remove ImageInit and revert Image.i3/m3 back to the way it was before, the problem disappears.



Questions,

1.  What does the WinNT.MemoryBarrier() call do?

2.  What would happen if this code was run by multiple threads?  Are there any concurrency issues that need to be guarded?

3.  What would happen in the case of multiple monitors at different resolutions?



Regards,

Randy

>>> Jay  8/11/2008 6:46 AM>>>

Also try the change I just commited with ReleaseDC.

- Jay


> From: jayk123 at hotmail.com 
> To: rcoleburn at scires.com 
> CC: wagner at elegosoft.com 
> Subject: RE: strange problem w/new Image/ImageInit
> Date: Mon, 11 Aug 2008 07:51:52 +0000
>
>
> Randy, this makes no sense to me.
> What happens if you just hardcode the numbers instead of computing them?
>
>
> - Jay
>
>
>
>
>
>
> ________________________________
>
>
>
> Date: Mon, 11 Aug 2008 02:55:56 -0400
> From: rcoleburn at scires.com 
> To: jayk123 at hotmail.com 
> CC: Olaf Wagner




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080812/607eed9b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ScrollerVBTClass.m3
Type: application/octet-stream
Size: 26638 bytes
Desc: not available
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080812/607eed9b/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Image.m3
Type: application/octet-stream
Size: 29271 bytes
Desc: not available
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080812/607eed9b/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Image.i3
Type: application/octet-stream
Size: 13111 bytes
Desc: not available
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080812/607eed9b/attachment-0002.obj>

From jay.krell at cornell.edu  Tue Aug 12 21:58:42 2008
From: jay.krell at cornell.edu (Jay)
Date: Tue, 12 Aug 2008 19:58:42 +0000
Subject: [M3devel] strange problem w/new Image/ImageInit
In-Reply-To: <48A17936.1E75.00D7.1@scires.com>
References: <489FAA38.1E75.00D7.1@scires.com>
	<COL101-W158F68823847D036260F0FE6710@phx.gbl>
	<48A02D67.1E75.00D7.1@scires.com>
	<COL101-W13606B4823978F6670D3C9E6710@phx.gbl>
	<48A05960.1E75.00D7.1@scires.com>
	<COL101-W65ECE9C2B48E275288EAF0E6710@phx.gbl>
	<48A110A3.1E75.00D7.1@scires.com>
	<COL101-W48D58C2FBDE5BCD3163650E6700@phx.gbl> 
	<48A17936.1E75.00D7.1@scires.com>
Message-ID: <COL101-W7934CC09223B996946776EE6700@phx.gbl>


Twice I've lost my message here, darnit.
LOGPIXELSX (look it up on MSDN/Google/LiveSearch) is pixels per inch on the x axis. It is stuck at 96 for compatibility. And the docs say it has just one value in a multimon situation.
So you can ask Windows for pixels per inch and get 96.
Or you can ask for pixels and millimeters and do the division and get the truth.
Or you can tell it you are "high dpi aware" on Vista and get the truth either way.
I understand the attempt to do the right thing, but it clearly doesn't work out -- the rest of the gui doesn't scale/move correctly with it.
What makes sense and is ideal is often at odds with the bulk of existing code. The bulk of existing code wins, and sometimes nobody can do the right thing in contradiction do it.
 
 - Jay



Date: Tue, 12 Aug 2008 11:51:25 -0400From: rcoleburn at scires.comTo: jay.krell at cornell.eduCC: m3devel at elegosoft.comSubject: Re: [M3devel] strange problem w/new Image/ImageInit

Jay:
 
Thanks for your insights here.  I'll try some more tests and see what I come up with.  I've attached my current Image.i3/Image.m3 and Win32/ScrollerVBTClass.m3 for your reference.  I've removed use of ImageInit from all of these.  And yes, I have reverted to the 75.0 hardcoded value.
 
Based on my limited understanding of the code, I still think I will get scaled behavior even if Modula-3 thinks the dpi is 96, because 147 / 96 =  1.53125, which rounds to 2.  So my pixmaps will still appear double-size.
 
In actuality, I think Modula-3 is trying to do the right thing with the scaling.  At some point on a high-enough dpi monitor, the pixmaps will be so tiny that you can't really see them if they are unscaled.  I've already observed this with some of my boolean and choice indicators--I had to reduce the shadowsize in order to tell whether the boolean/choice was TRUE or FALSE.  From the way Trestle/FormsVBT are set up, it appears that the designers wanted to get approximately the same size rendering on different dpi screens.  That's why you see millimeters everywhere in the code being converted to pixels.  Indeed, VBT has a procedure MMToPixels that is dependent on getting the screen type of the underlying VBT.T so it can get the ppm setting for this screen and do the computation.  Provided that the underlying implementation gives correct ppm info to Modula-3 for each screen, the current Trestle/FormsVBT should do the right thing even in multiple monitor situations.  I haven't tested this, but I should be able to drag a window from a monitor at one dpi onto a monitor at a different dpi and have everything scale to look correct on the new monitor.
 
The problem in my case with the 1920x1200 monitor is that the scaled pixmaps look huge in proportion to the text and other features of the window.  Maybe this other stuff isn't being scaled the same way pixmaps are scaled.
 
Does LOGPIXELSX stand for Logical Pixels X-Axis ?  I know that Windows has a dpi setting for fonts.  If set to normal, fonts are supposed to render at 96 dpi, but you can switch to large mode and have them rendered at 120 dpi, or you can make up a custom number.  This Windows setting applies only to fonts, not graphical elements.
 
You say that Modula-3 is computing LOGPIXELS via a "seemingly redundant equivalent way."  In my reading of the code in WinScreenType, it appears that Modula-3 is requesting from Windows the actual number of pixels in both axes and also the number of millimeters in both axes.  It uses these to compute the resolution in pixels per millimeter (ppm).  The ppm is what is stored and used internally when scaling pixmaps.  When necessary, ppm is converted to dpi using the formula (dpi = ppm x 25.4).
 
On my 4:3 aspect ratio IBM T60 at 1280x1024, the ppm is 3.41333 in both axes yielding a dpi of 86.698667.
 
On the widescreen (16:10 aspect ratio) Dell 4300 at 1920x1200 the ppm is slightly different in each axis, but is close to 5.8xxx yielding at dpi of 147.xxx  (again, the fractional part is different in each axis).
 
I don't mind running a test program for you on the hi-res system here--just send it to me via email.  I have the VC++ 2008 redistributables installed.
 
I think you are on the west coast and I'm on the east coast, so we have a time difference of 3 hours, but lately I've been working round the clock seemingly, so I'll try to respond with test results as soon as I can.
 
Regards,
Randy>>> Jay <jay.krell at cornell.edu> 8/12/2008 6:49 AM >>>Randy I don't think you need to add a way to use the unscaled data.I think the fix isa) go back to Image hardcoding 75b) Have WinScreenType hardcode 96 or use GetDeviceCaps(LOGPIXELSX Y) -- same thing really.And then see what happens.Basically, the scale of pixmaps and the scale of screens has always been close to 1:1.75:96, close enough.Therefore, unscaled has been the norm.Most GUI code uses GetDeviceCaps(LOGPIXELSX Y) I believe.However, most code is not prepared to get back anything other than 96 from it.Modula-3, at least for the pixmap code, was computing LOGPIXELSX and Y via a seemingly redundant equivalent way.However, my believe is that LOGPIXELSX and Y is forced to lie, but the other route is not.It seems an arbitrary discprecancy, but not beyond imagination.By switching to the lying method, we will get back the nearly unscaled 75:96 behavior.Vista adds a way for an application to declare that it is "high dpi aware", which then makes GetDeviceCaps(LOGPIXELX and Y) report the truth presumably. You can see, by the very existance of this ability to declare that you are high dpi aware -- to declare that your code is merely correct -- that most code is not correct.What remains to be determined is why Modula-3 pixmaps behave "differently" than Modula-3 buttons, text, etc.I also think there is a likely disconnect between painting and hit testing, but this is gross speculation.I should fiddle with the numbers myself.I will go ahead with a+b fairly soon.I will verify the numbers computed in #b before and after.I don't have any high dpi systems, so I expect the numbers to be roughly the same either way.I think the only systems that will see a change are high dpi, and they will see an improvement.Sorry for the back and forth regarding ImageInit -- a medium size change is going to be completely undone.- Jay________________________________Date: Tue, 12 Aug 2008 04:25:11 -0400From: rcoleburn at scires.comTo: jay.krell at cornell.eduCC: m3devel at elegosoft.comSubject: Re: [M3devel] strange problem w/new Image/ImageInitJay:For LOGPIXELS X & Y, I get 96 on the hi-res Dell M4300 system and also on my ThinkPad T60.I've put together revised versions of Image.i3/m3 and my ScrollerVBTClass.m3.  The good news is that I've managed to get the scroll bar to look correct in both scaled and unscaled modes.I've added a new procedure to Image.i3/m3 that will force subsequent calls to Scaled() to behave like Unscaled().  Using this, I can get the appearance I need on the hi-res monitor without resorting to changes in the original intent of the Image interface.  The advantage of this procedure is that it does not change the Image interface (except for addition of the procedure) and it therefore won't have any affect on pickles or anyone else's code.  Plus, it lets the programmer override use of Scaled() in all library modules without having to modify any source code.Before I commit any of these changes, I want to do some more testing and to fix the problem with subwindows (ZChassisVBT) not being able to move.Alas, my problem of the ZChassisVBTs not being able to move on the hi-res monitor persists with these changes, even though I left the xres/yres at 75.  Of course, these numbers are ignored for Unscaled images anyway.I'm at a loss to explain this behavior.  Here is what I know based on testing:1.  Using Scaled images and Image.Raw.xres/yres = 75.0, ZChassisVBT movement works on the hi-res monitor.2.  Using Scaled images and Image.Raw.xres/yres set to 86.xxx or to 147.xxx, ZChassisVBT movement does not work on the hi-res 147.xxx dpi monitor, but it still works on my 86.xxx dpi monitor3.  Using Unscaled images, ZChassisVBT movement does not work on the hi-res 147.xxx dpi monitor, but it still works on my 86.xxx dpi monitorSo, there seems to be something in the implementation somewhere of ZChassisVBT, or maybe ZMoveVBT, that doesn't like 147.xxx dpi monitors unless you scale all images assuming they were designed at 75 dpi.  At the 147 dpi, the 75 dpi pixmaps will be scaled by a factor of 2, which corresponds to what I am seeing on the screen.I'm too sleepy to make any more progress for now.  If anyone has an idea on what to do next, please let me know.  I'm stumped at this point.Regards,Randy>>> Jay  8/11/2008 3:52 PM>>>Hm. Ok then, where does it get the screen resolution from?Probably here?WinScreenType.m3:PROCEDURE InnerNew ((* IN-OUT *) res: T) =  BEGIN    WITH pix_hor = WinUser.GetSystemMetrics(WinUser.SM_CXSCREEN),         pix_ver = WinUser.GetSystemMetrics(WinUser.SM_CYSCREEN),         mm_hor  = GetDeviceCaps (WinGDI.HORZSIZE),         mm_ver  = GetDeviceCaps (WinGDI.VERTSIZE) DO      res.rootDom := Rect.FromSize(pix_hor, pix_ver);      res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);      res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);ok.Perhaps we should accept the numbers that Windows makes up instead?GetDeviceCaps(LOGPIXELSX)and GetDeviceCaps(LOGPIXELSY)Please try that, in the WinScreenType.m3 code.With removing ImageInit (or just have it hardcoded at 75).This will most likely be 96 even on your high dpi system, unless you are on Vistaand tell the system you are high dpi aware.I think there is disagreement in drawing vs. hit test as to where you are clicking.Try making ImageInit always 75.Try making the above convert from a hardcoded 96.And then try GetDeviceCaps(LOGPIXELSX and Y) -- which I expect always returns 96 for you.You can plug that into my dpi.c to see what it prints.I think part of what is happening is that Modula-3 was very rare in doing the right thing for high dpimonitors. But so much code is wrong that Windows has to counteract the wrongness,which means Modula-3 needs to go along and do things wrong in order for the counteractionto leave it doing the right thing also.I'm not sure.Oh, and presumably other places in Modula-3 are wrong, and the counteraction works for them.That's a bit of a mystery -- drawing of pixmaps vs. drawing of everything else.- Jay________________________________Date: Mon, 11 Aug 2008 15:23:17 -0400From: rcoleburn at scires.comTo: jay.krell at cornell.eduCC: m3devel at elegosoft.com; wagner at elegosoft.comSubject: RE: strange problem w/new Image/ImageInitJay:I have been experimenting quite a bit and I've come up with some "new old" information.I say "new old" because, after spending the time to read some of the comments in the original code (before we modified it), I think I now have a better idea of what the designers intended and why I had/have a problem.If you read carefully, the xres/yres fields in Image.Raw are supposed to represent the resolution at which the pixmap was originally DEVELOPED, not the resolution of the current screen.  It seems the designers went to great lengths to represent everything as screen-independent until it is actually rendered.The Image interface gives 3 ways of dealing with pixmaps:  (1) unscaled, (2) scaled, and (3) scaled to "most appropriate".  The change you and I conspired actually changes this behavior to make #2 (scaled) work as #1 (unscaled).  (It probably also changes #3.)  This is the behavior I want for my current program, but it changes the intent of the original interface, so I'm afraid we are going to have to revert all those changes.Digging deeper into Image.m3, I've discovered that it is smart-enough already to deduce the screen resolution.  If you look into the ApplyScaled1 procedure, you see that it converts the current screen resolution in millimeters to pixels in order to scale the pixmap.  The change we introduced, namely making Raw.xres/yres equal to the current screen resolution, effectively caused the Scaled procedure to do nothing since (ScreenDPI / ImageDPI) = 1.The problem that brought all this on in the first place is that my GUI was looking bad on the 1920x1200 screen.  The reason I have discovered *now* is that FormsVBT apparently uses the #2 (scaled) version for pixmaps.  In the old code, the interface defaulted the developed resolution of the pixmaps to be 75 dpi.  At my 147+ dpi screen, the scaled implementation would effectively double the size of the pixmap when rendered on the screen in an effort to make the pixmap look the same size on the 147dpi screen that it appeared on a 75 dpi screen.All of this to say that the changes to Image.i3/m3 need to be undone in order to get back the original intent of the developers.Of course, once these changes are undone, my problem returns with the GUI looking bad on 1920x1200 at 147+ dpi.  So, how to solve it properly now requires more thought.I need to do some more reading of the code I guess to see if there is a way already to cause FormsVBT to use unscaled for all pixmaps.  Otherwise, a quick fix would be to add a new procedure to the interface that would force use of the unscaled implementation.Now, back to the problem of not being able to drag the subwindows, I'm still puzzled.  To test my "understanding" as related above, I went back to the original Image.i3/m3, but this time changed the Scaled procedure to effectively do the same thing as Unscaled.  The pixmaps render fine on the 1920x1200 monitor, but the subwindows still can't be dragged.  If I back out my change to Scaled (effectively, revert to the original Image.m3), the subwindows drag with ease on the 1920x1200 monitor, but of course the pixmaps look bad.  I can't explain this behavior yet.  Any ideas?Regards,Randy>>> Jay  8/11/2008 2:41 PM>>>MemoryBarrier ensures that all the reads and writes before it finish before any reads and writes after it.Look at winnt.h or MSDN, as well the comment I put in explains it.It probably has no effect, since our compiler is not aggressive.What is confusing in these cases is the compiler and processor both need to be informed.There is a concurrency issue and the barrier should make extra certain to solve it.Multiple monitors are not considered.Do you have them?Randy, please experiment.Change the code to return hard coded numbers -- like the old 75.   Either without the globals, or initialize the globals.And then add in the the various calls one at a time, ignoring their return values.Furthermore, I guess you could just say:    IF xres = 0 THEN Init() END;and    IF yres = 0 THEN Init() END;and maybe change the globals to INTEGER.Though REAL should be 32 bits and be written atomatically.The idea is, even if the code does run multiple times concurrently, it should always return the same information.Anyway, like I said, try various or every combination between the two and findout which part triggers the difference, then we can think more about just that.I might be able to get an expert friend to give me some help, later.- Jay________________________________Date: Mon, 11 Aug 2008 12:15:40 -0400From: rcoleburn at scires.comTo: jay.krell at cornell.eduCC: wagner at elegosoft.comSubject: RE: strange problem w/new Image/ImageInitJay:I tested your change, but it has no effect on the problem I am having.  I also tried having the accessor functions just return a hardcoded number, but again, no effect on the problem.  This is real strange to me, because if I remove ImageInit and revert Image.i3/m3 back to the way it was before, the problem disappears.Questions,1.  What does the WinNT.MemoryBarrier() call do?2.  What would happen if this code was run by multiple threads?  Are there any concurrency issues that need to be guarded?3.  What would happen in the case of multiple monitors at different resolutions?Regards,Randy>>> Jay  8/11/2008 6:46 AM>>>Also try the change I just commited with ReleaseDC.- Jay> From: jayk123 at hotmail.com> To: rcoleburn at scires.com> CC: wagner at elegosoft.com> Subject: RE: strange problem w/new Image/ImageInit> Date: Mon, 11 Aug 2008 07:51:52 +0000>>> Randy, this makes no sense to me.> What happens if you just hardcode the numbers instead of computing them?>>> - Jay>>>>>>> ________________________________>>>> Date: Mon, 11 Aug 2008 02:55:56 -0400> From: rcoleburn at scires.com> To: jayk123 at hotmail.com> CC: Olaf Wagner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080812/41806d4a/attachment.html>

From rcoleburn at scires.com  Wed Aug 13 03:04:58 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Tue, 12 Aug 2008 21:04:58 -0400
Subject: [M3devel] strange problem w/new Image/ImageInit
In-Reply-To: <COL101-W7934CC09223B996946776EE6700@phx.gbl>
References: <489FAA38.1E75.00D7.1@scires.com>
	<COL101-W158F68823847D036260F0FE6710@phx.gbl>
	<48A02D67.1E75.00D7.1@scires.com>
	<COL101-W13606B4823978F6670D3C9E6710@phx.gbl>
	<48A05960.1E75.00D7.1@scires.com>
	<COL101-W65ECE9C2B48E275288EAF0E6710@phx.gbl>
	<48A110A3.1E75.00D7.1@scires.com>
	<COL101-W48D58C2FBDE5BCD3163650E6700@phx.gbl>
	<48A17936.1E75.00D7.1@scires.com>
	<COL101-W7934CC09223B996946776EE6700@phx.gbl>
Message-ID: <48A1FAF3.1E75.00D7.1@scires.com>

Jay:
 
So, let me make sure I understand what you are suggesting.
1.  Change WinScreenType to use LOGPIXELS and therefore it will yield 96 dpi.
2.  Test with Image.Raw.res at 75.0, if it doesn't work out, try changing to 96.0.
 
I'll try the above and let you know how it fares.  Or, if I've misunderstood, please correct me.
 
I find it interesting that if you leave Image.Raw.res at 75.0 and use scaled pixmaps, the ZChassisVBT's ZMoveVBT works as expected regardless of what dpi setting Windows reports to Trestle, but if you switch to unscaled pixmaps or if you change the Image.Raw.res to 86 or 147 the ZMoveVBT stops working on the 1920x1200 system yet it continues to work on all other systems I've tested.
 
Regards,
Randy

>>> Jay <jay.krell at cornell.edu> 8/12/2008 3:58 PM >>>
Twice I've lost my message here, darnit.
LOGPIXELSX (look it up on MSDN/Google/LiveSearch) is pixels per inch on the x axis. It is stuck at 96 for compatibility. And the docs say it has just one value in a multimon situation.
So you can ask Windows for pixels per inch and get 96.
Or you can ask for pixels and millimeters and do the division and get the truth.
Or you can tell it you are "high dpi aware" on Vista and get the truth either way.
I understand the attempt to do the right thing, but it clearly doesn't work out -- the rest of the gui doesn't scale/move correctly with it.
What makes sense and is ideal is often at odds with the bulk of existing code. The bulk of existing code wins, and sometimes nobody can do the right thing in contradiction do it.
 
 - Jay



Date: Tue, 12 Aug 2008 11:51:25 -0400
From: rcoleburn at scires.com 
To: jay.krell at cornell.edu 
CC: m3devel at elegosoft.com 
Subject: Re: [M3devel] strange problem w/new Image/ImageInit


Jay:
 
Thanks for your insights here.  I'll try some more tests and see what I come up with.  I've attached my current Image.i3/Image.m3 and Win32/ScrollerVBTClass.m3 for your reference.  I've removed use of ImageInit from all of these.  And yes, I have reverted to the 75.0 hardcoded value.
 
Based on my limited understanding of the code, I still think I will get scaled behavior even if Modula-3 thinks the dpi is 96, because 147 / 96 =  1.53125, which rounds to 2.  So my pixmaps will still appear double-size.
 
In actuality, I think Modula-3 is trying to do the right thing with the scaling.  At some point on a high-enough dpi monitor, the pixmaps will be so tiny that you can't really see them if they are unscaled.  I've already observed this with some of my boolean and choice indicators--I had to reduce the shadowsize in order to tell whether the boolean/choice was TRUE or FALSE.  From the way Trestle/FormsVBT are set up, it appears that the designers wanted to get approximately the same size rendering on different dpi screens.  That's why you see millimeters everywhere in the code being converted to pixels.  Indeed, VBT has a procedure MMToPixels that is dependent on getting the screen type of the underlying VBT.T so it can get the ppm setting for this screen and do the computation.  Provided that the underlying implementation gives correct ppm info to Modula-3 for each screen, the current Trestle/FormsVBT should do the right thing even in multiple monitor situations.  I haven't tested this, but I should be able to drag a window from a monitor at one dpi onto a monitor at a different dpi and have everything scale to look correct on the new monitor.
 
The problem in my case with the 1920x1200 monitor is that the scaled pixmaps look huge in proportion to the text and other features of the window.  Maybe this other stuff isn't being scaled the same way pixmaps are scaled.
 
Does LOGPIXELSX stand for Logical Pixels X-Axis ?  I know that Windows has a dpi setting for fonts.  If set to normal, fonts are supposed to render at 96 dpi, but you can switch to large mode and have them rendered at 120 dpi, or you can make up a custom number.  This Windows setting applies only to fonts, not graphical elements.
 
You say that Modula-3 is computing LOGPIXELS via a "seemingly redundant equivalent way."  In my reading of the code in WinScreenType, it appears that Modula-3 is requesting from Windows the actual number of pixels in both axes and also the number of millimeters in both axes.  It uses these to compute the resolution in pixels per millimeter (ppm).  The ppm is what is stored and used internally when scaling pixmaps.  When necessary, ppm is converted to dpi using the formula (dpi = ppm x 25.4).
 
On my 4:3 aspect ratio IBM T60 at 1280x1024, the ppm is 3.41333 in both axes yielding a dpi of 86.698667.
 
On the widescreen (16:10 aspect ratio) Dell 4300 at 1920x1200 the ppm is slightly different in each axis, but is close to 5.8xxx yielding at dpi of 147.xxx  (again, the fractional part is different in each axis).
 
I don't mind running a test program for you on the hi-res system here--just send it to me via email.  I have the VC++ 2008 redistributables installed.
 
I think you are on the west coast and I'm on the east coast, so we have a time difference of 3 hours, but lately I've been working round the clock seemingly, so I'll try to respond with test results as soon as I can.
 
Regards,
Randy

>>> Jay <jay.krell at cornell.edu> 8/12/2008 6:49 AM >>>

Randy I don't think you need to add a way to use the unscaled data.
I think the fix is
a) go back to Image hardcoding 75
b) Have WinScreenType hardcode 96 or use GetDeviceCaps(LOGPIXELSX Y) -- same thing really.
And then see what happens.

Basically, the scale of pixmaps and the scale of screens has always been close to 1:1.
75:96, close enough.
Therefore, unscaled has been the norm.

Most GUI code uses GetDeviceCaps(LOGPIXELSX Y) I believe.
However, most code is not prepared to get back anything other than 96 from it.

Modula-3, at least for the pixmap code, was computing LOGPIXELSX and Y via a seemingly redundant equivalent way.
However, my believe is that LOGPIXELSX and Y is forced to lie, but the other route is not.
It seems an arbitrary discprecancy, but not beyond imagination.

By switching to the lying method, we will get back the nearly unscaled 75:96 behavior.

Vista adds a way for an application to declare that it is "high dpi aware", which then makes GetDeviceCaps(LOGPIXELX and Y) report the truth presumably. You can see, by the very existance of this ability to declare that you are high dpi aware -- to declare that your code is merely correct -- that most code is not correct.

What remains to be determined is why Modula-3 pixmaps behave "differently" than Modula-3 buttons, text, etc.

I also think there is a likely disconnect between painting and hit testing, but this is gross speculation.
I should fiddle with the numbers myself.

I will go ahead with a+b fairly soon.
I will verify the numbers computed in #b before and after.
I don't have any high dpi systems, so I expect the numbers to be roughly the same either way.
I think the only systems that will see a change are high dpi, and they will see an improvement.

Sorry for the back and forth regarding ImageInit -- a medium size change is going to be completely undone.

- Jay

________________________________

Date: Tue, 12 Aug 2008 04:25:11 -0400
From: rcoleburn at scires.com 
To: jay.krell at cornell.edu 
CC: m3devel at elegosoft.com 
Subject: Re: [M3devel] strange problem w/new Image/ImageInit



Jay:



For LOGPIXELS X & Y, I get 96 on the hi-res Dell M4300 system and also on my ThinkPad T60.



I've put together revised versions of Image.i3/m3 and my ScrollerVBTClass.m3.  The good news is that I've managed to get the scroll bar to look correct in both scaled and unscaled modes.



I've added a new procedure to Image.i3/m3 that will force subsequent calls to Scaled() to behave like Unscaled().  Using this, I can get the appearance I need on the hi-res monitor without resorting to changes in the original intent of the Image interface.  The advantage of this procedure is that it does not change the Image interface (except for addition of the procedure) and it therefore won't have any affect on pickles or anyone else's code.  Plus, it lets the programmer override use of Scaled() in all library modules without having to modify any source code.



Before I commit any of these changes, I want to do some more testing and to fix the problem with subwindows (ZChassisVBT) not being able to move.



Alas, my problem of the ZChassisVBTs not being able to move on the hi-res monitor persists with these changes, even though I left the xres/yres at 75.  Of course, these numbers are ignored for Unscaled images anyway.



I'm at a loss to explain this behavior.  Here is what I know based on testing:

1.  Using Scaled images and Image.Raw.xres/yres = 75.0, ZChassisVBT movement works on the hi-res monitor.

2.  Using Scaled images and Image.Raw.xres/yres set to 86.xxx or to 147.xxx, ZChassisVBT movement does not work on the hi-res 147.xxx dpi monitor, but it still works on my 86.xxx dpi monitor

3.  Using Unscaled images, ZChassisVBT movement does not work on the hi-res 147.xxx dpi monitor, but it still works on my 86.xxx dpi monitor



So, there seems to be something in the implementation somewhere of ZChassisVBT, or maybe ZMoveVBT, that doesn't like 147.xxx dpi monitors unless you scale all images assuming they were designed at 75 dpi.  At the 147 dpi, the 75 dpi pixmaps will be scaled by a factor of 2, which corresponds to what I am seeing on the screen.



I'm too sleepy to make any more progress for now.  If anyone has an idea on what to do next, please let me know.  I'm stumped at this point.



Regards,

Randy

>>> Jay  8/11/2008 3:52 PM>>>

Hm. Ok then, where does it get the screen resolution from?

Probably here?

WinScreenType.m3:

PROCEDURE InnerNew ((* IN-OUT *) res: T) =
  BEGIN
    WITH pix_hor = WinUser.GetSystemMetrics(WinUser.SM_CXSCREEN),
         pix_ver = WinUser.GetSystemMetrics(WinUser.SM_CYSCREEN),
         mm_hor  = GetDeviceCaps (WinGDI.HORZSIZE),
         mm_ver  = GetDeviceCaps (WinGDI.VERTSIZE) DO
      res.rootDom := Rect.FromSize(pix_hor, pix_ver);
      res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
      res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);

ok.

Perhaps we should accept the numbers that Windows makes up instead?

GetDeviceCaps(LOGPIXELSX)
and GetDeviceCaps(LOGPIXELSY)

Please try that, in the WinScreenType.m3 code.
With removing ImageInit (or just have it hardcoded at 75).

This will most likely be 96 even on your high dpi system, unless you are on Vista
and tell the system you are high dpi aware.

I think there is disagreement in drawing vs. hit test as to where you are clicking.
Try making ImageInit always 75.
Try making the above convert from a hardcoded 96.
And then try GetDeviceCaps(LOGPIXELSX and Y) -- which I expect always returns 96 for you.
You can plug that into my dpi.c to see what it prints.

I think part of what is happening is that Modula-3 was very rare in doing the right thing for high dpi
monitors. But so much code is wrong that Windows has to counteract the wrongness,
which means Modula-3 needs to go along and do things wrong in order for the counteraction
to leave it doing the right thing also.
I'm not sure.
Oh, and presumably other places in Modula-3 are wrong, and the counteraction works for them.
That's a bit of a mystery -- drawing of pixmaps vs. drawing of everything else.

- Jay


________________________________

Date: Mon, 11 Aug 2008 15:23:17 -0400
From: rcoleburn at scires.com 
To: jay.krell at cornell.edu 
CC: m3devel at elegosoft.com; wagner at elegosoft.com 
Subject: RE: strange problem w/new Image/ImageInit



Jay:



I have been experimenting quite a bit and I've come up with some "new old" information.



I say "new old" because, after spending the time to read some of the comments in the original code (before we modified it), I think I now have a better idea of what the designers intended and why I had/have a problem.



If you read carefully, the xres/yres fields in Image.Raw are supposed to represent the resolution at which the pixmap was originally DEVELOPED, not the resolution of the current screen.  It seems the designers went to great lengths to represent everything as screen-independent until it is actually rendered.



The Image interface gives 3 ways of dealing with pixmaps:  (1) unscaled, (2) scaled, and (3) scaled to "most appropriate".  The change you and I conspired actually changes this behavior to make #2 (scaled) work as #1 (unscaled).  (It probably also changes #3.)  This is the behavior I want for my current program, but it changes the intent of the original interface, so I'm afraid we are going to have to revert all those changes.



Digging deeper into Image.m3, I've discovered that it is smart-enough already to deduce the screen resolution.  If you look into the ApplyScaled1 procedure, you see that it converts the current screen resolution in millimeters to pixels in order to scale the pixmap.  The change we introduced, namely making Raw.xres/yres equal to the current screen resolution, effectively caused the Scaled procedure to do nothing since (ScreenDPI / ImageDPI) = 1.



The problem that brought all this on in the first place is that my GUI was looking bad on the 1920x1200 screen.  The reason I have discovered *now* is that FormsVBT apparently uses the #2 (scaled) version for pixmaps.  In the old code, the interface defaulted the developed resolution of the pixmaps to be 75 dpi.  At my 147+ dpi screen, the scaled implementation would effectively double the size of the pixmap when rendered on the screen in an effort to make the pixmap look the same size on the 147dpi screen that it appeared on a 75 dpi screen.



All of this to say that the changes to Image.i3/m3 need to be undone in order to get back the original intent of the developers.



Of course, once these changes are undone, my problem returns with the GUI looking bad on 1920x1200 at 147+ dpi.  So, how to solve it properly now requires more thought.



I need to do some more reading of the code I guess to see if there is a way already to cause FormsVBT to use unscaled for all pixmaps.  Otherwise, a quick fix would be to add a new procedure to the interface that would force use of the unscaled implementation.



Now, back to the problem of not being able to drag the subwindows, I'm still puzzled.  To test my "understanding" as related above, I went back to the original Image.i3/m3, but this time changed the Scaled procedure to effectively do the same thing as Unscaled.  The pixmaps render fine on the 1920x1200 monitor, but the subwindows still can't be dragged.  If I back out my change to Scaled (effectively, revert to the original Image.m3), the subwindows drag with ease on the 1920x1200 monitor, but of course the pixmaps look bad.  I can't explain this behavior yet.  Any ideas?



Regards,

Randy

>>> Jay  8/11/2008 2:41 PM>>>

MemoryBarrier ensures that all the reads and writes before it finish before any reads and writes after it.
Look at winnt.h or MSDN, as well the comment I put in explains it.
It probably has no effect, since our compiler is not aggressive.
What is confusing in these cases is the compiler and processor both need to be informed.
There is a concurrency issue and the barrier should make extra certain to solve it.

Multiple monitors are not considered.
Do you have them?

Randy, please experiment.
Change the code to return hard coded numbers -- like the old 75.
   Either without the globals, or initialize the globals.
And then add in the the various calls one at a time, ignoring their return values.

Furthermore, I guess you could just say:

    IF xres = 0 THEN Init() END;

and

    IF yres = 0 THEN Init() END;

and maybe change the globals to INTEGER.
Though REAL should be 32 bits and be written atomatically.

The idea is, even if the code does run multiple times concurrently, it should always return the same information.

Anyway, like I said, try various or every combination between the two and find
out which part triggers the difference, then we can think more about just that.

I might be able to get an expert friend to give me some help, later.

- Jay


________________________________

Date: Mon, 11 Aug 2008 12:15:40 -0400
From: rcoleburn at scires.com 
To: jay.krell at cornell.edu 
CC: wagner at elegosoft.com 
Subject: RE: strange problem w/new Image/ImageInit



Jay:



I tested your change, but it has no effect on the problem I am having.  I also tried having the accessor functions just return a hardcoded number, but again, no effect on the problem.  This is real strange to me, because if I remove ImageInit and revert Image.i3/m3 back to the way it was before, the problem disappears.



Questions,

1.  What does the WinNT.MemoryBarrier() call do?

2.  What would happen if this code was run by multiple threads?  Are there any concurrency issues that need to be guarded?

3.  What would happen in the case of multiple monitors at different resolutions?



Regards,

Randy

>>> Jay  8/11/2008 6:46 AM>>>

Also try the change I just commited with ReleaseDC.

- Jay


> From: jayk123 at hotmail.com 
> To: rcoleburn at scires.com 
> CC: wagner at elegosoft.com 
> Subject: RE: strange problem w/new Image/ImageInit
> Date: Mon, 11 Aug 2008 07:51:52 +0000
>
>
> Randy, this makes no sense to me.
> What happens if you just hardcode the numbers instead of computing them?
>
>
> - Jay
>
>
>
>
>
>
> ________________________________
>
>
>
> Date: Mon, 11 Aug 2008 02:55:56 -0400
> From: rcoleburn at scires.com 
> To: jayk123 at hotmail.com 
> CC: Olaf Wagner




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080812/feddefb6/attachment.html>

From jay.krell at cornell.edu  Wed Aug 13 05:17:22 2008
From: jay.krell at cornell.edu (Jay)
Date: Wed, 13 Aug 2008 03:17:22 +0000
Subject: [M3devel] strange problem w/new Image/ImageInit
In-Reply-To: <48A1FAF3.1E75.00D7.1@scires.com>
References: <489FAA38.1E75.00D7.1@scires.com>
	<COL101-W158F68823847D036260F0FE6710@phx.gbl>
	<48A02D67.1E75.00D7.1@scires.com>
	<COL101-W13606B4823978F6670D3C9E6710@phx.gbl>
	<48A05960.1E75.00D7.1@scires.com>
	<COL101-W65ECE9C2B48E275288EAF0E6710@phx.gbl>
	<48A110A3.1E75.00D7.1@scires.com>
	<COL101-W48D58C2FBDE5BCD3163650E6700@phx.gbl>
	<48A17936.1E75.00D7.1@scires.com>
	<COL101-W7934CC09223B996946776EE6700@phx.gbl> 
	<48A1FAF3.1E75.00D7.1@scires.com>
Message-ID: <COL101-W56F9FEE075B5A2C956F192E6730@phx.gbl>


1 and 2 correct. I expect 75 will do for #2.#1 you can verify and not just run blind. Print it, or use the C code, or maybe you already did.
The ratio of these numbers is the "problem". You asked for "unscaled", I suggest 75/96 or 96/75, close to unscalled, and should be about the same as it has been doing on most machines all along -- most machines having close to 96 actual dpi. (We should probably do a quick survey of that.)
 
Is there a way to fiddle with the numbers that breaks movement on all machines?I should try and look for that.
 
 - Jay



Date: Tue, 12 Aug 2008 21:04:58 -0400From: rcoleburn at scires.comTo: jay.krell at cornell.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] strange problem w/new Image/ImageInit



Jay:
 
So, let me make sure I understand what you are suggesting.
1.  Change WinScreenType to use LOGPIXELS and therefore it will yield 96 dpi.
2.  Test with Image.Raw.res at 75.0, if it doesn't work out, try changing to 96.0.
 
I'll try the above and let you know how it fares.  Or, if I've misunderstood, please correct me.
 
I find it interesting that if you leave Image.Raw.res at 75.0 and use scaled pixmaps, the ZChassisVBT's ZMoveVBT works as expected regardless of what dpi setting Windows reports to Trestle, but if you switch to unscaled pixmaps or if you change the Image.Raw.res to 86 or 147 the ZMoveVBT stops working on the 1920x1200 system yet it continues to work on all other systems I've tested.
 
Regards,
Randy>>> Jay <jay.krell at cornell.edu> 8/12/2008 3:58 PM >>>Twice I've lost my message here, darnit.LOGPIXELSX (look it up on MSDN/Google/LiveSearch) is pixels per inch on the x axis. It is stuck at 96 for compatibility. And the docs say it has just one value in a multimon situation.So you can ask Windows for pixels per inch and get 96.Or you can ask for pixels and millimeters and do the division and get the truth.Or you can tell it you are "high dpi aware" on Vista and get the truth either way.I understand the attempt to do the right thing, but it clearly doesn't work out -- the rest of the gui doesn't scale/move correctly with it.What makes sense and is ideal is often at odds with the bulk of existing code. The bulk of existing code wins, and sometimes nobody can do the right thing in contradiction do it.  - Jay



Date: Tue, 12 Aug 2008 11:51:25 -0400From: rcoleburn at scires.comTo: jay.krell at cornell.eduCC: m3devel at elegosoft.comSubject: Re: [M3devel] strange problem w/new Image/ImageInit
Jay:
 
Thanks for your insights here.  I'll try some more tests and see what I come up with.  I've attached my current Image.i3/Image.m3 and Win32/ScrollerVBTClass.m3 for your reference.  I've removed use of ImageInit from all of these.  And yes, I have reverted to the 75.0 hardcoded value.
 
Based on my limited understanding of the code, I still think I will get scaled behavior even if Modula-3 thinks the dpi is 96, because 147 / 96 =  1.53125, which rounds to 2.  So my pixmaps will still appear double-size.
 
In actuality, I think Modula-3 is trying to do the right thing with the scaling.  At some point on a high-enough dpi monitor, the pixmaps will be so tiny that you can't really see them if they are unscaled.  I've already observed this with some of my boolean and choice indicators--I had to reduce the shadowsize in order to tell whether the boolean/choice was TRUE or FALSE.  From the way Trestle/FormsVBT are set up, it appears that the designers wanted to get approximately the same size rendering on different dpi screens.  That's why you see millimeters everywhere in the code being converted to pixels.  Indeed, VBT has a procedure MMToPixels that is dependent on getting the screen type of the underlying VBT.T so it can get the ppm setting for this screen and do the computation.  Provided that the underlying implementation gives correct ppm info to Modula-3 for each screen, the current Trestle/FormsVBT should do the right thing even in multiple monitor situations.  I haven't tested this, but I should be able to drag a window from a monitor at one dpi onto a monitor at a different dpi and have everything scale to look correct on the new monitor.
 
The problem in my case with the 1920x1200 monitor is that the scaled pixmaps look huge in proportion to the text and other features of the window.  Maybe this other stuff isn't being scaled the same way pixmaps are scaled.
 
Does LOGPIXELSX stand for Logical Pixels X-Axis ?  I know that Windows has a dpi setting for fonts.  If set to normal, fonts are supposed to render at 96 dpi, but you can switch to large mode and have them rendered at 120 dpi, or you can make up a custom number.  This Windows setting applies only to fonts, not graphical elements.
 
You say that Modula-3 is computing LOGPIXELS via a "seemingly redundant equivalent way."  In my reading of the code in WinScreenType, it appears that Modula-3 is requesting from Windows the actual number of pixels in both axes and also the number of millimeters in both axes.  It uses these to compute the resolution in pixels per millimeter (ppm).  The ppm is what is stored and used internally when scaling pixmaps.  When necessary, ppm is converted to dpi using the formula (dpi = ppm x 25.4).
 
On my 4:3 aspect ratio IBM T60 at 1280x1024, the ppm is 3.41333 in both axes yielding a dpi of 86.698667.
 
On the widescreen (16:10 aspect ratio) Dell 4300 at 1920x1200 the ppm is slightly different in each axis, but is close to 5.8xxx yielding at dpi of 147.xxx  (again, the fractional part is different in each axis).
 
I don't mind running a test program for you on the hi-res system here--just send it to me via email.  I have the VC++ 2008 redistributables installed.
 
I think you are on the west coast and I'm on the east coast, so we have a time difference of 3 hours, but lately I've been working round the clock seemingly, so I'll try to respond with test results as soon as I can.
 
Regards,
Randy>>> Jay <jay.krell at cornell.edu> 8/12/2008 6:49 AM >>>Randy I don't think you need to add a way to use the unscaled data.I think the fix isa) go back to Image hardcoding 75b) Have WinScreenType hardcode 96 or use GetDeviceCaps(LOGPIXELSX Y) -- same thing really.And then see what happens.Basically, the scale of pixmaps and the scale of screens has always been close to 1:1.75:96, close enough.Therefore, unscaled has been the norm.Most GUI code uses GetDeviceCaps(LOGPIXELSX Y) I believe.However, most code is not prepared to get back anything other than 96 from it.Modula-3, at least for the pixmap code, was computing LOGPIXELSX and Y via a seemingly redundant equivalent way.However, my believe is that LOGPIXELSX and Y is forced to lie, but the other route is not.It seems an arbitrary discprecancy, but not beyond imagination.By switching to the lying method, we will get back the nearly unscaled 75:96 behavior.Vista adds a way for an application to declare that it is "high dpi aware", which then makes GetDeviceCaps(LOGPIXELX and Y) report the truth presumably. You can see, by the very existance of this ability to declare that you are high dpi aware -- to declare that your code is merely correct -- that most code is not correct.What remains to be determined is why Modula-3 pixmaps behave "differently" than Modula-3 buttons, text, etc.I also think there is a likely disconnect between painting and hit testing, but this is gross speculation.I should fiddle with the numbers myself.I will go ahead with a+b fairly soon.I will verify the numbers computed in #b before and after.I don't have any high dpi systems, so I expect the numbers to be roughly the same either way.I think the only systems that will see a change are high dpi, and they will see an improvement.Sorry for the back and forth regarding ImageInit -- a medium size change is going to be completely undone.- Jay________________________________Date: Tue, 12 Aug 2008 04:25:11 -0400From: rcoleburn at scires.comTo: jay.krell at cornell.eduCC: m3devel at elegosoft.comSubject: Re: [M3devel] strange problem w/new Image/ImageInitJay:For LOGPIXELS X & Y, I get 96 on the hi-res Dell M4300 system and also on my ThinkPad T60.I've put together revised versions of Image.i3/m3 and my ScrollerVBTClass.m3.  The good news is that I've managed to get the scroll bar to look correct in both scaled and unscaled modes.I've added a new procedure to Image.i3/m3 that will force subsequent calls to Scaled() to behave like Unscaled().  Using this, I can get the appearance I need on the hi-res monitor without resorting to changes in the original intent of the Image interface.  The advantage of this procedure is that it does not change the Image interface (except for addition of the procedure) and it therefore won't have any affect on pickles or anyone else's code.  Plus, it lets the programmer override use of Scaled() in all library modules without having to modify any source code.Before I commit any of these changes, I want to do some more testing and to fix the problem with subwindows (ZChassisVBT) not being able to move.Alas, my problem of the ZChassisVBTs not being able to move on the hi-res monitor persists with these changes, even though I left the xres/yres at 75.  Of course, these numbers are ignored for Unscaled images anyway.I'm at a loss to explain this behavior.  Here is what I know based on testing:1.  Using Scaled images and Image.Raw.xres/yres = 75.0, ZChassisVBT movement works on the hi-res monitor.2.  Using Scaled images and Image.Raw.xres/yres set to 86.xxx or to 147.xxx, ZChassisVBT movement does not work on the hi-res 147.xxx dpi monitor, but it still works on my 86.xxx dpi monitor3.  Using Unscaled images, ZChassisVBT movement does not work on the hi-res 147.xxx dpi monitor, but it still works on my 86.xxx dpi monitorSo, there seems to be something in the implementation somewhere of ZChassisVBT, or maybe ZMoveVBT, that doesn't like 147.xxx dpi monitors unless you scale all images assuming they were designed at 75 dpi.  At the 147 dpi, the 75 dpi pixmaps will be scaled by a factor of 2, which corresponds to what I am seeing on the screen.I'm too sleepy to make any more progress for now.  If anyone has an idea on what to do next, please let me know.  I'm stumped at this point.Regards,Randy>>> Jay  8/11/2008 3:52 PM>>>Hm. Ok then, where does it get the screen resolution from?Probably here?WinScreenType.m3:PROCEDURE InnerNew ((* IN-OUT *) res: T) =  BEGIN    WITH pix_hor = WinUser.GetSystemMetrics(WinUser.SM_CXSCREEN),         pix_ver = WinUser.GetSystemMetrics(WinUser.SM_CYSCREEN),         mm_hor  = GetDeviceCaps (WinGDI.HORZSIZE),         mm_ver  = GetDeviceCaps (WinGDI.VERTSIZE) DO      res.rootDom := Rect.FromSize(pix_hor, pix_ver);      res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);      res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);ok.Perhaps we should accept the numbers that Windows makes up instead?GetDeviceCaps(LOGPIXELSX)and GetDeviceCaps(LOGPIXELSY)Please try that, in the WinScreenType.m3 code.With removing ImageInit (or just have it hardcoded at 75).This will most likely be 96 even on your high dpi system, unless you are on Vistaand tell the system you are high dpi aware.I think there is disagreement in drawing vs. hit test as to where you are clicking.Try making ImageInit always 75.Try making the above convert from a hardcoded 96.And then try GetDeviceCaps(LOGPIXELSX and Y) -- which I expect always returns 96 for you.You can plug that into my dpi.c to see what it prints.I think part of what is happening is that Modula-3 was very rare in doing the right thing for high dpimonitors. But so much code is wrong that Windows has to counteract the wrongness,which means Modula-3 needs to go along and do things wrong in order for the counteractionto leave it doing the right thing also.I'm not sure.Oh, and presumably other places in Modula-3 are wrong, and the counteraction works for them.That's a bit of a mystery -- drawing of pixmaps vs. drawing of everything else.- Jay________________________________Date: Mon, 11 Aug 2008 15:23:17 -0400From: rcoleburn at scires.comTo: jay.krell at cornell.eduCC: m3devel at elegosoft.com; wagner at elegosoft.comSubject: RE: strange problem w/new Image/ImageInitJay:I have been experimenting quite a bit and I've come up with some "new old" information.I say "new old" because, after spending the time to read some of the comments in the original code (before we modified it), I think I now have a better idea of what the designers intended and why I had/have a problem.If you read carefully, the xres/yres fields in Image.Raw are supposed to represent the resolution at which the pixmap was originally DEVELOPED, not the resolution of the current screen.  It seems the designers went to great lengths to represent everything as screen-independent until it is actually rendered.The Image interface gives 3 ways of dealing with pixmaps:  (1) unscaled, (2) scaled, and (3) scaled to "most appropriate".  The change you and I conspired actually changes this behavior to make #2 (scaled) work as #1 (unscaled).  (It probably also changes #3.)  This is the behavior I want for my current program, but it changes the intent of the original interface, so I'm afraid we are going to have to revert all those changes.Digging deeper into Image.m3, I've discovered that it is smart-enough already to deduce the screen resolution.  If you look into the ApplyScaled1 procedure, you see that it converts the current screen resolution in millimeters to pixels in order to scale the pixmap.  The change we introduced, namely making Raw.xres/yres equal to the current screen resolution, effectively caused the Scaled procedure to do nothing since (ScreenDPI / ImageDPI) = 1.The problem that brought all this on in the first place is that my GUI was looking bad on the 1920x1200 screen.  The reason I have discovered *now* is that FormsVBT apparently uses the #2 (scaled) version for pixmaps.  In the old code, the interface defaulted the developed resolution of the pixmaps to be 75 dpi.  At my 147+ dpi screen, the scaled implementation would effectively double the size of the pixmap when rendered on the screen in an effort to make the pixmap look the same size on the 147dpi screen that it appeared on a 75 dpi screen.All of this to say that the changes to Image.i3/m3 need to be undone in order to get back the original intent of the developers.Of course, once these changes are undone, my problem returns with the GUI looking bad on 1920x1200 at 147+ dpi.  So, how to solve it properly now requires more thought.I need to do some more reading of the code I guess to see if there is a way already to cause FormsVBT to use unscaled for all pixmaps.  Otherwise, a quick fix would be to add a new procedure to the interface that would force use of the unscaled implementation.Now, back to the problem of not being able to drag the subwindows, I'm still puzzled.  To test my "understanding" as related above, I went back to the original Image.i3/m3, but this time changed the Scaled procedure to effectively do the same thing as Unscaled.  The pixmaps render fine on the 1920x1200 monitor, but the subwindows still can't be dragged.  If I back out my change to Scaled (effectively, revert to the original Image.m3), the subwindows drag with ease on the 1920x1200 monitor, but of course the pixmaps look bad.  I can't explain this behavior yet.  Any ideas?Regards,Randy>>> Jay  8/11/2008 2:41 PM>>>MemoryBarrier ensures that all the reads and writes before it finish before any reads and writes after it.Look at winnt.h or MSDN, as well the comment I put in explains it.It probably has no effect, since our compiler is not aggressive.What is confusing in these cases is the compiler and processor both need to be informed.There is a concurrency issue and the barrier should make extra certain to solve it.Multiple monitors are not considered.Do you have them?Randy, please experiment.Change the code to return hard coded numbers -- like the old 75.   Either without the globals, or initialize the globals.And then add in the the various calls one at a time, ignoring their return values.Furthermore, I guess you could just say:    IF xres = 0 THEN Init() END;and    IF yres = 0 THEN Init() END;and maybe change the globals to INTEGER.Though REAL should be 32 bits and be written atomatically.The idea is, even if the code does run multiple times concurrently, it should always return the same information.Anyway, like I said, try various or every combination between the two and findout which part triggers the difference, then we can think more about just that.I might be able to get an expert friend to give me some help, later.- Jay________________________________Date: Mon, 11 Aug 2008 12:15:40 -0400From: rcoleburn at scires.comTo: jay.krell at cornell.eduCC: wagner at elegosoft.comSubject: RE: strange problem w/new Image/ImageInitJay:I tested your change, but it has no effect on the problem I am having.  I also tried having the accessor functions just return a hardcoded number, but again, no effect on the problem.  This is real strange to me, because if I remove ImageInit and revert Image.i3/m3 back to the way it was before, the problem disappears.Questions,1.  What does the WinNT.MemoryBarrier() call do?2.  What would happen if this code was run by multiple threads?  Are there any concurrency issues that need to be guarded?3.  What would happen in the case of multiple monitors at different resolutions?Regards,Randy>>> Jay  8/11/2008 6:46 AM>>>Also try the change I just commited with ReleaseDC.- Jay> From: jayk123 at hotmail.com> To: rcoleburn at scires.com> CC: wagner at elegosoft.com> Subject: RE: strange problem w/new Image/ImageInit> Date: Mon, 11 Aug 2008 07:51:52 +0000>>> Randy, this makes no sense to me.> What happens if you just hardcode the numbers instead of computing them?>>> - Jay>>>>>>> ________________________________>>>> Date: Mon, 11 Aug 2008 02:55:56 -0400> From: rcoleburn at scires.com> To: jayk123 at hotmail.com> CC: Olaf Wagner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080813/0d8a70e0/attachment.html>

From jay.krell at cornell.edu  Wed Aug 13 13:31:05 2008
From: jay.krell at cornell.edu (Jay)
Date: Wed, 13 Aug 2008 11:31:05 +0000
Subject: [M3devel] FW: [M3commit] CVS Update: cm3
In-Reply-To: <20080813111059.33D8010D4DFE@birch.elegosoft.com>
References: <20080813111059.33D8010D4DFE@birch.elegosoft.com>
Message-ID: <COL101-W464DEDAFAE6F8583491CF0E6730@phx.gbl>


Randy, sorry
1) I didn't realize the functions were in use.
2) I couldn't figure out what each number means. I did try varying them and seeing the affect.
I think maybe I need to learn the X Windows terms? I know in Mac/Windows the part you can drag is the "thumb".

I think I preserved your intent. Feel free to reinstate your intent.
I brought up formsedit and only could easily see a vertical scrollbar.
It doesn't look right to me, but I suspect it is.
If the layers of Trestle could be understand and plowed through, DrawFrameControl would be good.
I've misplaced my Nelson. I'll get another and see if I can understand this..
I'm also curious to see if Tk and Qt draw scrollbars themselves or not.
I'll probably check soon (or by end of month, will be gone next week, out of touch).

 - Jay




----------------------------------------
[big mess made by the ever non-working email systems..]
> Date: Wed, 13 Aug 2008 13:10:59 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT:	/usr/cvs
> Changes by:	jkrell at birch.	08/08/13 13:10:59
> 
> Modified files:
> 	cm3/m3-ui/vbtkit/src/lego/WIN32/: ScrollerVBTClass.m3 
> 
> Log message:
> 	fix it to compile, at least
> 	and eliminate common subexpressions
> 	will see if we can get Windows to draw much more of this
> 	using DrawFrameControl
> 


From martinbishop at bellsouth.net  Thu Aug 14 01:22:28 2008
From: martinbishop at bellsouth.net (Martin Bishop)
Date: Wed, 13 Aug 2008 18:22:28 -0500
Subject: [M3devel] CM3IDE
Message-ID: <48A36CB4.3050005@bellsouth.net>

I asked this on the mailing list, but I'll ask here too.

I compiled CM3, and all went well, but when I try to run "cm3ide" it
asks me for browser and editor to use, which I tell it, and then it just
hangs.

I tried going to http://localhost:3800, but it doesn't appear any
service is running (browser just gives an error)


From martinbishop at bellsouth.net  Thu Aug 14 01:57:42 2008
From: martinbishop at bellsouth.net (Martin Bishop)
Date: Wed, 13 Aug 2008 18:57:42 -0500
Subject: [M3devel] CM3IDE
In-Reply-To: <48A36CB4.3050005@bellsouth.net>
References: <48A36CB4.3050005@bellsouth.net>
Message-ID: <48A374F6.4090409@bellsouth.net>

Martin Bishop wrote:
> I asked this on the mailing list, but I'll ask here too.
> 
> I compiled CM3, and all went well, but when I try to run "cm3ide" it
> asks me for browser and editor to use, which I tell it, and then it just
> hangs.
> 
> I tried going to http://localhost:3800, but it doesn't appear any
> service is running (browser just gives an error)
> 

Of course I meant on the usenet group, as this IS the mailing list :P


From rcoleburn at scires.com  Thu Aug 14 05:30:23 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Wed, 13 Aug 2008 23:30:23 -0400
Subject: [M3devel] FW: [M3commit] CVS Update: cm3
Message-ID: <48A36E8F020000D7000461EC@SRCMAIL.scires.com>

Jay:

I have a "working" version of the Win32 version of the ScrollerVBTClass.m3.  I put "working" in quotes because some of the behavior is a bit awkward.  Actually, I've been working on an improved version, but wasn't ready to release it yet.

This Win32 version came from an effort where my company paid Critical Mass to make some modifications to Trestle/FormsVBT to make it appear more like Microsoft Windows.  Unfortunately, the CMass effort on the scroll bar didn't turn out as well as some of their other efforts.  

I've made some improvements in it recently, and I think the version I emailed to you contained some of those improvements.

One of the big issues is that the platform-independent interface for the scroll bar defines things very differently from Windows.  For example, you use the left button to scroll forward and the right button to scroll backward, and then there is the whole issue of scrolling in proportion to the distance from the thumb to the mouse click.  CMass tried to hack the POSIX form of the module to come up with something that worked under Windows, but it doesn't quite get it right.  One of the changes I made recently at least fixed the appearance of the scroll bar, especially when scaled pixmaps are in use.  My change forces the trough to occupy the same width/height of the arrow buttons.  I was working on other improvements when I got sidetracked with the resolution problem on the customer's Dell M4300 computer.

At this point, my most pressing issue is indeed how to make the ZMoveVBT/ZChassisVBT work properly for subwindow movement on the M4300 hi-res computer.  At this point, I can give the customer two versions of the software:  (1) everything "works", but the appearance is bad because pixmaps are doubled in size, or (2) everything looks great, but you can't move the subwindows around.  Both of these versions are unacceptable to the customer, so I've got to come up with a fix.  Once I've done that, I can resume my effort with the scroll bar.

Regards,
Randy

>>> Jay <jay.krell at cornell.edu> 08/13/08 7:31 AM >>>

Randy, sorry
1) I didn't realize the functions were in use.
2) I couldn't figure out what each number means. I did try varying them and seeing the affect.
I think maybe I need to learn the X Windows terms? I know in Mac/Windows the part you can drag is the "thumb".

I think I preserved your intent. Feel free to reinstate your intent.
I brought up formsedit and only could easily see a vertical scrollbar.
It doesn't look right to me, but I suspect it is.
If the layers of Trestle could be understand and plowed through, DrawFrameControl would be good.
I've misplaced my Nelson. I'll get another and see if I can understand this..
I'm also curious to see if Tk and Qt draw scrollbars themselves or not.
I'll probably check soon (or by end of month, will be gone next week, out of touch).

 - Jay




----------------------------------------
[big mess made by the ever non-working email systems..]
> Date: Wed, 13 Aug 2008 13:10:59 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT:	/usr/cvs
> Changes by:	jkrell at birch.	08/08/13 13:10:59
> 
> Modified files:
> 	cm3/m3-ui/vbtkit/src/lego/WIN32/: ScrollerVBTClass.m3 
> 
> Log message:
> 	fix it to compile, at least
> 	and eliminate common subexpressions
> 	will see if we can get Windows to draw much more of this
> 	using DrawFrameControl
> 




From rcoleburn at scires.com  Thu Aug 14 05:38:59 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Wed, 13 Aug 2008 23:38:59 -0400
Subject: [M3devel] FW: [M3commit] CVS Update: cm3
Message-ID: <48A37093020000D7000461F1@SRCMAIL.scires.com>

Jay:

After reading your message again, it seems that you may not have received the versions of Image.i3/m3 and ScrollerVBTClass that I sent you.  I had already done the work to remove ImageInit from ScrollerVBTClass and Image.  I just didn't commit it to the repository because everything is still in a state of flux.  The versions I sent also included my new procedure for forcing use of Unscaled pixmaps.

If you like, I can resend these, or commit the versions I have to the repository.  The latter would at least put things right for anyone else using the software right now while we work on a better solution.  Let me know.

BTW, I wasn't able to work on any Modula-3 today because I had to travel for business.  Unfortunately, I'm going to lose a bit more time in the next couple of days because of a tragic death (auto accident) in my extended family.

I'm due at the customer facility on Monday morning, so unfortunately I'm also quickly running out of time for a solution.

Regards,
Randy

Randy C. Coleburn
Senior Systems Engineer, Communications, Networks, & Electronics Division (CNE)
Corporate & Atlanta Information Systems Security Manager (ISSM)
Scientific Research Corporation
2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339
voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) 989-9497

Quality Policy:  "SRC CNE Division is committed to delivering continually improving research & engineering excellence that meets or exceeds customer requirements."
>>> Jay <jay.krell at cornell.edu> 08/13/08 7:31 AM >>>

Randy, sorry
1) I didn't realize the functions were in use.
2) I couldn't figure out what each number means. I did try varying them and seeing the affect.
I think maybe I need to learn the X Windows terms? I know in Mac/Windows the part you can drag is the "thumb".

I think I preserved your intent. Feel free to reinstate your intent.
I brought up formsedit and only could easily see a vertical scrollbar.
It doesn't look right to me, but I suspect it is.
If the layers of Trestle could be understand and plowed through, DrawFrameControl would be good.
I've misplaced my Nelson. I'll get another and see if I can understand this..
I'm also curious to see if Tk and Qt draw scrollbars themselves or not.
I'll probably check soon (or by end of month, will be gone next week, out of touch).

 - Jay




----------------------------------------
[big mess made by the ever non-working email systems..]
> Date: Wed, 13 Aug 2008 13:10:59 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT:	/usr/cvs
> Changes by:	jkrell at birch.	08/08/13 13:10:59
> 
> Modified files:
> 	cm3/m3-ui/vbtkit/src/lego/WIN32/: ScrollerVBTClass.m3 
> 
> Log message:
> 	fix it to compile, at least
> 	and eliminate common subexpressions
> 	will see if we can get Windows to draw much more of this
> 	using DrawFrameControl
> 




From rcoleburn at scires.com  Thu Aug 14 05:57:32 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Wed, 13 Aug 2008 23:57:32 -0400
Subject: [M3devel] CM3IDE
Message-ID: <48A374ED020000D7000461FC@SRCMAIL.scires.com>

Martin:

Thanks for your question.

Please let me know what operating system platform you are using.

The first time you run CM3IDE, it asks about which editor and which browser you want to use.  These questions can be avoided by putting the information in your CM3.CFG file.

If you are using Microsoft IE and Windows, the required format of the response to the console dialog questions is not obvious.  

I will be glad to try and help you resolve this problem.  Please understand that CM3IDE is a new addition to the cm3 codebase and we are still working out some kinks.

Regards,
Randy

>>> Martin Bishop <martinbishop at bellsouth.net> 08/13/08 7:57 PM >>>
Martin Bishop wrote:
> I asked this on the mailing list, but I'll ask here too.
> 
> I compiled CM3, and all went well, but when I try to run "cm3ide" it
> asks me for browser and editor to use, which I tell it, and then it just
> hangs.
> 
> I tried going to http://localhost:3800, but it doesn't appear any
> service is running (browser just gives an error)
> 

Of course I meant on the usenet group, as this IS the mailing list :P




From rcoleburn at scires.com  Thu Aug 14 06:43:07 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Thu, 14 Aug 2008 00:43:07 -0400
Subject: [M3devel] CM3IDE
In-Reply-To: <48A374ED020000D7000461FC@SRCMAIL.scires.com>
References: <48A374ED020000D7000461FC@SRCMAIL.scires.com>
Message-ID: <48A37F94.1E75.00D7.1@scires.com>

Martin:
 
Sorry, I reread my post and realized I forgot to tell you the variables that can go into cm3\bin\cm3.cfg
 
INITIAL_CM3_IDE_BROWSER
INITIAL_CM3_IDE_EDITOR
 
If you are on Windows, you will need to escape the backslash character, e.g.
INITIAL_CM3_IDE_BROWSER="C:\\Program Files\\Internet Explorer\\iexplore.exe"
 
You should set the following environment variable to point to the location where your "private" Modula-3 projects are stored:  CM3_IDE_HOME
 
For example, CM3_IDE_HOME=C:\MyM3Projects
 
If you are using Microsoft Windows and you want to use paths with spaces, you should use the Microsoft short name equivalents, e.g., CM3_IDE_HOME=C:\DOCUME~1\mbishop\MYDOCU~1\CM3Home
 
Regards,
Randy

>>> "Randy Coleburn" <rcoleburn at scires.com> 8/13/2008 11:57 PM >>>
Martin:

Thanks for your question.

Please let me know what operating system platform you are using.

The first time you run CM3IDE, it asks about which editor and which browser you want to use.  These questions can be avoided by putting the information in your CM3.CFG file.

If you are using Microsoft IE and Windows, the required format of the response to the console dialog questions is not obvious.  

I will be glad to try and help you resolve this problem.  Please understand that CM3IDE is a new addition to the cm3 codebase and we are still working out some kinks.

Regards,
Randy

>>> Martin Bishop <martinbishop at bellsouth.net> 08/13/08 7:57 PM >>>
Martin Bishop wrote:
> I asked this on the mailing list, but I'll ask here too.
> 
> I compiled CM3, and all went well, but when I try to run "cm3ide" it
> asks me for browser and editor to use, which I tell it, and then it just
> hangs.
> 
> I tried going to http://localhost:3800, but it doesn't appear any
> service is running (browser just gives an error)
> 

Of course I meant on the usenet group, as this IS the mailing list :P



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080814/ca4f1365/attachment.html>

From mika at async.caltech.edu  Thu Aug 14 10:08:54 2008
From: mika at async.caltech.edu (Mika Nystrom)
Date: Thu, 14 Aug 2008 01:08:54 -0700
Subject: [M3devel] FW: [M3commit] CVS Update: cm3
In-Reply-To: Your message of "Wed, 13 Aug 2008 23:30:23 EDT."
	<48A36E8F020000D7000461EC@SRCMAIL.scires.com> 
Message-ID: <200808140808.m7E88shk081883@camembert.async.caltech.edu>

...
>I've misplaced my Nelson. I'll get another and see if I can understand this..

You may want to just google for "SRC Research Report 68" and "...69"

    Mika

>I'm also curious to see if Tk and Qt draw scrollbars themselves or not.
>I'll probably check soon (or by end of month, will be gone next week, out of t
>ouch).
>
> - Jay


From jay.krell at cornell.edu  Thu Aug 14 14:17:29 2008
From: jay.krell at cornell.edu (Jay)
Date: Thu, 14 Aug 2008 12:17:29 +0000
Subject: [M3devel] FW: [M3commit] CVS Update: cm3
In-Reply-To: <200808140808.m7E88shk081883@camembert.async.caltech.edu>
References: Your message of 
	<200808140808.m7E88shk081883@camembert.async.caltech.edu>
Message-ID: <COL101-W2370AECE37D9828B834395E6720@phx.gbl>


Awesome, thanks.

 - Jay


> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] FW: [M3commit] CVS Update: cm3
> Date: Thu, 14 Aug 2008 01:08:54 -0700
> From: mika at async.caltech.edu
>
> ...
>>I've misplaced my Nelson. I'll get another and see if I can understand this..
>
> You may want to just google for "SRC Research Report 68" and "...69"
>
> Mika
>
>>I'm also curious to see if Tk and Qt draw scrollbars themselves or not.
>>I'll probably check soon (or by end of month, will be gone next week, out of t
>>ouch).
>>
>> - Jay


From jay.krell at cornell.edu  Thu Aug 14 14:46:06 2008
From: jay.krell at cornell.edu (Jay)
Date: Thu, 14 Aug 2008 12:46:06 +0000
Subject: [M3devel] windows move/scroller
Message-ID: <COL101-W123B5E9D268CE608107D40E6720@phx.gbl>


Randy, your scrollervbclass.m3 looks ok or better.

I went to try other gui apps, see if I could see the failure-to-move bug.
It seems that most gui apps now crash.
formsvbtedit is ok.


***
*** runtime error:
***     failed.
***    file "..\src\winvbt\WinContext.m3", line 171
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0x6e1f80c  0x1011cf9  PushPixmap + 0x49b in ..\src\winvbt\WinContext.m3
0x6e1f8d4  0x101fd0c  PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3
0x6e1fd30  0x101dc35  PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3
0x6e1fd98  0x10184ee  PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3
0x6e1fde0  0x1016ded  WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3
0x6e1fe0c  0x7d9472d8  
0x6e1fe84  0x7d947568  
0x6e1fefc  0x7d94778d  
0x6e1ff0c  0x7d94ab86  
0x6e1ff54  0x101bbc9  MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3
.........  .........  ... more frames ...
(a3c.aec): Break instruction exception - code 80000003 (first chance)
eax=00000001 ebx=000000ab ecx=0000ff27 edx=0000001c esi=06e1f5b0 edi=006358eb
eip=7d61002d esp=06e1f598 ebp=06e1f5b0 iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202
ntdll32!DbgBreakPoint:
7d61002d cc              int     3


The "funny" thing is that when this occurs, lots of scrollbar arrows have been drawn
at the wrong place -- filling up Juno's canvas.

This happens with current ScrollerVBClass.m3, or copying the Posix one over Win32,
or your current one.

I changed PushPixMap to print GetLastError, but it is 0. :(

I'll dig a bit.

Not great.
 - Jay


From jay.krell at cornell.edu  Thu Aug 14 15:07:09 2008
From: jay.krell at cornell.edu (Jay)
Date: Thu, 14 Aug 2008 13:07:09 +0000
Subject: [M3devel] another trestle bug..
Message-ID: <COL101-W3271758E974746EF2E7BEBE6720@phx.gbl>


Sigh..in FormsVBTEdit, control-a to select all, control-c to copy, control-c to copy again:



***
*** runtime error:
***    Thread client error: Attempt to lock mutex already locked by self
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 155
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0x6a0f1d0   0x57ba8c  Die + 0x2d in ..\src\thread\WIN32\ThreadWin32.m3
0x6a0f204   0x578d22  LockMutex + 0x13a in ..\src\thread\WIN32\ThreadWin32.m3
0x6a0f24c   0xec9f01  LostClipboard + 0x7f in ..\src\winvbt\WinTrestle.m3
0x6a0f288   0xec702c  WindowProc + 0x8c8 in ..\src\winvbt\WinTrestle.m3
0x6a0f2b4  0x7d9472d8  
0x6a0f32c  0x7d947568  
0x6a0f388  0x7d947d93  
0x6a0f3c8  0x7d969cb2  
0x6a0f43c  0x7d61ea0e  
0x6a0f46c   0xec4506  Acquire + 0x2f in ..\src\winvbt\WinTrestle.m3
.........  .........  ... more frames ...

full stack is:


ChildEBP RetAddr
06a0f144 00575937 ntdll32!DbgBreakPoint
06a0f160 0056c42e m3core!RTOS__Crash+0x4c
06a0f178 0056a19e m3core!RTProcess__Crash+0x68
06a0f190 00569e1d m3core!RTError__EndError+0x37
06a0f1a8 0057ba8c m3core!RTError__Msg+0x8d
06a0f1d0 00578d22 m3core!ThreadWin32__Die+0x2d
06a0f204 00ec9f01 m3core!ThreadWin32__LockMutex+0x13a
06a0f24c 00ec702c m3ui!WinTrestle__LostClipboard+0x7f
06a0f288 7d9472d8 m3ui!WinTrestle__WindowProc+0x8c8
06a0f2b4 7d947568 user32!InternalCallWinProc+0x28
06a0f32c 7d947d93 user32!UserCallWinProcCheckWow+0x114
06a0f388 7d969cb2 user32!DispatchClientMessage+0xdf
06a0f3c8 7d61ea0e user32!__fnINDESTROYCLIPBRD+0x2c
06a0f3fc 00ec46bf ntdll32!KiUserCallbackDispatcher+0x2e
06a0f43c 00ec4506 m3ui!WinTrestle__Acquire__AcquireClipboard+0xf5
06a0f46c 00f327d8 m3ui!WinTrestle__Acquire+0x2f
06a0f4bc 00eedf1a m3ui!ETAgent__Acquire+0x21e
06a0f4f8 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
06a0f534 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
06a0f570 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
06a0f5ac 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
06a0f5e8 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
06a0f624 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
06a0f660 00f327d8 m3ui!VBTClass__AcquireDefault+0x110
06a0f6b0 00e06f96 m3ui!ETAgent__Acquire+0x21e
06a0f6e8 00eedf1a m3vbtkit!ReactivityVBT__Acquire+0x46
06a0f724 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
06a0f760 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
06a0f79c 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
06a0f7d8 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
06a0f814 00eed0e7 m3ui!VBTClass__AcquireDefault+0x110
06a0f848 00ee191b m3ui!VBTClass__Acquire+0xe1
06a0f874 00e3c80d m3ui!VBT__Acquire+0x56
06a0f918 00e3c737 m3vbtkit!TextPortClass__TakeSelection__take+0x7e
06a0f944 00e49ace m3vbtkit!TextPortClass__TakeSelection+0xbe
06a0f97c 00e49109 m3vbtkit!MacModel__Copy+0x87
06a0f9a4 00e3407d m3vbtkit!MacModel__ControlChord+0xd9
06a0fa1c 10026730 m3vbtkit!TextPort__Filter+0x243
06a0fa58 00405eaa m3formsvbt!FVRuntime__PortFilter+0xc3
06a0fb18 00e33e32 formsedit!FormsEditVBT__EPortFilter+0x3ac
06a0fb48 00e48c0e m3vbtkit!TextPort__ApplyStandardKeyFilter+0x89
06a0fb98 00e33da1 m3vbtkit!MacModel__ApplyMacFilter+0xcf
06a0fbf8 00eeae96 m3vbtkit!TextPort__Key+0x1a4
06a0fc30 00f33cd5 m3ui!VBTClass__Key+0xa5
06a0fc74 00e06f48 m3ui!ETAgent__KeyCode+0x19b
06a0fc94 00eeae96 m3vbtkit!ReactivityVBT__Key+0x42
06a0fccc 00f33cd5 m3ui!VBTClass__Key+0xa5
06a0fd10 00eeae96 m3ui!ETAgent__KeyCode+0x19b
06a0fd48 00ec8fbf m3ui!VBTClass__Key+0xa5
06a0fd9c 00ec6ef0 m3ui!WinTrestle__VBTKeyPress+0xfd
06a0fde0 7d9472d8 m3ui!WinTrestle__WindowProc+0x78c
06a0fe0c 7d947568 user32!InternalCallWinProc+0x28
06a0fe84 7d94778d user32!UserCallWinProcCheckWow+0x114
06a0fefc 7d94ab86 user32!DispatchMessageWorker+0x37b
06a0ff0c 00ecbbd9 user32!DispatchMessageA+0xf
06a0ff54 0057a69a m3ui!WinTrestle__MessengerApply+0x21f
06a0ff8c 0057a433 m3core!ThreadWin32__RunThread+0x1f6
06a0ffb8 7d4dfe21 m3core!ThreadWin32__ThreadBase+0x3a
06a0ffec 00000000 kernel32!BaseThreadStart+0x34


From wagner at elegosoft.com  Thu Aug 14 15:16:38 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Thu, 14 Aug 2008 15:16:38 +0200
Subject: [M3devel] another trestle bug..
In-Reply-To: <COL101-W3271758E974746EF2E7BEBE6720@phx.gbl>
References: <COL101-W3271758E974746EF2E7BEBE6720@phx.gbl>
Message-ID: <20080814151638.enfxv3axvok0g8wc@mail.elegosoft.com>

Quoting Jay <jay.krell at cornell.edu>:

>
> Sigh..in FormsVBTEdit, control-a to select all, control-c to copy,   
> control-c to copy again:
>
>
>
> ***
> *** runtime error:
> ***    Thread client error: Attempt to lock mutex already locked by self
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 155
> ***

This may well be a side-effect of my changes, though I didn't notice
it. You may want to check the old code of the MacModel :-/
If it is, we have to review the mutex use.

Olaf

> Stack trace:
>    FP         PC      Procedure
> ---------  ---------  -------------------------------
> 0x6a0f1d0   0x57ba8c  Die + 0x2d in ..\src\thread\WIN32\ThreadWin32.m3
> 0x6a0f204   0x578d22  LockMutex + 0x13a in ..\src\thread\WIN32\ThreadWin32.m3
> 0x6a0f24c   0xec9f01  LostClipboard + 0x7f in ..\src\winvbt\WinTrestle.m3
> 0x6a0f288   0xec702c  WindowProc + 0x8c8 in ..\src\winvbt\WinTrestle.m3
> 0x6a0f2b4  0x7d9472d8
> 0x6a0f32c  0x7d947568
> 0x6a0f388  0x7d947d93
> 0x6a0f3c8  0x7d969cb2
> 0x6a0f43c  0x7d61ea0e
> 0x6a0f46c   0xec4506  Acquire + 0x2f in ..\src\winvbt\WinTrestle.m3
> .........  .........  ... more frames ...
>
> full stack is:
>
>
> ChildEBP RetAddr
> 06a0f144 00575937 ntdll32!DbgBreakPoint
> 06a0f160 0056c42e m3core!RTOS__Crash+0x4c
> 06a0f178 0056a19e m3core!RTProcess__Crash+0x68
> 06a0f190 00569e1d m3core!RTError__EndError+0x37
> 06a0f1a8 0057ba8c m3core!RTError__Msg+0x8d
> 06a0f1d0 00578d22 m3core!ThreadWin32__Die+0x2d
> 06a0f204 00ec9f01 m3core!ThreadWin32__LockMutex+0x13a
> 06a0f24c 00ec702c m3ui!WinTrestle__LostClipboard+0x7f
> 06a0f288 7d9472d8 m3ui!WinTrestle__WindowProc+0x8c8
> 06a0f2b4 7d947568 user32!InternalCallWinProc+0x28
> 06a0f32c 7d947d93 user32!UserCallWinProcCheckWow+0x114
> 06a0f388 7d969cb2 user32!DispatchClientMessage+0xdf
> 06a0f3c8 7d61ea0e user32!__fnINDESTROYCLIPBRD+0x2c
> 06a0f3fc 00ec46bf ntdll32!KiUserCallbackDispatcher+0x2e
> 06a0f43c 00ec4506 m3ui!WinTrestle__Acquire__AcquireClipboard+0xf5
> 06a0f46c 00f327d8 m3ui!WinTrestle__Acquire+0x2f
> 06a0f4bc 00eedf1a m3ui!ETAgent__Acquire+0x21e
> 06a0f4f8 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
> 06a0f534 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
> 06a0f570 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
> 06a0f5ac 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
> 06a0f5e8 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
> 06a0f624 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
> 06a0f660 00f327d8 m3ui!VBTClass__AcquireDefault+0x110
> 06a0f6b0 00e06f96 m3ui!ETAgent__Acquire+0x21e
> 06a0f6e8 00eedf1a m3vbtkit!ReactivityVBT__Acquire+0x46
> 06a0f724 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
> 06a0f760 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
> 06a0f79c 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
> 06a0f7d8 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
> 06a0f814 00eed0e7 m3ui!VBTClass__AcquireDefault+0x110
> 06a0f848 00ee191b m3ui!VBTClass__Acquire+0xe1
> 06a0f874 00e3c80d m3ui!VBT__Acquire+0x56
> 06a0f918 00e3c737 m3vbtkit!TextPortClass__TakeSelection__take+0x7e
> 06a0f944 00e49ace m3vbtkit!TextPortClass__TakeSelection+0xbe
> 06a0f97c 00e49109 m3vbtkit!MacModel__Copy+0x87
> 06a0f9a4 00e3407d m3vbtkit!MacModel__ControlChord+0xd9
> 06a0fa1c 10026730 m3vbtkit!TextPort__Filter+0x243
> 06a0fa58 00405eaa m3formsvbt!FVRuntime__PortFilter+0xc3
> 06a0fb18 00e33e32 formsedit!FormsEditVBT__EPortFilter+0x3ac
> 06a0fb48 00e48c0e m3vbtkit!TextPort__ApplyStandardKeyFilter+0x89
> 06a0fb98 00e33da1 m3vbtkit!MacModel__ApplyMacFilter+0xcf
> 06a0fbf8 00eeae96 m3vbtkit!TextPort__Key+0x1a4
> 06a0fc30 00f33cd5 m3ui!VBTClass__Key+0xa5
> 06a0fc74 00e06f48 m3ui!ETAgent__KeyCode+0x19b
> 06a0fc94 00eeae96 m3vbtkit!ReactivityVBT__Key+0x42
> 06a0fccc 00f33cd5 m3ui!VBTClass__Key+0xa5
> 06a0fd10 00eeae96 m3ui!ETAgent__KeyCode+0x19b
> 06a0fd48 00ec8fbf m3ui!VBTClass__Key+0xa5
> 06a0fd9c 00ec6ef0 m3ui!WinTrestle__VBTKeyPress+0xfd
> 06a0fde0 7d9472d8 m3ui!WinTrestle__WindowProc+0x78c
> 06a0fe0c 7d947568 user32!InternalCallWinProc+0x28
> 06a0fe84 7d94778d user32!UserCallWinProcCheckWow+0x114
> 06a0fefc 7d94ab86 user32!DispatchMessageWorker+0x37b
> 06a0ff0c 00ecbbd9 user32!DispatchMessageA+0xf
> 06a0ff54 0057a69a m3ui!WinTrestle__MessengerApply+0x21f
> 06a0ff8c 0057a433 m3core!ThreadWin32__RunThread+0x1f6
> 06a0ffb8 7d4dfe21 m3core!ThreadWin32__ThreadBase+0x3a
> 06a0ffec 00000000 kernel32!BaseThreadStart+0x34
>



-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From jay.krell at cornell.edu  Thu Aug 14 15:11:19 2008
From: jay.krell at cornell.edu (Jay)
Date: Thu, 14 Aug 2008 13:11:19 +0000
Subject: [M3devel] another trestle bug..
In-Reply-To: <COL101-W3271758E974746EF2E7BEBE6720@phx.gbl>
References: <COL101-W3271758E974746EF2E7BEBE6720@phx.gbl>
Message-ID: <COL101-W57222A54717D1E92781042E6720@phx.gbl>


Better yet, with file/line:


ChildEBP RetAddr
06a0f144 00575937 ntdll32!DbgBreakPoint
06a0f160 0056c42e m3core!RTOS__Crash+0x4c [..\src\runtime\WIN32\RTOS.m3 @ 29]
06a0f178 0056a19e m3core!RTProcess__Crash+0x68 [..\src\runtime\common\RTProcess.m3 @ 66]
06a0f190 00569e1d m3core!RTError__EndError+0x37 [..\src\runtime\common\RTError.m3 @ 118]
06a0f1a8 0057ba8c m3core!RTError__Msg+0x8d [..\src\runtime\common\RTError.m3 @ 23]
06a0f1d0 00578d22 m3core!ThreadWin32__Die+0x2d [..\src\thread\WIN32\ThreadWin32.m3 @ 982]
06a0f204 00ec9f01 m3core!ThreadWin32__LockMutex+0x13a [..\src\thread\WIN32\ThreadWin32.m3 @ 155]
06a0f24c 00ec702c m3ui!WinTrestle__LostClipboard+0x7f [..\src\winvbt\WinTrestle.m3 @ 2044]
06a0f288 7d9472d8 m3ui!WinTrestle__WindowProc+0x8c8 [..\src\winvbt\WinTrestle.m3 @ 1211]
06a0f2b4 7d947568 user32!InternalCallWinProc+0x28
06a0f32c 7d947d93 user32!UserCallWinProcCheckWow+0x114
06a0f388 7d969cb2 user32!DispatchClientMessage+0xdf
06a0f3c8 7d61ea0e user32!__fnINDESTROYCLIPBRD+0x2c
06a0f3fc 00ec46bf ntdll32!KiUserCallbackDispatcher+0x2e
06a0f43c 00ec4506 m3ui!WinTrestle__Acquire__AcquireClipboard+0xf5 [..\src\winvbt\WinTrestle.m3 @ 431]
06a0f46c 00f327d8 m3ui!WinTrestle__Acquire+0x2f [..\src\winvbt\WinTrestle.m3 @ 445]
06a0f4bc 00eedf1a m3ui!ETAgent__Acquire+0x21e [..\src\split\ETAgent.m3 @ 120]
06a0f4f8 00eedf1a m3ui!VBTClass__AcquireDefault+0x110 [..\src\vbt\VBTClass.m3 @834]
06a0f534 00eedf1a m3ui!VBTClass__AcquireDefault+0x110 [..\src\vbt\VBTClass.m3 @834]
06a0f570 00eedf1a m3ui!VBTClass__AcquireDefault+0x110 [..\src\vbt\VBTClass.m3 @834]
06a0f5ac 00eedf1a m3ui!VBTClass__AcquireDefault+0x110 [..\src\vbt\VBTClass.m3 @834]
06a0f5e8 00eedf1a m3ui!VBTClass__AcquireDefault+0x110 [..\src\vbt\VBTClass.m3 @834]
06a0f624 00eedf1a m3ui!VBTClass__AcquireDefault+0x110 [..\src\vbt\VBTClass.m3 @834]
06a0f660 00f327d8 m3ui!VBTClass__AcquireDefault+0x110 [..\src\vbt\VBTClass.m3 @834]
06a0f6b0 00e06f96 m3ui!ETAgent__Acquire+0x21e [..\src\split\ETAgent.m3 @ 120]
06a0f6e8 00eedf1a m3vbtkit!ReactivityVBT__Acquire+0x46 [..\src\lego\ReactivityVBT.m3 @ 222]
06a0f724 00eedf1a m3ui!VBTClass__AcquireDefault+0x110 [..\src\vbt\VBTClass.m3 @834]
06a0f760 00eedf1a m3ui!VBTClass__AcquireDefault+0x110 [..\src\vbt\VBTClass.m3 @834]
06a0f79c 00eedf1a m3ui!VBTClass__AcquireDefault+0x110 [..\src\vbt\VBTClass.m3 @834]
06a0f7d8 00eedf1a m3ui!VBTClass__AcquireDefault+0x110 [..\src\vbt\VBTClass.m3 @834]
06a0f814 00eed0e7 m3ui!VBTClass__AcquireDefault+0x110 [..\src\vbt\VBTClass.m3 @834]
06a0f848 00ee191b m3ui!VBTClass__Acquire+0xe1 [..\src\vbt\VBTClass.m3 @ 612]
06a0f874 00e3c80d m3ui!VBT__Acquire+0x56 [..\src\vbt\VBT.m3 @ 156]
06a0f918 00e3c737 m3vbtkit!TextPortClass__TakeSelection__take+0x7e [..\src\etext\TextPortClass.m3 @ 833]
06a0f944 00e49ace m3vbtkit!TextPortClass__TakeSelection+0xbe [..\src\etext\TextPortClass.m3 @ 852]
06a0f97c 00e49109 m3vbtkit!MacModel__Copy+0x87 [..\src\etext\MacModel.m3 @ 371]
06a0f9a4 00e3407d m3vbtkit!MacModel__ControlChord+0xd9 [..\src\etext\MacModel.m3 @ 269]
06a0fa1c 10026730 m3vbtkit!TextPort__Filter+0x243 [..\src\etext\TextPort.m3 @ 768]
06a0fa58 00405eaa m3formsvbt!FVRuntime__PortFilter+0xc3 [..\src\FVRuntime.m3 @ 819]
06a0fb18 00e33e32 formsedit!FormsEditVBT__EPortFilter+0x3ac [..\src\FormsEditVBT.m3 @ 711]
06a0fb48 00e48c0e m3vbtkit!TextPort__ApplyStandardKeyFilter+0x89 [..\src\etext\TextPort.m3 @ 740]
06a0fb98 00e33da1 m3vbtkit!MacModel__ApplyMacFilter+0xcf [..\src\etext\MacModel.m3 @ 91]
06a0fbf8 00eeae96 m3vbtkit!TextPort__Key+0x1a4 [..\src\etext\TextPort.m3 @ 732]
06a0fc30 00f33cd5 m3ui!VBTClass__Key+0xa5 [..\src\vbt\VBTClass.m3 @ 250]
06a0fc74 00e06f48 m3ui!ETAgent__KeyCode+0x19b [..\src\split\ETAgent.m3 @ 295]
06a0fc94 00eeae96 m3vbtkit!ReactivityVBT__Key+0x42 [..\src\lego\ReactivityVBT.m3 @ 215]
06a0fccc 00f33cd5 m3ui!VBTClass__Key+0xa5 [..\src\vbt\VBTClass.m3 @ 250]
06a0fd10 00eeae96 m3ui!ETAgent__KeyCode+0x19b [..\src\split\ETAgent.m3 @ 295]
06a0fd48 00ec8fbf m3ui!VBTClass__Key+0xa5 [..\src\vbt\VBTClass.m3 @ 250]
06a0fd9c 00ec6ef0 m3ui!WinTrestle__VBTKeyPress+0xfd [..\src\winvbt\WinTrestle.m3 @ 1734]
06a0fde0 7d9472d8 m3ui!WinTrestle__WindowProc+0x78c [..\src\winvbt\WinTrestle.m3 @ 1178]
06a0fe0c 7d947568 user32!InternalCallWinProc+0x28
06a0fe84 7d94778d user32!UserCallWinProcCheckWow+0x114
06a0fefc 7d94ab86 user32!DispatchMessageWorker+0x37b
06a0ff0c 00ecbbd9 user32!DispatchMessageA+0xf
06a0ff54 0057a69a m3ui!WinTrestle__MessengerApply+0x21f [..\src\winvbt\WinTrestle.m3 @ 2436]
06a0ff8c 0057a433 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread\WIN32\ThreadWin32.m3 @ 579]
06a0ffb8 7d4dfe21 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread\WIN32\ThreadWin32.m3 @ 548]
06a0ffec 00000000 kernel32!BaseThreadStart+0x34


 - Jay

> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Date: Thu, 14 Aug 2008 13:07:09 +0000
> Subject: [M3devel] another trestle bug..
>
>
> Sigh..in FormsVBTEdit, control-a to select all, control-c to copy, control-c to copy again:
>
>
>
> ***
> *** runtime error:
> *** Thread client error: Attempt to lock mutex already locked by self
> *** file "..\src\thread\WIN32\ThreadWin32.m3", line 155
> ***
>
> Stack trace:
> FP PC Procedure
> --------- --------- -------------------------------
> 0x6a0f1d0 0x57ba8c Die + 0x2d in ..\src\thread\WIN32\ThreadWin32.m3
> 0x6a0f204 0x578d22 LockMutex + 0x13a in ..\src\thread\WIN32\ThreadWin32.m3
> 0x6a0f24c 0xec9f01 LostClipboard + 0x7f in ..\src\winvbt\WinTrestle.m3
> 0x6a0f288 0xec702c WindowProc + 0x8c8 in ..\src\winvbt\WinTrestle.m3
> 0x6a0f2b4 0x7d9472d8
> 0x6a0f32c 0x7d947568
> 0x6a0f388 0x7d947d93
> 0x6a0f3c8 0x7d969cb2
> 0x6a0f43c 0x7d61ea0e
> 0x6a0f46c 0xec4506 Acquire + 0x2f in ..\src\winvbt\WinTrestle.m3
> ......... ......... ... more frames ...
>
> full stack is:
>
>
> ChildEBP RetAddr
> 06a0f144 00575937 ntdll32!DbgBreakPoint
> 06a0f160 0056c42e m3core!RTOS__Crash+0x4c
...

From wagner at elegosoft.com  Thu Aug 14 15:20:40 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Thu, 14 Aug 2008 15:20:40 +0200
Subject: [M3devel] windows move/scroller
In-Reply-To: <COL101-W123B5E9D268CE608107D40E6720@phx.gbl>
References: <COL101-W123B5E9D268CE608107D40E6720@phx.gbl>
Message-ID: <20080814152040.tu00bh7jqckg0w8w@mail.elegosoft.com>

Quoting Jay <jay.krell at cornell.edu>:

>
> Randy, your scrollervbclass.m3 looks ok or better.
>
> I went to try other gui apps, see if I could see the failure-to-move bug.
> It seems that most gui apps now crash.
> formsvbtedit is ok.
>
>
> ***
> *** runtime error:
> ***     failed.
> ***    file "..\src\winvbt\WinContext.m3", line 171
> ***
>
> Stack trace:
>    FP         PC      Procedure
> ---------  ---------  -------------------------------
> 0x6e1f80c  0x1011cf9  PushPixmap + 0x49b in ..\src\winvbt\WinContext.m3
> 0x6e1f8d4  0x101fd0c  PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3
> 0x6e1fd30  0x101dc35  PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3
> 0x6e1fd98  0x10184ee  PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3
> 0x6e1fde0  0x1016ded  WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3
> 0x6e1fe0c  0x7d9472d8
> 0x6e1fe84  0x7d947568
> 0x6e1fefc  0x7d94778d
> 0x6e1ff0c  0x7d94ab86
> 0x6e1ff54  0x101bbc9  MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3
> .........  .........  ... more frames ...
> (a3c.aec): Break instruction exception - code 80000003 (first chance)
> eax=00000001 ebx=000000ab ecx=0000ff27 edx=0000001c esi=06e1f5b0 edi=006358eb
> eip=7d61002d esp=06e1f598 ebp=06e1f5b0 iopl=0         nv up ei pl nz na po nc
> cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202
> ntdll32!DbgBreakPoint:
> 7d61002d cc              int     3
>
>
> The "funny" thing is that when this occurs, lots of scrollbar arrows  
>  have been drawn
> at the wrong place -- filling up Juno's canvas.

Did Juno ever work on Windows' Trestle? I seem to remember that
the Windows implementation was not sufficient for this rather
sophisticated application, too many things were missing.

Olaf

>
> This happens with current ScrollerVBClass.m3, or copying the Posix   
> one over Win32,
> or your current one.
>
> I changed PushPixMap to print GetLastError, but it is 0. :(
>
> I'll dig a bit.
>
> Not great.
>  - Jay
>



-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From rcoleburn at scires.com  Thu Aug 14 16:38:22 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Thu, 14 Aug 2008 10:38:22 -0400
Subject: [M3devel] windows move/scroller
In-Reply-To: <20080814152040.tu00bh7jqckg0w8w@mail.elegosoft.com>
References: <COL101-W123B5E9D268CE608107D40E6720@phx.gbl>
	<20080814152040.tu00bh7jqckg0w8w@mail.elegosoft.com>
Message-ID: <48A40B18.1E75.00D7.1@scires.com>

Sorry, but I haven't used Juno, so I don't know if it worked on
Windows.
Regards,
Randy

>>> Olaf Wagner <wagner at elegosoft.com> 8/14/2008 9:20 AM >>>
Quoting Jay <jay.krell at cornell.edu>:

>
> Randy, your scrollervbclass.m3 looks ok or better.
>
> I went to try other gui apps, see if I could see the failure-to-move
bug.
> It seems that most gui apps now crash.
> formsvbtedit is ok.
>
>
> ***
> *** runtime error:
> ***     failed.
> ***    file "..\src\winvbt\WinContext.m3", line 171
> ***
>
> Stack trace:
>    FP         PC      Procedure
> ---------  ---------  -------------------------------
> 0x6e1f80c  0x1011cf9  PushPixmap + 0x49b in
..\src\winvbt\WinContext.m3
> 0x6e1f8d4  0x101fd0c  PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3
> 0x6e1fd30  0x101dc35  PaintBatch + 0x225 in
..\src\winvbt\WinPaint.m3
> 0x6e1fd98  0x10184ee  PaintBatchVBT + 0x12d in
..\src\winvbt\WinTrestle.m3
> 0x6e1fde0  0x1016ded  WindowProc + 0x699 in
..\src\winvbt\WinTrestle.m3
> 0x6e1fe0c  0x7d9472d8
> 0x6e1fe84  0x7d947568
> 0x6e1fefc  0x7d94778d
> 0x6e1ff0c  0x7d94ab86
> 0x6e1ff54  0x101bbc9  MessengerApply + 0x21f in
..\src\winvbt\WinTrestle.m3
> .........  .........  ... more frames ...
> (a3c.aec): Break instruction exception - code 80000003 (first
chance)
> eax=00000001 ebx=000000ab ecx=0000ff27 edx=0000001c esi=06e1f5b0
edi=006358eb
> eip=7d61002d esp=06e1f598 ebp=06e1f5b0 iopl=0         nv up ei pl nz
na po nc
> cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b            
efl=00000202
> ntdll32!DbgBreakPoint:
> 7d61002d cc              int     3
>
>
> The "funny" thing is that when this occurs, lots of scrollbar arrows 

>  have been drawn
> at the wrong place -- filling up Juno's canvas.

Did Juno ever work on Windows' Trestle? I seem to remember that
the Windows implementation was not sufficient for this rather
sophisticated application, too many things were missing.

Olaf

>
> This happens with current ScrollerVBClass.m3, or copying the Posix  

> one over Win32,
> or your current one.
>
> I changed PushPixMap to print GetLastError, but it is 0. :(
>
> I'll dig a bit.
>
> Not great.
>  - Jay
>



-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin,
Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45
86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz:
Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:
DE163214194


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080814/6256aebf/attachment.html>

From jay.krell at cornell.edu  Thu Aug 14 16:38:33 2008
From: jay.krell at cornell.edu (Jay)
Date: Thu, 14 Aug 2008 14:38:33 +0000
Subject: [M3devel] windows move/scroller
In-Reply-To: <20080814152040.tu00bh7jqckg0w8w@mail.elegosoft.com>
References: <COL101-W123B5E9D268CE608107D40E6720@phx.gbl>
	<20080814152040.tu00bh7jqckg0w8w@mail.elegosoft.com>
Message-ID: <COL101-W298075CF2F20ED878F16C1E6720@phx.gbl>


I admit I can't remember between NT386GNU and NT386.
At least one of them Juno works on, at least better than I'm seeing on NT386 today.
Juno gets pretty far on NT386. The splash screen comes up, the loading progress,
most of the initial gui comes up, except the "canvas" is full of scrollbar arrows.
 
I'll have to try with 3.6/4.1..
 
A few seconds with mentor and I got:
 
D:\dev2\cm3.2\m3-ui\ui\src\winvbt>\cm3\bin\mentor.exeCreatePatternBrush failed with  0
****** runtime error:***    A runtime error occurred.***    pc = 0x7d61002d***
Stack trace:   FP         PC      Procedure---------  ---------  -------------------------------0x72af77c   0x9266ae  SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.m30x72af80c  0x7d61002d  <???>0x72af8d4  0x147fe8c  PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m30x72afd30  0x147ddb5  PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m30x72afd98  0x147867e  PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m30x72afde0  0x1476f7d  WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m30x72afe0c  0x7d9472d8  <???>0x72afe84  0x7d947568  <???>0x72afefc  0x7d94778d  <???>0x72aff0c  0x7d94ab86  <???>.........  .........  ... more frames ...
 
Maybe a divide by zero since I don't know how to setup mentor usefully..
Looks different than Juno.
 
Calculator works.
 
 - Jay
> Date: Thu, 14 Aug 2008 15:20:40 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] windows move/scroller> > Quoting Jay <jay.krell at cornell.edu>:> > >> > Randy, your scrollervbclass.m3 looks ok or better.> >> > I went to try other gui apps, see if I could see the failure-to-move bug.> > It seems that most gui apps now crash.> > formsvbtedit is ok.> >> >> > ***> > *** runtime error:> > *** failed.> > *** file "..\src\winvbt\WinContext.m3", line 171> > ***> >> > Stack trace:> > FP PC Procedure> > --------- --------- -------------------------------> > 0x6e1f80c 0x1011cf9 PushPixmap + 0x49b in ..\src\winvbt\WinContext.m3> > 0x6e1f8d4 0x101fd0c PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3> > 0x6e1fd30 0x101dc35 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3> > 0x6e1fd98 0x10184ee PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3> > 0x6e1fde0 0x1016ded WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3> > 0x6e1fe0c 0x7d9472d8> > 0x6e1fe84 0x7d947568> > 0x6e1fefc 0x7d94778d> > 0x6e1ff0c 0x7d94ab86> > 0x6e1ff54 0x101bbc9 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3> > ......... ......... ... more frames ...> > (a3c.aec): Break instruction exception - code 80000003 (first chance)> > eax=00000001 ebx=000000ab ecx=0000ff27 edx=0000001c esi=06e1f5b0 edi=006358eb> > eip=7d61002d esp=06e1f598 ebp=06e1f5b0 iopl=0 nv up ei pl nz na po nc> > cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202> > ntdll32!DbgBreakPoint:> > 7d61002d cc int 3> >> >> > The "funny" thing is that when this occurs, lots of scrollbar arrows > > have been drawn> > at the wrong place -- filling up Juno's canvas.> > Did Juno ever work on Windows' Trestle? I seem to remember that> the Windows implementation was not sufficient for this rather> sophisticated application, too many things were missing.> > Olaf> > >> > This happens with current ScrollerVBClass.m3, or copying the Posix > > one over Win32,> > or your current one.> >> > I changed PushPixMap to print GetLastError, but it is 0. :(> >> > I'll dig a bit.> >> > Not great.> > - Jay> >> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080814/28a08669/attachment.html>

From jay.krell at cornell.edu  Thu Aug 14 17:01:51 2008
From: jay.krell at cornell.edu (Jay)
Date: Thu, 14 Aug 2008 15:01:51 +0000
Subject: [M3devel] windows move/scroller
In-Reply-To: <20080814152040.tu00bh7jqckg0w8w@mail.elegosoft.com>
References: <COL101-W123B5E9D268CE608107D40E6720@phx.gbl>
	<20080814152040.tu00bh7jqckg0w8w@mail.elegosoft.com> 
Message-ID: <COL101-W37231C33F530CED8ACFD67E6720@phx.gbl>


Juno was not in 3.6 and 4.1.

 - Jay


________________________________

From: jay.krell at cornell.edu
To: wagner at elegosoft.com; m3devel at elegosoft.com
Subject: RE: [M3devel] windows move/scroller
Date: Thu, 14 Aug 2008 14:38:33 +0000




I admit I can't remember between NT386GNU and NT386.
At least one of them Juno works on, at least better than I'm seeing on NT386 today.
Juno gets pretty far on NT386. The splash screen comes up, the loading progress,
most of the initial gui comes up, except the "canvas" is full of scrollbar arrows.

I'll have to try with 3.6/4.1..

A few seconds with mentor and I got:

D:\dev2\cm3.2\m3-ui\ui\src\winvbt>\cm3\bin\mentor.exe
CreatePatternBrush failed with  0

***
*** runtime error:
***    A runtime error occurred.
***    pc = 0x7d61002d
***
Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0x72af77c   0x9266ae  SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.m3
0x72af80c  0x7d61002d  
0x72af8d4  0x147fe8c  PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3
0x72afd30  0x147ddb5  PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3
0x72afd98  0x147867e  PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3
0x72afde0  0x1476f7d  WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3
0x72afe0c  0x7d9472d8  
0x72afe84  0x7d947568  
0x72afefc  0x7d94778d  
0x72aff0c  0x7d94ab86  
.........  .........  ... more frames ...

Maybe a divide by zero since I don't know how to setup mentor usefully..
Looks different than Juno.

Calculator works.

 - Jay

> Date: Thu, 14 Aug 2008 15:20:40 +0200
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] windows move/scroller
>
> Quoting Jay :
>
>>
>> Randy, your scrollervbclass.m3 looks ok or better.
>>
>> I went to try other gui apps, see if I could see the failure-to-move bug.
>> It seems that most gui apps now crash.
>> formsvbtedit is ok.
>>
>>
>> ***
>> *** runtime error:
>> *** failed.
>> *** file "..\src\winvbt\WinContext.m3", line 171
>> ***
>>
>> Stack trace:
>> FP PC Procedure
>> --------- --------- -------------------------------
>> 0x6e1f80c 0x1011cf9 PushPixmap + 0x49b in ..\src\winvbt\WinContext.m3
>> 0x6e1f8d4 0x101fd0c PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3
>> 0x6e1fd30 0x101dc35 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3
>> 0x6e1fd98 0x10184ee PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3
>> 0x6e1fde0 0x1016ded WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3
>> 0x6e1fe0c 0x7d9472d8
>> 0x6e1fe84 0x7d947568
>> 0x6e1fefc 0x7d94778d
>> 0x6e1ff0c 0x7d94ab86
>> 0x6e1ff54 0x101bbc9 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3
>> ......... ......... ... more frames ...
>> (a3c.aec): Break instruction exception - code 80000003 (first chance)
>> eax=00000001 ebx=000000ab ecx=0000ff27 edx=0000001c esi=06e1f5b0 edi=006358eb
>> eip=7d61002d esp=06e1f598 ebp=06e1f5b0 iopl=0 nv up ei pl nz na po nc
>> cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
>> ntdll32!DbgBreakPoint:
>> 7d61002d cc int 3
>>
>>
>> The "funny" thing is that when this occurs, lots of scrollbar arrows
>> have been drawn
>> at the wrong place -- filling up Juno's canvas.
>
> Did Juno ever work on Windows' Trestle? I seem to remember that
> the Windows implementation was not sufficient for this rather
> sophisticated application, too many things were missing.
>
> Olaf
>
>>
>> This happens with current ScrollerVBClass.m3, or copying the Posix
>> one over Win32,
>> or your current one.
>>
>> I changed PushPixMap to print GetLastError, but it is 0. :(
>>
>> I'll dig a bit.
>>
>> Not great.
>> - Jay
>>
>
>
>
> --
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>



From jay.krell at cornell.edu  Thu Aug 14 17:08:26 2008
From: jay.krell at cornell.edu (Jay)
Date: Thu, 14 Aug 2008 15:08:26 +0000
Subject: [M3devel] windows move/scroller
In-Reply-To: <20080814152040.tu00bh7jqckg0w8w@mail.elegosoft.com>
References: <COL101-W123B5E9D268CE608107D40E6720@phx.gbl>
	<20080814152040.tu00bh7jqckg0w8w@mail.elegosoft.com>  
Message-ID: <COL101-W18E9D5B3112D5CFE53692BE6720@phx.gbl>


Could be that I had:


        brush := WinGDI.CreatePatternBrush (pst.pmtable[pm].hbmp);
        IF brush = NIL THEN
          win32error := WinBase.GetLastError ();
          IO.Put("CreatePatternBrush failed with " (* & Fmt.Address(brush) *) & " " & Fmt.Int(win32error) & "\n");
>>>          WinBase.DebugBreak ();
        END;
        


will remove that and see.
Fisheye sees this too ("RTSignal", we'll see if it was the breakpoint...)

 - Jay

> From: jay.krell at cornell.edu
> To: wagner at elegosoft.com; m3devel at elegosoft.com
> Subject: RE: [M3devel] windows move/scroller
> Date: Thu, 14 Aug 2008 15:01:51 +0000
>
>
> Juno was not in 3.6 and 4.1.
>
> - Jay
>
>
> ________________________________
>
> From: jay.krell at cornell.edu
> To: wagner at elegosoft.com; m3devel at elegosoft.com
> Subject: RE: [M3devel] windows move/scroller
> Date: Thu, 14 Aug 2008 14:38:33 +0000
>
>
>
>
> I admit I can't remember between NT386GNU and NT386.
> At least one of them Juno works on, at least better than I'm seeing on NT386 today.
> Juno gets pretty far on NT386. The splash screen comes up, the loading progress,
> most of the initial gui comes up, except the "canvas" is full of scrollbar arrows.
>
> I'll have to try with 3.6/4.1..
>
> A few seconds with mentor and I got:
>
> D:\dev2\cm3.2\m3-ui\ui\src\winvbt>\cm3\bin\mentor.exe
> CreatePatternBrush failed with 0
>
> ***
> *** runtime error:
> *** A runtime error occurred.
> *** pc = 0x7d61002d
> ***
> Stack trace:
> FP PC Procedure
> --------- --------- -------------------------------
> 0x72af77c 0x9266ae SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.m3
> 0x72af80c 0x7d61002d
> 0x72af8d4 0x147fe8c PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3
> 0x72afd30 0x147ddb5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3
> 0x72afd98 0x147867e PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3
> 0x72afde0 0x1476f7d WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3
> 0x72afe0c 0x7d9472d8
> 0x72afe84 0x7d947568
> 0x72afefc 0x7d94778d
> 0x72aff0c 0x7d94ab86
> ......... ......... ... more frames ...
>
> Maybe a divide by zero since I don't know how to setup mentor usefully..
> Looks different than Juno.
>
> Calculator works.
>
> - Jay
>
>> Date: Thu, 14 Aug 2008 15:20:40 +0200
>> From: wagner at elegosoft.com
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] windows move/scroller
>>
>> Quoting Jay :
>>
>>>
>>> Randy, your scrollervbclass.m3 looks ok or better.
>>>
>>> I went to try other gui apps, see if I could see the failure-to-move bug.
>>> It seems that most gui apps now crash.
>>> formsvbtedit is ok.
>>>
>>>
>>> ***
>>> *** runtime error:
>>> *** failed.
>>> *** file "..\src\winvbt\WinContext.m3", line 171
>>> ***
>>>
>>> Stack trace:
>>> FP PC Procedure
>>> --------- --------- -------------------------------
>>> 0x6e1f80c 0x1011cf9 PushPixmap + 0x49b in ..\src\winvbt\WinContext.m3
>>> 0x6e1f8d4 0x101fd0c PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3
>>> 0x6e1fd30 0x101dc35 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3
>>> 0x6e1fd98 0x10184ee PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3
>>> 0x6e1fde0 0x1016ded WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3
>>> 0x6e1fe0c 0x7d9472d8
>>> 0x6e1fe84 0x7d947568
>>> 0x6e1fefc 0x7d94778d
>>> 0x6e1ff0c 0x7d94ab86
>>> 0x6e1ff54 0x101bbc9 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3
>>> ......... ......... ... more frames ...
>>> (a3c.aec): Break instruction exception - code 80000003 (first chance)
>>> eax=00000001 ebx=000000ab ecx=0000ff27 edx=0000001c esi=06e1f5b0 edi=006358eb
>>> eip=7d61002d esp=06e1f598 ebp=06e1f5b0 iopl=0 nv up ei pl nz na po nc
>>> cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
>>> ntdll32!DbgBreakPoint:
>>> 7d61002d cc int 3
>>>
>>>
>>> The "funny" thing is that when this occurs, lots of scrollbar arrows
>>> have been drawn
>>> at the wrong place -- filling up Juno's canvas.
>>
>> Did Juno ever work on Windows' Trestle? I seem to remember that
>> the Windows implementation was not sufficient for this rather
>> sophisticated application, too many things were missing.
>>
>> Olaf
>>
>>>
>>> This happens with current ScrollerVBClass.m3, or copying the Posix
>>> one over Win32,
>>> or your current one.
>>>
>>> I changed PushPixMap to print GetLastError, but it is 0. :(
>>>
>>> I'll dig a bit.
>>>
>>> Not great.
>>> - Jay
>>>
>>
>>
>>
>> --
>> Olaf Wagner -- elego Software Solutions GmbH
>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>>
>


From wagner at elegosoft.com  Thu Aug 14 19:45:09 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Thu, 14 Aug 2008 19:45:09 +0200
Subject: [M3devel] another trestle bug..
In-Reply-To: <20080814151638.enfxv3axvok0g8wc@mail.elegosoft.com>
References: <COL101-W3271758E974746EF2E7BEBE6720@phx.gbl>
	<20080814151638.enfxv3axvok0g8wc@mail.elegosoft.com>
Message-ID: <20080814194509.6pl53v9csg04occ8@mail.elegosoft.com>

Quoting Olaf Wagner <wagner at elegosoft.com>:

> Quoting Jay <jay.krell at cornell.edu>:
>
>>
>> Sigh..in FormsVBTEdit, control-a to select all, control-c to copy,   
>>  control-c to copy again:
>>
>>
>>
>> ***
>> *** runtime error:
>> ***    Thread client error: Attempt to lock mutex already locked by self
>> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 155
>> ***
>
> This may well be a side-effect of my changes, though I didn't notice
> it. You may want to check the old code of the MacModel :-/
> If it is, we have to review the mutex use.

It's not related to the TextPort changes, but to WinTrestle.
I just tried on FreeBSD, and it works without a problem there.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From rodney.bates at wichita.edu  Fri Aug 15 03:20:07 2008
From: rodney.bates at wichita.edu (Rodney M. Bates)
Date: Thu, 14 Aug 2008 20:20:07 -0500
Subject: [M3devel] Recursive locks
In-Reply-To: <48A49161.1E75.00D7.1@scires.com>
References: <20080814142659.91A4A10D4F35@birch.elegosoft.com>
	<48A4134F.1E75.00D7.1@scires.com>
	<COL101-W30EE57E79AD843F646E8B4E6720@phx.gbl>
	<COL101-W22A7E87C9A16373E9679D9E6720@phx.gbl>
	<48A49161.1E75.00D7.1@scires.com>
Message-ID: <48A4D9C7.8030209@wichita.edu>

Randy Coleburn wrote:
> Jay:
>  
> There is the abstraction of multiple concurrent "readers" but only one 
> "writer".  I actually have such a module that I use sometimes in my 
> programs.  The idea is one of acquiring/releasing read locks and write 
> locks.  The difficulty here is in preventing starvation and usually 
> requires adherence to some rules (again rigor).  By starvation I mean 
> that writers must wait for all readers to finish before they get access, 
> so if there is always at least one reader, the writer will "starve" and 
> never gain access.
>  
> As for recursive locks, again that is usually indicative of a design 
> flaw.  I did once implement a system that permitted the same thread to 
> acquire a lock multiple times, provided that it eventually released the 
> lock the same number of times that it acquired it.  In other words, 
> after the first lock, subsequent locks by the same thread just increment 
> a counter.  Then, unlocks decrement the counter until it is zero with 
> the final unlock actually releasing the mutex.
>  
> In the code you modified, you could implement such a scheme to handle 
> the recursive locks, provided that at some point the thread releases for 
> each lock.  The Thread interface has the ability to note the current 
> thread (i.e., Thread.Self()).  So you could make a stack of locks by 
> same thread.  Other threads would have to block until the first thread's 
> lock stack was empty.
>  
> For example:
>  
> ACQUIRE:  If resource available, lock resource mutex and put current 
> thread on granted stack.  Otherwise, if current thread already on 
> granted stack, push it on stack again and let it proceed.  Otherwise 
> (this is a new thread wanting access), so push this thread onto a 
> waiting stack and wait.
>  
> RELEASE:  Pop granted stack and check to ensure the popped stack entry 
> represents the current thread.  If not, must crash due to a programming 
> error.  If granted stack is now empty, check to see if the waiting stack 
> is empty.  If the waiting stack is empty, release the resource mutex.  
> Otherwise (there is at least one thread waiting), pop waiting stack and 
> push onto granted stack.  Repeat pop/push for each occurrence of current 
> thread at top of waiting stack.  Allow waiting thread to proceed.
>  
> I can check into providing my read-write locks modules if needed.
>  
> Regards,
> Randy
> 


I have forgotten just where, but there are places in Trestle where it is
documented that, when your <whatever>-procedure is called, it is possible
that a certain MUTEX will sometimes already be held by the executing thread,
sometimes not.  If you need to access the data protected by that MUTEX,
you are just out of luck.  No matter what you do, it will be sometimes
wrong, sometimes not.  I don't remember the details, but I gave up trying
to find a way to do what I wanted to do.  I think it was very difficult,
even allowing modifications to Trestle.  This kind of lock scheme would
probably have solved this problem.


>  >>> Jay <jay.krell at cornell.edu> 8/14/2008 6:08 PM >>>
> 
> Maybe we should have another lock type that allows recursive acquires?
> To be used sparingly, but used here?
> I know that is often frowned upon -- the need for it implies a design 
> flaw -- but
> maybe it is ok sometimes?
> I don't understand when/why recursive locks are ok or not.
> 
> - Jay
> 
> 
> ________________________________
> 
> From: jay.krell at cornell.edu
> To: rcoleburn at scires.com; jkrell at elego.de; m3commit at elegosoft.com
> Date: Thu, 14 Aug 2008 22:05:13 +0000
> Subject: Re: [M3commit] CVS Update: cm3
> 
> 
> 
> 
> How about this comment in the code:
> 
> (*-------------------------------------------------- raw seething 
> windows ---*)
> (* NOTE: The helper procedures called by WindowProc lock VBT.mu when calling
>    various Trestle procedures.  They do not hold locks while calling Win32
>    because it knows nothing about Modula-3 locks and it can, on a whim, call
>    WindowProc to do something.  The only reason this scheme might work is
>    because we have a single Modula-3 thread that's pulling on the Win32
>    message queue and calling WindowProc.
> 
>    Similarly, we don't bother locking around updates to Child records.
>    They are updated by the single Modula-3/WindowProc thread.
> *)
> 
> ?
> I also need to check if any state has been modified, or cached in 
> locals, with
> the locks held that are being released.
> 
> -Jay
> 
> 
> 
> ________________________________
> 
> 
> Date: Thu, 14 Aug 2008 11:13:25 -0400
> From: rcoleburn at scires.com
> To: jkrell at elego.de; m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
> 
> 
> 
> Jay:
> 
> 
> 
> I haven't studied this code in depth, but on the surface I doubt your 
> change is "correct".
> 
> 
> 
> I think the more telling problem is that if you look at the body of 
> WinTrestle.Release, it is empty, save for a comment that it is not yet 
> implemented.  So, it would seem that if WinTrestle.Acquire is called 
> more than once, you will crash because the locks have not been released.
> 
> 
> 
> Further, I don't think it would make sense to release the locks before 
> calling out to Windows, and then reacquire them upon return.  The locks 
> are known to Modula-3 and not Windows.  Releasing them will allow other 
> competing threads to acquire them while you are in the Windows subsystem 
> and would seem to violate whatever protections were in place per holding 
> the locks.  Upon return from Windows, the thread will be back in 
> competition with others to reacquire the locks it gave up and upon 
> success, there is no guarantee that the other threads didn't disturb the 
> state the original thread depended upon.
> 
> 
> 
> I would suggest reverting these changes and looking to implement the 
> Release procedure.
> 
> 
> 
> Regards,
> 
> Randy
> 
> 
>  >>> Jay Krell  8/14/2008 4:26 PM>>>
> CVSROOT:/usr/cvs
> Changes by:jkrell at birch.08/08/14 16:26:59
> 
> Modified files:
> cm3/m3-ui/ui/src/winvbt/: WinTrestle.m3
> 
> Log message:
> release locks when calling out to Win32 to prevent recursive lock 
> acquisition. correct?
> 
> 
> 

-- 
-------------------------------------------------------------
Rodney M. Bates, retired assistant professor
Dept. of Computer Science, Wichita State University
Wichita, KS 67260-0083
316-978-3922
rodney.bates at wichita.edu


From jay.krell at cornell.edu  Fri Aug 15 08:27:17 2008
From: jay.krell at cornell.edu (Jay)
Date: Fri, 15 Aug 2008 06:27:17 +0000
Subject: [M3devel] Recursive locks
In-Reply-To: <48A4D9C7.8030209@wichita.edu>
References: <20080814142659.91A4A10D4F35@birch.elegosoft.com>
	<48A4134F.1E75.00D7.1@scires.com>
	<COL101-W30EE57E79AD843F646E8B4E6720@phx.gbl>
	<COL101-W22A7E87C9A16373E9679D9E6720@phx.gbl>
	<48A49161.1E75.00D7.1@scires.com>  <48A4D9C7.8030209@wichita.edu>
Message-ID: <COL101-W769E513D93D5D95A0F5D6BE66D0@phx.gbl>


Btw, notice that the comment I quoted is NOT true, prior to my change.
It claims we don't hold locks when we call out to Win32, but we do.
 
I vaguely know that releasing and reacquiring locks is or can be dangerous..
But, it depends, right?
It depends on if the locked data has been used yet, and if it is assumed to be
unchanged from the use before the release to uses after the reacquire, right?
 
I believe:
  Handling messages in Win32 possibly causes reentrance  -- called while already "in the middle" of doing something.
  Trestle, at least in parts, is perhaps not "designed" to handle that.
     That is, it does a lot of long term locking.
 
I tried to consider if the work here can be deferred, but it seems like it is exactly meant to occur in this order. I'll have dig more..sometimes...
 
 - Jay> Date: Thu, 14 Aug 2008 20:20:07 -0500> From: rodney.bates at wichita.edu> To: m3devel at elegosoft.com> Subject: [M3devel] Recursive locks> > Randy Coleburn wrote:> > Jay:> > > > There is the abstraction of multiple concurrent "readers" but only one > > "writer". I actually have such a module that I use sometimes in my > > programs. The idea is one of acquiring/releasing read locks and write > > locks. The difficulty here is in preventing starvation and usually > > requires adherence to some rules (again rigor). By starvation I mean > > that writers must wait for all readers to finish before they get access, > > so if there is always at least one reader, the writer will "starve" and > > never gain access.> > > > As for recursive locks, again that is usually indicative of a design > > flaw. I did once implement a system that permitted the same thread to > > acquire a lock multiple times, provided that it eventually released the > > lock the same number of times that it acquired it. In other words, > > after the first lock, subsequent locks by the same thread just increment > > a counter. Then, unlocks decrement the counter until it is zero with > > the final unlock actually releasing the mutex.> > > > In the code you modified, you could implement such a scheme to handle > > the recursive locks, provided that at some point the thread releases for > > each lock. The Thread interface has the ability to note the current > > thread (i.e., Thread.Self()). So you could make a stack of locks by > > same thread. Other threads would have to block until the first thread's > > lock stack was empty.> > > > For example:> > > > ACQUIRE: If resource available, lock resource mutex and put current > > thread on granted stack. Otherwise, if current thread already on > > granted stack, push it on stack again and let it proceed. Otherwise > > (this is a new thread wanting access), so push this thread onto a > > waiting stack and wait.> > > > RELEASE: Pop granted stack and check to ensure the popped stack entry > > represents the current thread. If not, must crash due to a programming > > error. If granted stack is now empty, check to see if the waiting stack > > is empty. If the waiting stack is empty, release the resource mutex. > > Otherwise (there is at least one thread waiting), pop waiting stack and > > push onto granted stack. Repeat pop/push for each occurrence of current > > thread at top of waiting stack. Allow waiting thread to proceed.> > > > I can check into providing my read-write locks modules if needed.> > > > Regards,> > Randy> > > > > I have forgotten just where, but there are places in Trestle where it is> documented that, when your <whatever>-procedure is called, it is possible> that a certain MUTEX will sometimes already be held by the executing thread,> sometimes not. If you need to access the data protected by that MUTEX,> you are just out of luck. No matter what you do, it will be sometimes> wrong, sometimes not. I don't remember the details, but I gave up trying> to find a way to do what I wanted to do. I think it was very difficult,> even allowing modifications to Trestle. This kind of lock scheme would> probably have solved this problem.> > > > >>> Jay <jay.krell at cornell.edu> 8/14/2008 6:08 PM >>>> > > > Maybe we should have another lock type that allows recursive acquires?> > To be used sparingly, but used here?> > I know that is often frowned upon -- the need for it implies a design > > flaw -- but> > maybe it is ok sometimes?> > I don't understand when/why recursive locks are ok or not.> > > > - Jay> > > > > > ________________________________> > > > From: jay.krell at cornell.edu> > To: rcoleburn at scires.com; jkrell at elego.de; m3commit at elegosoft.com> > Date: Thu, 14 Aug 2008 22:05:13 +0000> > Subject: Re: [M3commit] CVS Update: cm3> > > > > > > > > > How about this comment in the code:> > > > (*-------------------------------------------------- raw seething > > windows ---*)> > (* NOTE: The helper procedures called by WindowProc lock VBT.mu when calling> > various Trestle procedures. They do not hold locks while calling Win32> > because it knows nothing about Modula-3 locks and it can, on a whim, call> > WindowProc to do something. The only reason this scheme might work is> > because we have a single Modula-3 thread that's pulling on the Win32> > message queue and calling WindowProc.> > > > Similarly, we don't bother locking around updates to Child records.> > They are updated by the single Modula-3/WindowProc thread.> > *)> > > > ?> > I also need to check if any state has been modified, or cached in > > locals, with> > the locks held that are being released.> > > > -Jay> > > > > > > > ________________________________> > > > > > Date: Thu, 14 Aug 2008 11:13:25 -0400> > From: rcoleburn at scires.com> > To: jkrell at elego.de; m3commit at elegosoft.com> > Subject: Re: [M3commit] CVS Update: cm3> > > > > > > > Jay:> > > > > > > > I haven't studied this code in depth, but on the surface I doubt your > > change is "correct".> > > > > > > > I think the more telling problem is that if you look at the body of > > WinTrestle.Release, it is empty, save for a comment that it is not yet > > implemented. So, it would seem that if WinTrestle.Acquire is called > > more than once, you will crash because the locks have not been released.> > > > > > > > Further, I don't think it would make sense to release the locks before > > calling out to Windows, and then reacquire them upon return. The locks > > are known to Modula-3 and not Windows. Releasing them will allow other > > competing threads to acquire them while you are in the Windows subsystem > > and would seem to violate whatever protections were in place per holding > > the locks. Upon return from Windows, the thread will be back in > > competition with others to reacquire the locks it gave up and upon > > success, there is no guarantee that the other threads didn't disturb the > > state the original thread depended upon.> > > > > > > > I would suggest reverting these changes and looking to implement the > > Release procedure.> > > > > > > > Regards,> > > > Randy> > > > > > >>> Jay Krell 8/14/2008 4:26 PM>>>> > CVSROOT:/usr/cvs> > Changes by:jkrell at birch.08/08/14 16:26:59> > > > Modified files:> > cm3/m3-ui/ui/src/winvbt/: WinTrestle.m3> > > > Log message:> > release locks when calling out to Win32 to prevent recursive lock > > acquisition. correct?> > > > > > > > -- > -------------------------------------------------------------> Rodney M. Bates, retired assistant professor> Dept. of Computer Science, Wichita State University> Wichita, KS 67260-0083> 316-978-3922> rodney.bates at wichita.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080815/2369c19c/attachment.html>

From rcoleburn at scires.com  Tue Aug 19 22:55:00 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Tue, 19 Aug 2008 16:55:00 -0400
Subject: [M3devel] pixmaps et al on Win32 hi-res monitors
Message-ID: <48AAFADE.1E75.00D7.1@scires.com>

Jay, Sorry for the delay in getting back to you.
 
I ran tests as you suggested, namely, in WinScreenType.InnerNew I changed the x & y resolution to be 96.0 (I did not change the pixels,  just the res field).  I tried running this version with Image.Raw.x/yres set to 75.0 and also set to 96.0.  In both cases, what I got on the screen was horrid.  Everything was extremely large and only a fraction of the window was visible on screen (e.g., shadow size on buttons appeared to be increased by a factor of 7 or more).
 
So, here is where I stand:
 
1.  It seems that for certain high-dpi monitors (Dell M4300 laptop is only one I've tested), if you use unscaled pixmaps in FormsVBT/Trestle, the ZGrowVBT stops working for ZChassisVBT.  You can still grab the title and try to drag.  The system will put an outline around the window, but it won't let you drag it anywhere.
 
2.  I have put an environment variable in my programs that lets you choose between scaled and unscaled pixmaps.  For either case, the program seems to work fine on "normal dpi" monitors, but when run on the Dell M4300 hi-res system, you get the following behavior:  
 
Unscaled=subwindows can't be dragged around (moved), but the GUI looks good; 
 
Scaled=subwindow dragging works as expected, but all pixmaps are double-size resulting in bad appearance (pixmaps are out of proportion with text and cause some subwindows to be too big to fit on screen).  
 
So, the end user gets to decide via environment variable whether he wants a pretty GUI with frozen subwindows, or an ugly GUI with movable subwindows.  Alas, the choices are poor, at best.
 
3.  At this point I don't know of anything else to try as a potential solution to this problem.
 
4.  I am running final tests today & tomorrow at the customer location.  We will meet tomorrow (Wednesday) afternoon to decide if customer will accept the program.
 
If anyone has any other ideas for a solution, please let me know ASAP.
 
I plan to commit my changes to the repository as soon as the final decision on acceptance is rendered.  These changes will not alter the way Trestle/FormsVBT has been working on Windows, except to fix the appearance of scaled scroll bars and to add the capability to force use of unscaled pixmaps.  The latter is not done thru env var, but via a new procedure in Image.i3.  (One could use an env var in one's program, like I did, to provide a control input to the new procedure.)  Unless one calls the new procedure, the default is to use scaled pixmaps so as to maintain compatibility with the way its been done in the past, thus there is no change in operation unless explicitly called for by the programmer.
 
Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080819/8d2b858f/attachment.html>

From jay.krell at cornell.edu  Tue Aug 19 23:23:52 2008
From: jay.krell at cornell.edu (Jay)
Date: Tue, 19 Aug 2008 21:23:52 +0000
Subject: [M3devel] pixmaps et al on Win32 hi-res monitors
In-Reply-To: <48AAFADE.1E75.00D7.1@scires.com>
References: <48AAFADE.1E75.00D7.1@scires.com>
Message-ID: <COL101-W685AD60FBE2EC60E5831C6E6690@phx.gbl>


Randy this is all unfortunate. I really wish I had this configuration locally to try out. :(
If you or your customer can send me one....I make no promises. :)
(It is not a cheap machine. It is a "high end" laptop ("high end" means "arbitrarily inflated price"), starts at $1400, and is not well configured at that price. You can get a much better Dell Vostro or Inspiron for half the price.)
 
"I kinda thunk" 96 and 75 or 96 and 96, would lead to "correcly unscaled pixmaps".
I need to read the code more..these must have had other affects.
 
Be sure your customer knows it works fine on most machines/configurations.
Try to get your customer to believe we might yet fix it. 
  However, granted, confidence in the overall system will still suffer.
And if you can get them to send me one..just to borrow...probably not a good move in a "professional environment", use your judgement.
 
Sorry,
 - Jay



Date: Tue, 19 Aug 2008 16:55:00 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: pixmaps et al on Win32 hi-res monitors

Jay, Sorry for the delay in getting back to you.
 
I ran tests as you suggested, namely, in WinScreenType.InnerNew I changed the x & y resolution to be 96.0 (I did not change the pixels,  just the res field).  I tried running this version with Image.Raw.x/yres set to 75.0 and also set to 96.0.  In both cases, what I got on the screen was horrid.  Everything was extremely large and only a fraction of the window was visible on screen (e.g., shadow size on buttons appeared to be increased by a factor of 7 or more).
 
So, here is where I stand:
 
1.  It seems that for certain high-dpi monitors (Dell M4300 laptop is only one I've tested), if you use unscaled pixmaps in FormsVBT/Trestle, the ZGrowVBT stops working for ZChassisVBT.  You can still grab the title and try to drag.  The system will put an outline around the window, but it won't let you drag it anywhere.
 
2.  I have put an environment variable in my programs that lets you choose between scaled and unscaled pixmaps.  For either case, the program seems to work fine on "normal dpi" monitors, but when run on the Dell M4300 hi-res system, you get the following behavior:  
 
Unscaled=subwindows can't be dragged around (moved), but the GUI looks good; 
 
Scaled=subwindow dragging works as expected, but all pixmaps are double-size resulting in bad appearance (pixmaps are out of proportion with text and cause some subwindows to be too big to fit on screen).  
 
So, the end user gets to decide via environment variable whether he wants a pretty GUI with frozen subwindows, or an ugly GUI with movable subwindows.  Alas, the choices are poor, at best.
 
3.  At this point I don't know of anything else to try as a potential solution to this problem.
 
4.  I am running final tests today & tomorrow at the customer location.  We will meet tomorrow (Wednesday) afternoon to decide if customer will accept the program.
 
If anyone has any other ideas for a solution, please let me know ASAP.
 
I plan to commit my changes to the repository as soon as the final decision on acceptance is rendered.  These changes will not alter the way Trestle/FormsVBT has been working on Windows, except to fix the appearance of scaled scroll bars and to add the capability to force use of unscaled pixmaps.  The latter is not done thru env var, but via a new procedure in Image.i3.  (One could use an env var in one's program, like I did, to provide a control input to the new procedure.)  Unless one calls the new procedure, the default is to use scaled pixmaps so as to maintain compatibility with the way its been done in the past, thus there is no change in operation unless explicitly called for by the programmer.
 
Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080819/9c2d9618/attachment.html>

From rcoleburn at scires.com  Wed Aug 20 01:46:35 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Tue, 19 Aug 2008 19:46:35 -0400
Subject: [M3devel] pixmaps et al on Win32 hi-res monitors
In-Reply-To: <COL101-W685AD60FBE2EC60E5831C6E6690@phx.gbl>
References: <48AAFADE.1E75.00D7.1@scires.com>
	<COL101-W685AD60FBE2EC60E5831C6E6690@phx.gbl>
Message-ID: <48AB2313.1E75.00D7.1@scires.com>

Jay:
 
Thanks.  I probably can't arrange to send you one of these computers, but I might be able to set up a way for you to remotely access it.
 
Regards,
Randy

>>> Jay <jay.krell at cornell.edu> 8/19/2008 5:23 PM >>>
Randy this is all unfortunate. I really wish I had this configuration locally to try out. :(
If you or your customer can send me one....I make no promises. :)
(It is not a cheap machine. It is a "high end" laptop ("high end" means "arbitrarily inflated price"), starts at $1400, and is not well configured at that price. You can get a much better Dell Vostro or Inspiron for half the price.)
 
"I kinda thunk" 96 and 75 or 96 and 96, would lead to "correcly unscaled pixmaps".
I need to read the code more..these must have had other affects.
 
Be sure your customer knows it works fine on most machines/configurations.
Try to get your customer to believe we might yet fix it. 
  However, granted, confidence in the overall system will still suffer.
And if you can get them to send me one..just to borrow...probably not a good move in a "professional environment", use your judgement.
 
Sorry,
 - Jay



Date: Tue, 19 Aug 2008 16:55:00 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com; jayk123 at hotmail.com 
Subject: pixmaps et al on Win32 hi-res monitors


Jay, Sorry for the delay in getting back to you.
 
I ran tests as you suggested, namely, in WinScreenType.InnerNew I changed the x & y resolution to be 96.0 (I did not change the pixels,  just the res field).  I tried running this version with Image.Raw.x/yres set to 75.0 and also set to 96.0.  In both cases, what I got on the screen was horrid.  Everything was extremely large and only a fraction of the window was visible on screen (e.g., shadow size on buttons appeared to be increased by a factor of 7 or more).
 
So, here is where I stand:
 
1.  It seems that for certain high-dpi monitors (Dell M4300 laptop is only one I've tested), if you use unscaled pixmaps in FormsVBT/Trestle, the ZGrowVBT stops working for ZChassisVBT.  You can still grab the title and try to drag.  The system will put an outline around the window, but it won't let you drag it anywhere.
 
2.  I have put an environment variable in my programs that lets you choose between scaled and unscaled pixmaps.  For either case, the program seems to work fine on "normal dpi" monitors, but when run on the Dell M4300 hi-res system, you get the following behavior:  
 
Unscaled=subwindows can't be dragged around (moved), but the GUI looks good; 
 
Scaled=subwindow dragging works as expected, but all pixmaps are double-size resulting in bad appearance (pixmaps are out of proportion with text and cause some subwindows to be too big to fit on screen).  
 
So, the end user gets to decide via environment variable whether he wants a pretty GUI with frozen subwindows, or an ugly GUI with movable subwindows.  Alas, the choices are poor, at best.
 
3.  At this point I don't know of anything else to try as a potential solution to this problem.
 
4.  I am running final tests today & tomorrow at the customer location.  We will meet tomorrow (Wednesday) afternoon to decide if customer will accept the program.
 
If anyone has any other ideas for a solution, please let me know ASAP.
 
I plan to commit my changes to the repository as soon as the final decision on acceptance is rendered.  These changes will not alter the way Trestle/FormsVBT has been working on Windows, except to fix the appearance of scaled scroll bars and to add the capability to force use of unscaled pixmaps.  The latter is not done thru env var, but via a new procedure in Image.i3.  (One could use an env var in one's program, like I did, to provide a control input to the new procedure.)  Unless one calls the new procedure, the default is to use scaled pixmaps so as to maintain compatibility with the way its been done in the past, thus there is no change in operation unless explicitly called for by the programmer.
 
Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080819/02e9be3e/attachment.html>

From jay.krell at cornell.edu  Thu Aug 21 13:00:43 2008
From: jay.krell at cornell.edu (Jay)
Date: Thu, 21 Aug 2008 11:00:43 +0000
Subject: [M3devel] pixmaps et al on Win32 hi-res monitors
In-Reply-To: <48AB2313.1E75.00D7.1@scires.com>
References: <48AAFADE.1E75.00D7.1@scires.com>
	<COL101-W685AD60FBE2EC60E5831C6E6690@phx.gbl> 
	<48AB2313.1E75.00D7.1@scires.com>
Message-ID: <COL101-W44C26F20E9DF8DF3815DAEE66B0@phx.gbl>


Randy, in case anyone splurges on one of these..

Can you go to Dell.com.
Support.
Type in the asset tag. I think they are on small
barcode stickers on the bottom.

Tell us which screen type this as?
  15.4 IN WIDE WUXGA Anti-Glare LCD Panel
  15.4 inch Wide Screen WSXGA+ TrueLife LCD Panel
  15.4 inch Wide Screen WXGA Anti-Glare LCD Panel
(These are the current options when buying this;
could be there were others in the past. Totally unknown.
Should be easy to map the alphabet soup of *GA to resolutions,
but I don't know.)

Could be also you can simulate this with a simple setting.
I'll try when I get home.
You have a small app that demonstrates the problem?

Hm..

http://en.wikipedia.org/wiki/WSXGA
http://www.pcmag.com/encyclopedia_term/0,2542,t=WSXGA&i=54916,00.asp

 - Jay

________________________________
> Date: Tue, 19 Aug 2008 19:46:35 -0400
> From: rcoleburn at scires.com
> To: jay.krell at cornell.edu; m3devel at elegosoft.com
> Subject: Re: [M3devel] pixmaps et al on Win32 hi-res monitors
> 
> Jay:
> 
> Thanks.  I probably can't arrange to send you one of these computers, but I might be able to set up a way for you to remotely access it.
> 
> Regards,
> Randy
> 
>>>> Jay  8/19/2008 5:23 PM>>>
> Randy this is all unfortunate. I really wish I had this configuration locally to try out. :(
> If you or your customer can send me one....I make no promises. :)
> (It is not a cheap machine. It is a "high end" laptop ("high end" means "arbitrarily inflated price"), starts at $1400, and is not well configured at that price. You can get a much better Dell Vostro or Inspiron for half the price.)
> 
> "I kinda thunk" 96 and 75 or 96 and 96, would lead to "correcly unscaled pixmaps".
> I need to read the code more..these must have had other affects.
> 
> Be sure your customer knows it works fine on most machines/configurations.
> Try to get your customer to believe we might yet fix it.
>   However, granted, confidence in the overall system will still suffer.
> And if you can get them to send me one..just to borrow...probably not a good move in a "professional environment", use your judgement.
> 
> Sorry,
>  - Jay
> 
> 
> ________________________________
> 
> Date: Tue, 19 Aug 2008 16:55:00 -0400
> From: rcoleburn at scires.com
> To: m3devel at elegosoft.com; jayk123 at hotmail.com
> Subject: pixmaps et al on Win32 hi-res monitors
> 
> 
> Jay, Sorry for the delay in getting back to you.
> 
> I ran tests as you suggested, namely, in WinScreenType.InnerNew I changed the x & y resolution to be 96.0 (I did not change the pixels,  just the res field).  I tried running this version with Image.Raw.x/yres set to 75.0 and also set to 96.0.  In both cases, what I got on the screen was horrid.  Everything was extremely large and only a fraction of the window was visible on screen (e.g., shadow size on buttons appeared to be increased by a factor of 7 or more).
> 
> So, here is where I stand:
> 
> 1.  It seems that for certain high-dpi monitors (Dell M4300 laptop is only one I've tested), if you use unscaled pixmaps in FormsVBT/Trestle, the ZGrowVBT stops working for ZChassisVBT.  You can still grab the title and try to drag.  The system will put an outline around the window, but it won't let you drag it anywhere.
> 
> 2.  I have put an environment variable in my programs that lets you choose between scaled and unscaled pixmaps.  For either case, the program seems to work fine on "normal dpi" monitors, but when run on the Dell M4300 hi-res system, you get the following behavior:
> 
> Unscaled=subwindows can't be dragged around (moved), but the GUI looks good;
> 
> Scaled=subwindow dragging works as expected, but all pixmaps are double-size resulting in bad appearance (pixmaps are out of proportion with text and cause some subwindows to be too big to fit on screen).
> 
> So, the end user gets to decide via environment variable whether he wants a pretty GUI with frozen subwindows, or an ugly GUI with movable subwindows.  Alas, the choices are poor, at best.
> 
> 3.  At this point I don't know of anything else to try as a potential solution to this problem.
> 
> 4.  I am running final tests today & tomorrow at the customer location.  We will meet tomorrow (Wednesday) afternoon to decide if customer will accept the program.
> 
> If anyone has any other ideas for a solution, please let me know ASAP.
> 
> I plan to commit my changes to the repository as soon as the final decision on acceptance is rendered.  These changes will not alter the way Trestle/FormsVBT has been working on Windows, except to fix the appearance of scaled scroll bars and to add the capability to force use of unscaled pixmaps.  The latter is not done thru env var, but via a new procedure in Image.i3.  (One could use an env var in one's program, like I did, to provide a control input to the new procedure.)  Unless one calls the new procedure, the default is to use scaled pixmaps so as to maintain compatibility with the way its been done in the past, thus there is no change in operation unless explicitly called for by the programmer.
> 
> Regards,
> Randy


From rcoleburn at scires.com  Thu Aug 21 14:20:01 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Thu, 21 Aug 2008 08:20:01 -0400
Subject: [M3devel] pixmaps et al on Win32 hi-res monitors
In-Reply-To: <COL101-W44C26F20E9DF8DF3815DAEE66B0@phx.gbl>
References: <48AAFADE.1E75.00D7.1@scires.com>
	<COL101-W685AD60FBE2EC60E5831C6E6690@phx.gbl>
	<48AB2313.1E75.00D7.1@scires.com>
	<COL101-W44C26F20E9DF8DF3815DAEE66B0@phx.gbl>
Message-ID: <48AD2527.1E75.00D7.1@scires.com>

Jay:
 
I wouldn't "splurge" on this unless someone just wants one of them.
 
Based on the URLs you sent, the Dell M4300 display is a WUXGA, 16:10, 1920x1200.  See http://en.wikipedia.org/wiki/WUXGA 
 
I'm heading to the airport now, so I'll have to get the asset tag for you when I get back to Atlanta.
 
BTW, the customer is impressed with the speed with which I was able to provide the new software.  I owe this credit to Modula-3.  The customer is also impressed with the software, esp. the use of multi-threading and the ability to target multiple platforms simply by recompiling.  Again, credit Modula-3.  Using my env var hack, I was able to show the customer correct appearance of the GUI, at the expense of sub-window movement, so the customer believes I should be able to eventually solve the problem.  Therefore, the customer has agreed to take delivery of the software with the proviso that I continue to work to solve the problem.  So, it looks like I have some more time to work toward a solution.
 
FYI:  My software is used to control and monitor a satellite multi-receiver system.  This system receives and processes tactical data for display and action by the operator and other automated systems.  I can't be more specific because the application is used by the military.  Indeed, the reason for the hard delivery deadline is to meet a deadline for flight testing aboard a new military aircraft.
 
When I get back to Atlanta, I'll try to put together some screen captures of the GUI (minus any tactical info) and provide them in a PDF so you can see some of the windows.  I may be able to put together a small program that demonstrates the problem I'm having.  I won't be able to release the source code, but I should be able to provide a standalone EXE file.
 
Regards,
Randy

>>> Jay <jay.krell at cornell.edu> 8/21/2008 7:00 AM >>>

Randy, in case anyone splurges on one of these..

Can you go to Dell.com.
Support.
Type in the asset tag. I think they are on small
barcode stickers on the bottom.

Tell us which screen type this as?
  15.4 IN WIDE WUXGA Anti-Glare LCD Panel
  15.4 inch Wide Screen WSXGA+ TrueLife LCD Panel
  15.4 inch Wide Screen WXGA Anti-Glare LCD Panel
(These are the current options when buying this;
could be there were others in the past. Totally unknown.
Should be easy to map the alphabet soup of *GA to resolutions,
but I don't know.)

Could be also you can simulate this with a simple setting.
I'll try when I get home.
You have a small app that demonstrates the problem?

Hm..

http://en.wikipedia.org/wiki/WSXGA 
http://www.pcmag.com/encyclopedia_term/0,2542,t=WSXGA&i=54916,00.asp 

- Jay

________________________________
> Date: Tue, 19 Aug 2008 19:46:35 -0400
> From: rcoleburn at scires.com 
> To: jay.krell at cornell.edu; m3devel at elegosoft.com 
> Subject: Re: [M3devel] pixmaps et al on Win32 hi-res monitors
> 
> Jay:
> 
> Thanks.  I probably can't arrange to send you one of these computers, but I might be able to set up a way for you to remotely access it.
> 
> Regards,
> Randy
> 
>>>> Jay  8/19/2008 5:23 PM>>>
> Randy this is all unfortunate. I really wish I had this configuration locally to try out. :(
> If you or your customer can send me one....I make no promises. :)
> (It is not a cheap machine. It is a "high end" laptop ("high end" means "arbitrarily inflated price"), starts at $1400, and is not well configured at that price. You can get a much better Dell Vostro or Inspiron for half the price.)
> 
> "I kinda thunk" 96 and 75 or 96 and 96, would lead to "correcly unscaled pixmaps".
> I need to read the code more..these must have had other affects.
> 
> Be sure your customer knows it works fine on most machines/configurations.
> Try to get your customer to believe we might yet fix it.
>   However, granted, confidence in the overall system will still suffer.
> And if you can get them to send me one..just to borrow...probably not a good move in a "professional environment", use your judgement.
> 
> Sorry,
>  - Jay
> 
> 
> ________________________________
> 
> Date: Tue, 19 Aug 2008 16:55:00 -0400
> From: rcoleburn at scires.com 
> To: m3devel at elegosoft.com; jayk123 at hotmail.com 
> Subject: pixmaps et al on Win32 hi-res monitors
> 
> 
> Jay, Sorry for the delay in getting back to you.
> 
> I ran tests as you suggested, namely, in WinScreenType.InnerNew I changed the x & y resolution to be 96.0 (I did not change the pixels,  just the res field).  I tried running this version with Image.Raw.x/yres set to 75.0 and also set to 96.0.  In both cases, what I got on the screen was horrid.  Everything was extremely large and only a fraction of the window was visible on screen (e.g., shadow size on buttons appeared to be increased by a factor of 7 or more).
> 
> So, here is where I stand:
> 
> 1.  It seems that for certain high-dpi monitors (Dell M4300 laptop is only one I've tested), if you use unscaled pixmaps in FormsVBT/Trestle, the ZGrowVBT stops working for ZChassisVBT.  You can still grab the title and try to drag.  The system will put an outline around the window, but it won't let you drag it anywhere.
> 
> 2.  I have put an environment variable in my programs that lets you choose between scaled and unscaled pixmaps.  For either case, the program seems to work fine on "normal dpi" monitors, but when run on the Dell M4300 hi-res system, you get the following behavior:
> 
> Unscaled=subwindows can't be dragged around (moved), but the GUI looks good;
> 
> Scaled=subwindow dragging works as expected, but all pixmaps are double-size resulting in bad appearance (pixmaps are out of proportion with text and cause some subwindows to be too big to fit on screen).
> 
> So, the end user gets to decide via environment variable whether he wants a pretty GUI with frozen subwindows, or an ugly GUI with movable subwindows.  Alas, the choices are poor, at best.
> 
> 3.  At this point I don't know of anything else to try as a potential solution to this problem.
> 
> 4.  I am running final tests today & tomorrow at the customer location.  We will meet tomorrow (Wednesday) afternoon to decide if customer will accept the program.
> 
> If anyone has any other ideas for a solution, please let me know ASAP.
> 
> I plan to commit my changes to the repository as soon as the final decision on acceptance is rendered.  These changes will not alter the way Trestle/FormsVBT has been working on Windows, except to fix the appearance of scaled scroll bars and to add the capability to force use of unscaled pixmaps.  The latter is not done thru env var, but via a new procedure in Image.i3.  (One could use an env var in one's program, like I did, to provide a control input to the new procedure.)  Unless one calls the new procedure, the default is to use scaled pixmaps so as to maintain compatibility with the way its been done in the past, thus there is no change in operation unless explicitly called for by the programmer.
> 
> Regards,
> Randy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080821/7218998f/attachment.html>

From dabenavidesd at yahoo.es  Fri Aug  1 00:43:07 2008
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Thu, 31 Jul 2008 22:43:07 +0000 (GMT)
Subject: [M3devel] need help with cm3 problem before I deliver software
	this week
In-Reply-To: <4891A737.1E75.00D7.1@scires.com>
Message-ID: <537778.13498.qm@web27107.mail.ukl.yahoo.com>

Hi all:
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.
Thanks

--- El jue, 31/7/08, Randy Coleburn <rcoleburn at scires.com> escribi?:
De: Randy Coleburn <rcoleburn at scires.com>
Asunto: Re: [M3devel] need help with cm3 problem before I deliver software this week
Para: "Rodney M. Bates" <rodney.bates at wichita.edu>
CC: m3devel at elegosoft.com
Fecha: jueves, 31 julio, 2008 10:51


 
Rodney:
?
I am using Windows XP Professional, Service Pack 2 (on some systems, Service Pack 3 is applied).
?
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?
?
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.
?
Regards,
Randy

>>> "Rodney M. Bates" <rodney.bates at wichita.edu> 7/31/2008 9:33 AM >>>
Which variant of the M3 Windows target are you using?? I don't have any
of them built right now.

Randy Coleburn wrote:
> Hi Olaf, Daniel, Rodney, et al:
>? 
> Thanks for your responses so far.? Sorry for the delay in replying, but 
> our email server has been offline for nearly 24-hours.? There were some 
> severe electrical storms that took down both redundant power systems for 
> our email system.? Hope I have not missed any of your replies.
>? 
> Right now, I am delivering the software on Windows XP using SP2 or 
> greater.? I have not tried to see if this problem also occurs on Unix.? 
> I don't have ready access to a unix system from my current location.
>? 
> So it is perhaps a Windows-only problem with Trestle/FormsVBT.? In any 
> event, it is a real problem for me.
>? 
> As for the pixmap stretching problem, I have tested various resolutions 
> on the customer's computer.? Unfortunately, the customer demands that 
> the display resolution stay at the 1920x1200.
> 1920x1200=pixmap stretch problem
> 1680x1050=pixmap stretch problem
> 1440x900=no problem
> 1024x768=no problem
>? 
> Regards,
> Randy
> 
>? >>> Olaf Wagner <wagner at elegosoft.com> 7/30/2008 2:24 AM >>>
> Quoting Randy Coleburn <rcoleburn at scires.com>:
> 
>? > Hi:
>? >
>? > 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.
>? >
>? > This problem is easily reproduced using the "formsedit" program.
>? >
>? > The problem is with the TypeIn and TypeScript FormsVBT elements used 
>? >? in my program.? Since formsedit uses these, you can easily 
>? > reproduce? the problem.
>? >
>? > 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.
> 
> Randy,
> 
> I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't able
> to reproduce the problem on FreeBSD 6.3.
> 
> Does the problem show up on all platforms you are working on?
> Which are these?
> 
> Are there any local modifications to the libraries which I may not
> have?
> 
> If it occurs only on Unix, it may be possible that a weird window
> manager interferes with the event delivery; otherwise I've got no
> good idea. If on Unix, you/we could perhaps test the behaviour
> on a different (remote) X display?
> 
> Please provide more data about the problem context and how to
> reproduce it.
> 
> Regards,
> 
> Olaf
> 
>? > 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).
>? >
>? > 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#.
>? >
>? > 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.
>? >
>? > Regards,
>? > Randy Coleburn
>? > Senior Systems Engineer
>? > Scientific Research Corporation
>? >
> 
> 
> 
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>???????????????? Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96? mobile: +49 177 2345 869? fax: +49 30 23 45 86 95
>???? http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 
> 

-- 
-------------------------------------------------------------
Rodney M. Bates, retired assistant professor
Dept. of Computer Science, Wichita State University
Wichita, KS 67260-0083
316-978-3922
rodney.bates at wichita.edu




      ______________________________________________ 
Enviado desde Correo Yahoo! La bandeja de entrada m?s inteligente.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080731/87ed8ad9/attachment-0001.html>

From jayk123 at hotmail.com  Fri Aug  1 00:52:51 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 31 Jul 2008 22:52:51 +0000
Subject: [M3devel] need help with cm3 problem before I
	deliver	software	this	week
In-Reply-To: <4891A737.1E75.00D7.1@scires.com>
References: <488F4292.1E75.00D7.1@scires.com>
	<20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com>
	<4890EB9C.1E75.00D7.1@scires.com> <4891BF18.8000905@wichita.edu> 
	<4891A737.1E75.00D7.1@scires.com>
Message-ID: <COL101-W53603D6A9F25219F7DF8C2E67C0@phx.gbl>


You reminded me -- there is something in the code about double reporting of characters and ignoring the first one.
It is, like the main/environment stuff, one of those suspicious changes that crept in  -- a change with a comment indicating the changer didn't know what is going on, and overridable with environment variable/command line switch. But I had less luck resolving this than with main/environment.
Does it repro with 4.1? Or 3.6?
I haven't tried yet but will shortly.
Been on gcc related tangents since I got a sparc/Solaris machine, sorry.
 
 - Jay



Date: Thu, 31 Jul 2008 11:51:28 -0400From: rcoleburn at scires.comTo: rodney.bates at wichita.eduCC: m3devel at elegosoft.comSubject: Re: [M3devel] need help with cm3 problem before I deliver software this week

Rodney:
 
I am using Windows XP Professional, Service Pack 2 (on some systems, Service Pack 3 is applied).
 
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?
 
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.
 
Regards,
Randy>>> "Rodney M. Bates" <rodney.bates at wichita.edu> 7/31/2008 9:33 AM >>>Which variant of the M3 Windows target are you using?  I don't have anyof them built right now.Randy Coleburn wrote:> Hi Olaf, Daniel, Rodney, et al:>  > Thanks for your responses so far.  Sorry for the delay in replying, but > our email server has been offline for nearly 24-hours.  There were some > severe electrical storms that took down both redundant power systems for > our email system.  Hope I have not missed any of your replies.>  > Right now, I am delivering the software on Windows XP using SP2 or > greater.  I have not tried to see if this problem also occurs on Unix.  > I don't have ready access to a unix system from my current location.>  > So it is perhaps a Windows-only problem with Trestle/FormsVBT.  In any > event, it is a real problem for me.>  > As for the pixmap stretching problem, I have tested various resolutions > on the customer's computer.  Unfortunately, the customer demands that > the display resolution stay at the 1920x1200.> 1920x1200=pixmap stretch problem> 1680x1050=pixmap stretch problem> 1440x900=no problem> 1024x768=no problem>  > Regards,> Randy> >  >>> Olaf Wagner <wagner at elegosoft.com> 7/30/2008 2:24 AM >>>> Quoting Randy Coleburn <rcoleburn at scires.com>:> >  > Hi:>  >>  > 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.>  >>  > This problem is easily reproduced using the "formsedit" program.>  >>  > The problem is with the TypeIn and TypeScript FormsVBT elements used >  >  in my program.  Since formsedit uses these, you can easily >  > reproduce  the problem.>  >>  > 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.> > Randy,> > I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't able> to reproduce the problem on FreeBSD 6.3.> > Does the problem show up on all platforms you are working on?> Which are these?> > Are there any local modifications to the libraries which I may not> have?> > If it occurs only on Unix, it may be possible that a weird window> manager interferes with the event delivery; otherwise I've got no> good idea. If on Unix, you/we could perhaps test the behaviour> on a different (remote) X display?> > Please provide more data about the problem context and how to> reproduce it.> > Regards,> > Olaf> >  > 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).>  >>  > 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#.>  >>  > 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.>  >>  > Regards,>  > Randy Coleburn>  > Senior Systems Engineer>  > Scientific Research Corporation>  >> > > > -- > Olaf Wagner -- elego Software Solutions GmbH>                 Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95>     http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> > -- -------------------------------------------------------------Rodney M. Bates, retired assistant professorDept. of Computer Science, Wichita State UniversityWichita, KS 67260-0083316-978-3922rodney.bates at wichita.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080731/3ccb6074/attachment-0001.html>

From dabenavidesd at yahoo.es  Fri Aug  1 01:16:05 2008
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Thu, 31 Jul 2008 23:16:05 +0000 (GMT)
Subject: [M3devel] need help with cm3 problem before I deliver software
	this week
In-Reply-To: <537778.13498.qm@web27107.mail.ukl.yahoo.com>
Message-ID: <464840.85424.qm@web27104.mail.ukl.yahoo.com>

Hi all:
They are @M3TraceWinMsgs and @M3SlowTrace
I get it in the file m3-ui/ui/src/winvbt/WinTrestle.m3
lines 1096, 1097
? trace_msgs := RTParams.IsPresent ("TraceWinMsgs");
? slow_trace := RTParams.IsPresent ("SlowTrace");
Thanks


--- El jue, 31/7/08, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:
De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] need help with cm3 problem before I deliver software this week
Para: "Rodney M. Bates" <rodney.bates at wichita.edu>, "Randy Coleburn" <rcoleburn at scires.com>
CC: m3devel at elegosoft.com
Fecha: jueves, 31 julio, 2008 5:43

Hi all:
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.
Thanks

--- El jue, 31/7/08, Randy Coleburn <rcoleburn at scires.com> escribi?:
De: Randy Coleburn <rcoleburn at scires.com>
Asunto: Re: [M3devel] need help with cm3 problem before I deliver software this
week
Para: "Rodney M. Bates" <rodney.bates at wichita.edu>
CC: m3devel at elegosoft.com
Fecha: jueves, 31 julio, 2008 10:51


 
Rodney:
?
I am using Windows XP Professional, Service Pack 2 (on some systems, Service
Pack 3 is applied).
?
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?
?
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.
?
Regards,
Randy

>>> "Rodney M. Bates" <rodney.bates at wichita.edu>
7/31/2008 9:33 AM >>>
Which variant of the M3 Windows target are you using?? I don't have any
of them built right now.

Randy Coleburn wrote:
> Hi Olaf, Daniel, Rodney, et al:
>? 
> Thanks for your responses so far.? Sorry for the delay in replying, but 
> our email server has been offline for nearly 24-hours.? There were some 
> severe electrical storms that took down both redundant power systems for 
> our email system.? Hope I have not missed any of your replies.
>? 
> Right now, I am delivering the software on Windows XP using SP2 or 
> greater.? I have not tried to see if this problem also occurs on Unix.? 
> I don't have ready access to a unix system from my current location.
>? 
> So it is perhaps a Windows-only problem with Trestle/FormsVBT.? In any 
> event, it is a real problem for me.
>? 
> As for the pixmap stretching problem, I have tested various resolutions 
> on the customer's computer.? Unfortunately, the customer demands that

> the display resolution stay at the 1920x1200.
> 1920x1200=pixmap stretch problem
> 1680x1050=pixmap stretch problem
> 1440x900=no problem
> 1024x768=no problem
>? 
> Regards,
> Randy
> 
>? >>> Olaf Wagner <wagner at elegosoft.com> 7/30/2008 2:24 AM
>>>
> Quoting Randy Coleburn <rcoleburn at scires.com>:
> 
>? > Hi:
>? >
>? > 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.
>? >
>? > This problem is easily reproduced using the "formsedit"
program.
>? >
>? > The problem is with the TypeIn and TypeScript FormsVBT elements
used 
>? >? in my program.? Since formsedit uses these, you can easily 
>? > reproduce? the problem.
>? >
>? > 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.
> 
> Randy,
> 
> I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't able
> to reproduce the problem on FreeBSD 6.3.
> 
> Does the problem show up on all platforms you are working on?
> Which are these?
> 
> Are there any local modifications to the libraries which I may not
> have?
> 
> If it occurs only on Unix, it may be possible that a weird window
> manager interferes with the event delivery; otherwise I've got no
> good idea. If on Unix, you/we could perhaps test the behaviour
> on a different (remote) X display?
> 
> Please provide more data about the problem context and how to
> reproduce it.
> 
> Regards,
> 
> Olaf
> 
>? > 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).
>? >
>? > 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#


      ?No te gusta tu direcci?n de correo?
Consigue una que te guste de verdad - millones de direcciones de correo disponibles en Yahoo!
http://es.docs.yahoo.com/mail/nueva_direccion.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080731/3ff8953c/attachment-0001.html>

From jayk123 at hotmail.com  Fri Aug  1 02:23:43 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 1 Aug 2008 00:23:43 +0000
Subject: [M3devel] need help with cm3 problem before I deliver
	software	this week
In-Reply-To: <464840.85424.qm@web27104.mail.ukl.yahoo.com>
References: <537778.13498.qm@web27107.mail.ukl.yahoo.com>
	<464840.85424.qm@web27104.mail.ukl.yahoo.com>
Message-ID: <COL101-W37FB9AE76D233A727F58D1E67F0@phx.gbl>


Try this also:
 
d:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinTrestle.m3
 
(*-------------------------------------------------------- initialization ---*)
VAR  useEvent_WM_CHAR := FALSE;BEGIN  WITH v = Env.Get("USE_EVENT_WM_CHAR") DO    IF v # NIL THEN      useEvent_WM_CHAR := Text.Length(v) = 0 OR                          Text.GetChar(v, 0) = '1' OR                          Text.GetChar(v, 0) = 'y' OR                          Text.GetChar(v, 0) = 'Y';    END;  END;  CreateTrestle ();END WinTrestle. set USE_EVENT_WM_CHAR=1
 or 
 set USE_EVENT_WM_CHAR=Yucky! 
 
(I think it should check for "y", or "yes", case insensitive, not just any string that starts with "y".., or only allow 0 or 1, and error for anything else, and put M3 or CM3 at the front of the variable to not clash with other uses...)
 
Though, granted, I am just totally guessing right now.
 
   - Jay



Date: Thu, 31 Jul 2008 23:16:05 +0000From: dabenavidesd at yahoo.esTo: rodney.bates at wichita.edu; rcoleburn at scires.comCC: m3devel at elegosoft.comSubject: Re: [M3devel] need help with cm3 problem before I deliver software this week



Hi all:They are @M3TraceWinMsgs and @M3SlowTraceI get it in the file m3-ui/ui/src/winvbt/WinTrestle.m3lines 1096, 1097  trace_msgs := RTParams.IsPresent ("TraceWinMsgs");  slow_trace := RTParams.IsPresent ("SlowTrace");Thanks--- El jue, 31/7/08, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:
De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>Asunto: Re: [M3devel] need help with cm3 problem before I deliver software this weekPara: "Rodney M. Bates" <rodney.bates at wichita.edu>, "Randy Coleburn" <rcoleburn at scires.com>CC: m3devel at elegosoft.comFecha: jueves, 31 julio, 2008 5:43Hi all:I think I remember somewhere there are runtime
 parameters for debugging Trestleon windows implementation. Check the source code of it; I can't find them inthis moment.Thanks--- El jue, 31/7/08, Randy Coleburn <rcoleburn at scires.com> escribi?:De: Randy Coleburn <rcoleburn at scires.com>Asunto: Re: [M3devel] need help with cm3 problem before I deliver software thisweekPara: "Rodney M. Bates" <rodney.bates at wichita.edu>CC: m3devel at elegosoft.comFecha: jueves, 31 julio, 2008 10:51 Rodney: I am using Windows XP Professional, Service Pack 2 (on some systems, ServicePack 3 is applied). Michel Dagenais suggested that if the problem does not reproduce on Linux, thatit might have to do with how Windows reports character events.  He thought aFilter VBT may exist somewhere that would aid in debugging by printing methodcalls before propagating them to father/son.  This filter VBT would be
 insertedat different places in the VBT tree to get tracing information.  Are youfamiliar with something like this? As for the pixmaps, Michel suggests increasing the resolution of the originalpixmap to help alleviate problems with upscaling.  I may try this, but ofcourse, FormsVBT uses a lot of pixmap resources, for example, radio, boolean,checkmark, numeric, etc all use pixmaps. Regards,Randy>>> "Rodney M. Bates" <rodney.bates at wichita.edu>7/31/2008 9:33 AM >>>Which variant of the M3 Windows target are you using?  I don't have anyof them built right now.Randy Coleburn wrote:> Hi Olaf, Daniel, Rodney, et al:>  > Thanks for your responses so far.  Sorry for the delay in replying, but > our email server has been offline for nearly 24-hours.  There were some > severe electrical storms that
 took down both redundant power systems for > our email system.  Hope I have not missed any of your replies.>  > Right now, I am delivering the software on Windows XP using SP2 or > greater.  I have not tried to see if this problem also occurs on Unix.  > I don't have ready access to a unix system from my current location.>  > So it is perhaps a Windows-only problem with Trestle/FormsVBT.  In any > event, it is a real problem for me.>  > As for the pixmap stretching problem, I have tested various resolutions > on the customer's computer.  Unfortunately, the customer demands that> the display resolution stay at the 1920x1200.> 1920x1200=pixmap stretch problem> 1680x1050=pixmap stretch problem> 1440x900=no problem> 1024x768=no problem>  > Regards,> Randy> > 
 >>> Olaf Wagner <wagner at elegosoft.com> 7/30/2008 2:24 AM>>>> Quoting Randy Coleburn <rcoleburn at scires.com>:> >  > Hi:>  >>  > I've been using cm3 to develop software I am delivering thisweek to >  >  a customer.  During the acceptance testing, we've run into a>  > problem  that I have not been able to solve.  I am hoping someonein >  > the cm3  community can help.  I need to solve this problem ASAPthis >  > week.>  >>  > This problem is easily reproduced using the "formsedit"program.>  >>  > The problem is with the TypeIn and TypeScript FormsVBT elementsused >  >  in my program.  Since formsedit uses these, you can easily >  > reproduce  the
 problem.>  >>  > Click with the mouse to move the insertion point somewhere in the >  > text.  Observe that the cursor moves to that point.  Now, usethe  >  > left arrow key to move the insertion point a few characters tothe  >  > left.  Then, type a few characters.  Observe that the first  >  > character you type shows up at the place where you initiallymoved  >  > the cursor with the mouse, while the remaining characters show upat >  >  the place where you moved the cursor via the left-arrow key. This  >  > behavior is wrong.  The first character you type should be atthe  >  > current insertion point, not at the one from the mouse move.> > Randy,> > I just rebuilt the CM3 GUI
 libraries and formsedit, but I wasn't able> to reproduce the problem on FreeBSD 6.3.> > Does the problem show up on all platforms you are working on?> Which are these?> > Are there any local modifications to the libraries which I may not> have?> > If it occurs only on Unix, it may be possible that a weird window> manager interferes with the event delivery; otherwise I've got no> good idea. If on Unix, you/we could perhaps test the behaviour> on a different (remote) X display?> > Please provide more data about the problem context and how to> reproduce it.> > Regards,> > Olaf> >  > I'm sure the fix is easy, but I haven't been able to locateit yet.  >  >  It probably has to do with the internal idea of the insertionpoint >  >  not getting updated
 properly.  Note that the cursor on thescreen >  > 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).>  >>  > Any assistance you can provide is very much appreciated and willgo  >  > a long way toward keeping Modula-3 use alive and well for this  >  > project.  If we can't fix this one, the customers will wantto  >  > re-code everything in some Microsoft language, probably C++ or C#

Enviado desde Correo Yahoo!La bandeja de entrada m?s inteligente.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/3e9294c6/attachment-0001.html>

From rcoleburn at scires.com  Fri Aug  1 06:28:25 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Fri, 01 Aug 2008 00:28:25 -0400
Subject: [M3devel] need help with cm3 problem before I
	deliver	software	this week
In-Reply-To: <COL101-W37FB9AE76D233A727F58D1E67F0@phx.gbl>
References: <537778.13498.qm@web27107.mail.ukl.yahoo.com>
	<464840.85424.qm@web27104.mail.ukl.yahoo.com>
	<COL101-W37FB9AE76D233A727F58D1E67F0@phx.gbl>
Message-ID: <489258A0.1E75.00D7.1@scires.com>

Jay:
 
I tried "set USE_EVENT_WM_CHAR=1"
 
The result is that I get two or more characters on the screen for each
single character typed.
 
Regards,
Randy

>>> Jay <jayk123 at hotmail.com> 7/31/2008 8:23 PM >>>
Try this also:
 
d:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinTrestle.m3
 
(*--------------------------------------------------------
initialization ---*)
VAR
  useEvent_WM_CHAR := FALSE;
BEGIN
  WITH v = Env.Get("USE_EVENT_WM_CHAR") DO
    IF v # NIL THEN
      useEvent_WM_CHAR := Text.Length(v) = 0 OR
                          Text.GetChar(v, 0) = '1' OR
                          Text.GetChar(v, 0) = 'y' OR
                          Text.GetChar(v, 0) = 'Y';
    END;
  END;
  CreateTrestle ();
END WinTrestle.


 set USE_EVENT_WM_CHAR=1
 or 
 set USE_EVENT_WM_CHAR=Yucky! 
 
(I think it should check for "y", or "yes", case insensitive, not just
any string that starts with "y".., or only allow 0 or 1, and error for
anything else, and put M3 or CM3 at the front of the variable to not
clash with other uses...)
 
Though, granted, I am just totally guessing right now.
 
   - Jay


Date: Thu, 31 Jul 2008 23:16:05 +0000
From: dabenavidesd at yahoo.es 
To: rodney.bates at wichita.edu; rcoleburn at scires.com 
CC: m3devel at elegosoft.com 
Subject: Re: [M3devel] need help with cm3 problem before I deliver
software this week



Hi all:
They are @M3TraceWinMsgs and @M3SlowTrace
I get it in the file m3-ui/ui/src/winvbt/WinTrestle.m3
lines 1096, 1097
  trace_msgs := RTParams.IsPresent ("TraceWinMsgs");
  slow_trace := RTParams.IsPresent ("SlowTrace");
Thanks


--- El jue, 31/7/08, Daniel Alejandro Benavides D.
<dabenavidesd at yahoo.es> escribi?:


De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] need help with cm3 problem before I deliver
software this week
Para: "Rodney M. Bates" <rodney.bates at wichita.edu>, "Randy Coleburn"
<rcoleburn at scires.com>
CC: m3devel at elegosoft.com 
Fecha: jueves, 31 julio, 2008 5:43

Hi all:
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.
Thanks

--- El jue, 31/7/08, Randy Coleburn <rcoleburn at scires.com> escribi?:
De: Randy Coleburn <rcoleburn at scires.com>
Asunto: Re: [M3devel] need help with cm3 problem before I deliver
software this
week
Para: "Rodney M. Bates" <rodney.bates at wichita.edu>
CC: m3devel at elegosoft.com 
Fecha: jueves, 31 julio, 2008 10:51



Rodney:
 
I am using Windows XP Professional, Service Pack 2 (on some systems,
Service
Pack 3 is applied).
 
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?
 
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.
 
Regards,
Randy

>>> "Rodney M. Bates" <rodney.bates at wichita.edu>
7/31/2008 9:33 AM >>>
Which variant of the M3 Windows target are you using?  I don't have
any
of them built right now.

Randy Coleburn wrote:
> Hi Olaf, Daniel, Rodney, et al:
>  
> Thanks for your responses so far.  Sorry for the delay in replying,
but 
> our email server has been offline for nearly 24-hours.  There were
some 
> severe electrical storms that took down both redundant power systems
for 
> our email system.  Hope I have not missed any of your replies.
>  
> Right now, I am delivering the software on Windows XP using SP2 or 
> greater.  I have not tried to see if this problem also occurs on
Unix.  
> I don't have ready access to a unix system from my current location.
>  
> So it is perhaps a Windows-only problem with Trestle/FormsVBT.  In
any 
> event, it is a real problem for me.
>  
> As for the pixmap stretching problem, I have tested various
resolutions 
> on the customer's computer.  Unfortunately, the customer demands
that

> the display resolution stay at the 1920x1200.
> 1920x1200=pixmap stretch problem
> 1680x1050=pixmap stretch problem
> 1440x900=no problem
> 1024x768=no problem
>  
> Regards,
> Randy
> 
>  >>> Olaf Wagner <wagner at elegosoft.com> 7/30/2008 2:24 AM
>>>
> Quoting Randy Coleburn <rcoleburn at scires.com>:
> 
>  > Hi:
>  >
>  > 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.
>  >
>  > This problem is easily reproduced using the "formsedit"
program.
>  >
>  > The problem is with the TypeIn and TypeScript FormsVBT elements
used 
>  >  in my program.  Since formsedit uses these, you can easily 
>  > reproduce  the problem.
>  >
>  > 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.
> 
> Randy,
> 
> I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't
able
> to reproduce the problem on FreeBSD 6.3.
> 
> Does the problem show up on all platforms you are working on?
> Which are these?
> 
> Are there any local modifications to the libraries which I may not
> have?
> 
> If it occurs only on Unix, it may be possible that a weird window
> manager interferes with the event delivery; otherwise I've got no
> good idea. If on Unix, you/we could perhaps test the behaviour
> on a different (remote) X display?
> 
> Please provide more data about the problem context and how to
> reproduce it.
> 
> Regards,
> 
> Olaf
> 
>  > 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).
>  >
>  > 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#


Enviado desde Correo Yahoo! (
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
)
La bandeja de entrada m?s inteligente.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/03efd605/attachment-0001.html>

From rcoleburn at scires.com  Fri Aug  1 06:44:38 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Fri, 01 Aug 2008 00:44:38 -0400
Subject: [M3devel] need help with cm3 problem before I deliver	software
	this week
In-Reply-To: <464840.85424.qm@web27104.mail.ukl.yahoo.com>
References: <537778.13498.qm@web27107.mail.ukl.yahoo.com>
	<464840.85424.qm@web27104.mail.ukl.yahoo.com>
Message-ID: <48925C6D.1E75.00D7.1@scires.com>

Daniel:
 
I tried @M3SlowTrace, but it does not seem to produce any output.
 
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:

msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
msg 132 = WM_NCHITTEST
msg 32 = WM_SETCURSOR
msg 513 = WM_LBUTTONDOWN
msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
msg 514 = WM_LBUTTONUP
 | msg 132 = WM_NCHITTEST
 | msg 533 = ???
msg 514 = WM_LBUTTONUP
msg 132 = WM_NCHITTEST
msg 32 = WM_SETCURSOR
msg 512 = WM_MOUSEMOVE (aka WM_MOUSEFIRST)
msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
msg 256 = WM_KEYDOWN (aka WM_KEYFIRST)
msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
msg 257 = WM_KEYUP
msg 1033 = PAINTBATCH_VBT
msg 256 = WM_KEYDOWN (aka WM_KEYFIRST)
msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
msg 257 = WM_KEYUP
msg 1033 = PAINTBATCH_VBT
msg 256 = WM_KEYDOWN (aka WM_KEYFIRST)
msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
msg 257 = WM_KEYUP
msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
msg 256 = WM_KEYDOWN (aka WM_KEYFIRST)
msg 258 = WM_CHAR
msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
msg 257 = WM_KEYUP
msg 1033 = PAINTBATCH_VBT
msg 256 = WM_KEYDOWN (aka WM_KEYFIRST)
msg 258 = WM_CHAR
msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
msg 257 = WM_KEYUP
msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
 
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.
 
Do these messages help?  It is interesting to note that one of the
messages (#533) is identified as "???"
 
Regards,
Randy

>>> "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> 7/31/2008
7:16 PM >>>

Hi all:
They are @M3TraceWinMsgs and @M3SlowTrace
I get it in the file m3-ui/ui/src/winvbt/WinTrestle.m3
lines 1096, 1097
  trace_msgs := RTParams.IsPresent ("TraceWinMsgs");
  slow_trace := RTParams.IsPresent ("SlowTrace");
Thanks


--- El jue, 31/7/08, Daniel Alejandro Benavides D.
<dabenavidesd at yahoo.es> escribi?:


De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] need help with cm3 problem before I deliver
software this week
Para: "Rodney M. Bates" <rodney.bates at wichita.edu>, "Randy Coleburn"
<rcoleburn at scires.com>
CC: m3devel at elegosoft.com 
Fecha: jueves, 31 julio, 2008 5:43

Hi all:
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.
Thanks

--- El jue, 31/7/08, Randy Coleburn <rcoleburn at scires.com> escribi?:
De: Randy Coleburn <rcoleburn at scires.com>
Asunto: Re: [M3devel] need help with cm3 problem before I deliver
software this
week
Para: "Rodney M. Bates" <rodney.bates at wichita.edu>
CC: m3devel at elegosoft.com 
Fecha: jueves, 31 julio, 2008 10:51



Rodney:
 
I am using Windows XP Professional, Service Pack 2 (on some systems,
Service
Pack 3 is applied).
 
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?
 
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.
 
Regards,
Randy

>>> "Rodney M. Bates" <rodney.bates at wichita.edu>
7/31/2008 9:33 AM >>>
Which variant of the M3 Windows target are you using?  I don't have
any
of them built right now.

Randy Coleburn wrote:
> Hi Olaf, Daniel, Rodney, et al:
>  
> Thanks for your responses so far.  Sorry for the delay in replying,
but 
> our email server has been offline for nearly 24-hours.  There were
some 
> severe electrical storms that took down both redundant power systems
for 
> our email system.  Hope I have not missed any of your replies.
>  
> Right now, I am delivering the software on Windows XP using SP2 or 
> greater.  I have not tried to see if this problem also occurs on
Unix.  
> I don't have ready access to a unix system from my current location.
>  
> So it is perhaps a Windows-only problem with Trestle/FormsVBT.  In
any 
> event, it is a real problem for me.
>  
> As for the pixmap stretching problem, I have tested various
resolutions 
> on the customer's computer.  Unfortunately, the customer demands
that

> the display resolution stay at the 1920x1200.
> 1920x1200=pixmap stretch problem
> 1680x1050=pixmap stretch problem
> 1440x900=no problem
> 1024x768=no problem
>  
> Regards,
> Randy
> 
>  >>> Olaf Wagner <wagner at elegosoft.com> 7/30/2008 2:24 AM
>>>
> Quoting Randy Coleburn <rcoleburn at scires.com>:
> 
>  > Hi:
>  >
>  > 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.
>  >
>  > This problem is easily reproduced using the "formsedit"
program.
>  >
>  > The problem is with the TypeIn and TypeScript FormsVBT elements
used 
>  >  in my program.  Since formsedit uses these, you can easily 
>  > reproduce  the problem.
>  >
>  > 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.
> 
> Randy,
> 
> I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't
able
> to reproduce the problem on FreeBSD 6.3.
> 
> Does the problem show up on all platforms you are working on?
> Which are these?
> 
> Are there any local modifications to the libraries which I may not
> have?
> 
> If it occurs only on Unix, it may be possible that a weird window
> manager interferes with the event delivery; otherwise I've got no
> good idea. If on Unix, you/we could perhaps test the behaviour
> on a different (remote) X display?
> 
> Please provide more data about the problem context and how to
> reproduce it.
> 
> Regards,
> 
> Olaf
> 
>  > 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).
>  >
>  > 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#


Enviado desde Correo Yahoo! (
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
)
La bandeja de entrada m?s inteligente.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/df3dc33a/attachment-0001.html>

From rcoleburn at scires.com  Fri Aug  1 07:00:24 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Fri, 01 Aug 2008 01:00:24 -0400
Subject: [M3devel] need help with cm3 problem before I
	deliver	software	this week
In-Reply-To: <20080731184449.su7qkp9x6ocwkoo0@mail.elegosoft.com>
References: <488F4292.1E75.00D7.1@scires.com>
	<20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com>
	<4890EB9C.1E75.00D7.1@scires.com> <4891BF18.8000905@wichita.edu>
	<4891A737.1E75.00D7.1@scires.com>
	<20080731184449.su7qkp9x6ocwkoo0@mail.elegosoft.com>
Message-ID: <4892601C.1E75.00D7.1@scires.com>

Olaf:
 
The problem reproduces every time on my system.  I've tried it on three
different XP computers with same results every time.
 
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.
 
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.
 
Regards,
Randy

>>> Olaf Wagner <wagner at elegosoft.com> 7/31/2008 12:44 PM >>>
Quoting Randy Coleburn <rcoleburn at scires.com>:

> Rodney:
>
> I am using Windows XP Professional, Service Pack 2 (on some systems,
> Service Pack 3 is applied).

Hi Randy,

I just tried formsedit on exactly this system (XP professional, SP2)
in my virtual machine, and wasn't able to see any fault wrt. cursor
processing and typing, too. I checked-out and compiled all the latest
sources of the relevant gui packages (ui, vbtkit, formsvbt etc.), but
that didn't make any difference (though some changes had been
applied).
For me it just seems to work correctly. It may be of interest though
that some months ago when I was last working on this system for the
regression tests, I applied all existing Microsoft patches; but you've
done that probably, too.

I've got no idea about the pixmap problem, too.
As long as nobody else is able to reproduce the problem it will
remain difficult to analyze this problem.

Sorry that I cannot be of more help,

Olaf

PS: Are you sure that you are really using exactly the current CM3 gui
libraries, and not some adapted or modified stuff from an older
release?

> 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?
>
> 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.
>
> Regards,
> Randy
>
>>>> "Rodney M. Bates" <rodney.bates at wichita.edu> 7/31/2008 9:33 AM
>>>
> Which variant of the M3 Windows target are you using?  I don't have
> any
> of them built right now.
>
> Randy Coleburn wrote:
>> Hi Olaf, Daniel, Rodney, et al:
>>
>> Thanks for your responses so far.  Sorry for the delay in replying,
> but
>> our email server has been offline for nearly 24-hours.  There were
> some
>> severe electrical storms that took down both redundant power
systems
> for
>> our email system.  Hope I have not missed any of your replies.
>>
>> Right now, I am delivering the software on Windows XP using SP2 or
>> greater.  I have not tried to see if this problem also occurs on
> Unix.
>> I don't have ready access to a unix system from my current
location.
>>
>> So it is perhaps a Windows-only problem with Trestle/FormsVBT.  In
> any
>> event, it is a real problem for me.
>>
>> As for the pixmap stretching problem, I have tested various
> resolutions
>> on the customer's computer.  Unfortunately, the customer demands
that
>
>> the display resolution stay at the 1920x1200.
>> 1920x1200=pixmap stretch problem
>> 1680x1050=pixmap stretch problem
>> 1440x900=no problem
>> 1024x768=no problem
>>
>> Regards,
>> Randy
>>
>>  >>> Olaf Wagner <wagner at elegosoft.com> 7/30/2008 2:24 AM >>>
>> Quoting Randy Coleburn <rcoleburn at scires.com>:
>>
>>  > Hi:
>>  >
>>  > 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.
>>  >
>>  > This problem is easily reproduced using the "formsedit" program.
>>  >
>>  > The problem is with the TypeIn and TypeScript FormsVBT elements
> used
>>  >  in my program.  Since formsedit uses these, you can easily
>>  > reproduce  the problem.
>>  >
>>  > 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.
>>
>> Randy,
>>
>> I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't
> able
>> to reproduce the problem on FreeBSD 6.3.
>>
>> Does the problem show up on all platforms you are working on?
>> Which are these?
>>
>> Are there any local modifications to the libraries which I may not
>> have?
>>
>> If it occurs only on Unix, it may be possible that a weird window
>> manager interferes with the event delivery; otherwise I've got no
>> good idea. If on Unix, you/we could perhaps test the behaviour
>> on a different (remote) X display?
>>
>> Please provide more data about the problem context and how to
>> reproduce it.
>>
>> Regards,
>>
>> Olaf
>>
>>  > 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).
>>  >
>>  > 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#.
>>  >
>>  > 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.
>>  >
>>  > Regards,
>>  > Randy Coleburn
>>  > Senior Systems Engineer
>>  > Scientific Research Corporation
>>  >
>>
>>
>>
>> --
>> Olaf Wagner -- elego Software Solutions GmbH
>>                 Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin,
> Germany
>> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23
> 45 86 95
>>     http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz:
> Berlin
>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:
> DE163214194
>>
>>
>
> --
> -------------------------------------------------------------
> Rodney M. Bates, retired assistant professor
> Dept. of Computer Science, Wichita State University
> Wichita, KS 67260-0083
> 316-978-3922
> rodney.bates at wichita.edu 
>
>



-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin,
Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45
86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz:
Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:
DE163214194


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/32d067b8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: formsedit.exe.gz
Type: application/x-gzip
Size: 747981 bytes
Desc: not available
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/32d067b8/attachment-0001.bin>

From jayk123 at hotmail.com  Fri Aug  1 10:43:31 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 1 Aug 2008 08:43:31 +0000
Subject: [M3devel] need help with cm3 problem before I deliver
	software	this week
In-Reply-To: <537778.13498.qm@web27107.mail.ukl.yahoo.com>
References: <4891A737.1E75.00D7.1@scires.com>
	<537778.13498.qm@web27107.mail.ukl.yahoo.com>
Message-ID: <COL101-W47C793FC4B3AB08006FD9DE67F0@phx.gbl>


I can reproduce the problem. Exactly as well reported.
It kind of only happens once. Bring up formsedit, click, left arrow(s), type, it does what Randy said.
Click again, arrows again, type again, not a second time. Good enough though.
Close formsedit, reopen, it repros. Good.
file.save, type backslash or forward slash in the dialog, press return, and boom:
Most other strings are ok, but a single forward or backward slash, booms.
 
****** runtime error:***    An enumeration or subrange value was out of range.***    file "..\src\os\WIN32\FSWin32.m3", line 435***
Stack trace:   FP         PC      Procedure---------  ---------  -------------------------------0x67afccc   0x42524f  BuildStatus + 0x21 in ..\src\os\WIN32\FSWin32.m30x67afe60   0x4251dc  Status + 0x137 in ..\src\os\WIN32\FSWin32.m30x67aff50   0xd9d131  DoStats + 0x253 in ..\src\lego\FileBrowserVBT.m30x67aff88   0x53a6ca  RunThread + 0x1f6 in ..\src\thread\WIN32\ThreadWin32.m30x67affb4   0x53a463  ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3.........  .........  ... more frames ...
 
bugs...
 
 
And is that red line supposed to appear in the gui?
 
 - Jay> Date: Thu, 31 Jul 2008 22:43:07 +0000> From: dabenavidesd at yahoo.es> To: rodney.bates at wichita.edu; rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] need help with cm3 problem before I deliver software this week> > Hi all:> 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.> Thanks> > --- El jue, 31/7/08, Randy Coleburn <rcoleburn at scires.com> escribi?:> De: Randy Coleburn <rcoleburn at scires.com>> Asunto: Re: [M3devel] need help with cm3 problem before I deliver software this week> Para: "Rodney M. Bates" <rodney.bates at wichita.edu>> CC: m3devel at elegosoft.com> Fecha: jueves, 31 julio, 2008 10:51> > > > Rodney:>  > I am using Windows XP Professional, Service Pack 2 (on some systems, Service Pack 3 is applied).>  > 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?>  > 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.>  > Regards,> Randy> > >>> "Rodney M. Bates" <rodney.bates at wichita.edu> 7/31/2008 9:33 AM >>>> Which variant of the M3 Windows target are you using?  I don't have any> of them built right now.> > Randy Coleburn wrote:> > Hi Olaf, Daniel, Rodney, et al:> >  > > Thanks for your responses so far.  Sorry for the delay in replying, but > > our email server has been offline for nearly 24-hours.  There were some > > severe electrical storms that took down both redundant power systems for > > our email system.  Hope I have not missed any of your replies.> >  > > Right now, I am delivering the software on Windows XP using SP2 or > > greater.  I have not tried to see if this problem also occurs on Unix.  > > I don't have ready access to a unix system from my current location.> >  > > So it is perhaps a Windows-only problem with Trestle/FormsVBT.  In any > > event, it is a real problem for me.> >  > > As for the pixmap stretching problem, I have tested various resolutions > > on the customer's computer.  Unfortunately, the customer demands that > > the display resolution stay at the 1920x1200.> > 1920x1200=pixmap stretch problem> > 1680x1050=pixmap stretch problem> > 1440x900=no problem> > 1024x768=no problem> >  > > Regards,> > Randy> > > >  >>> Olaf Wagner <wagner at elegosoft.com> 7/30/2008 2:24 AM >>>> > Quoting Randy Coleburn <rcoleburn at scires.com>:> > > >  > Hi:> >  >> >  > 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.> >  >> >  > This problem is easily reproduced using the "formsedit" program.> >  >> >  > The problem is with the TypeIn and TypeScript FormsVBT elements used > >  >  in my program.  Since formsedit uses these, you can easily > >  > reproduce  the problem.> >  >> >  > 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.> > > > Randy,> > > > I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't able> > to reproduce the problem on FreeBSD 6.3.> > > > Does the problem show up on all platforms you are working on?> > Which are these?> > > > Are there any local modifications to the libraries which I may not> > have?> > > > If it occurs only on Unix, it may be possible that a weird window> > manager interferes with the event delivery; otherwise I've got no> > good idea. If on Unix, you/we could perhaps test the behaviour> > on a different (remote) X display?> > > > Please provide more data about the problem context and how to> > reproduce it.> > > > Regards,> > > > Olaf> > > >  > 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).> >  >> >  > 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#
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/a6c7192d/attachment-0001.html>

From jayk123 at hotmail.com  Fri Aug  1 10:57:20 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 1 Aug 2008 08:57:20 +0000
Subject: [M3devel] files over 2gig break 32bit Trestle file browser
 (maybe only Win32) (was the formsedit bug)
In-Reply-To: <COL101-W47C793FC4B3AB08006FD9DE67F0@phx.gbl>
References: <4891A737.1E75.00D7.1@scires.com>
	<537778.13498.qm@web27107.mail.ukl.yahoo.com> 
	<COL101-W47C793FC4B3AB08006FD9DE67F0@phx.gbl>
Message-ID: <COL101-W749C621ADBFF6587DAC097E67F0@phx.gbl>


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



From: jayk123 at hotmail.comTo: dabenavidesd at yahoo.es; rodney.bates at wichita.edu; rcoleburn at scires.comDate: Fri, 1 Aug 2008 08:43:31 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] need help with cm3 problem before I deliver software this week


I can reproduce the problem. Exactly as well reported.It kind of only happens once. Bring up formsedit, click, left arrow(s), type, it does what Randy said.Click again, arrows again, type again, not a second time. Good enough though.Close formsedit, reopen, it repros. Good.file.save, type backslash or forward slash in the dialog, press return, and boom:Most other strings are ok, but a single forward or backward slash, booms. ****** runtime error:***    An enumeration or subrange value was out of range.***    file "..\src\os\WIN32\FSWin32.m3", line 435***Stack trace:   FP         PC      Procedure---------  ---------  -------------------------------0x67afccc   0x42524f  BuildStatus + 0x21 in ..\src\os\WIN32\FSWin32.m30x67afe60   0x4251dc  Status + 0x137 in ..\src\os\WIN32\FSWin32.m30x67aff50   0xd9d131  DoStats + 0x253 in ..\src\lego\FileBrowserVBT.m30x67aff88   0x53a6ca  RunThread + 0x1f6 in ..\src\thread\WIN32\ThreadWin32.m30x67affb4   0x53a463  ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3.........  .........  ... more frames ... bugs...  And is that red line supposed to appear in the gui?  - Jay> Date: Thu, 31 Jul 2008 22:43:07 +0000> From: dabenavidesd at yahoo.es> To: rodney.bates at wichita.edu; rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] need help with cm3 problem before I deliver software this week> > Hi all:> 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.> Thanks> > --- El jue, 31/7/08, Randy Coleburn <rcoleburn at scires.com> escribi?:> De: Randy Coleburn <rcoleburn at scires.com>> Asunto: Re: [M3devel] need help with cm3 problem before I deliver software this week> Para: "Rodney M. Bates" <rodney.bates at wichita.edu>> CC: m3devel at elegosoft.com> Fecha: jueves, 31 julio, 2008 10:51> > > > Rodney:>  > I am using Windows XP Professional, Service Pack 2 (on some systems, Service Pack 3 is applied).>  > 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?>  > 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.>  > Regards,> Randy> > >>> "Rodney M. Bates" <rodney.bates at wichita.edu> 7/31/2008 9:33 AM >>>> Which variant of the M3 Windows target are you using?  I don't have any> of them built right now.> > Randy Coleburn wrote:> > Hi Olaf, Daniel, Rodney, et al:> >  > > Thanks for your responses so far.  Sorry for the delay in replying, but > > our email server has been offline for nearly 24-hours.  There were some > > severe electrical storms that took down both redundant power systems for > > our email system.  Hope I have not missed any of your replies.> >  > > Right now, I am delivering the software on Windows XP using SP2 or > > greater.  I have not tried to see if this problem also occurs on Unix.  > > I don't have ready access to a unix system from my current location.> >  > > So it is perhaps a Windows-only problem with Trestle/FormsVBT.  In any > > event, it is a real problem for me.> >  > > As for the pixmap stretching problem, I have tested various resolutions > > on the customer's computer.  Unfortunately, the customer demands that > > the display resolution stay at the 1920x1200.> > 1920x1200=pixmap stretch problem> > 1680x1050=pixmap stretch problem> > 1440x900=no problem> > 1024x768=no problem> >  > > Regards,> > Randy> > > >  >>> Olaf Wagner <wagner at elegosoft.com> 7/30/2008 2:24 AM >>>> > Quoting Randy Coleburn <rcoleburn at scires.com>:> > > >  > Hi:> >  >> >  > 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.> >  >> >  > This problem is easily reproduced using the "formsedit" program.> >  >> >  > The problem is with the TypeIn and TypeScript FormsVBT elements used > >  >  in my program.  Since formsedit uses these, you can easily > >  > reproduce  the problem.> >  >> >  > 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.> > > > Randy,> > > > I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't able> > to reproduce the problem on FreeBSD 6.3.> > > > Does the problem show up on all platforms you are working on?> > Which are these?> > > > Are there any local modifications to the libraries which I may not> > have?> > > > If it occurs only on Unix, it may be possible that a weird window> > manager interferes with the event delivery; otherwise I've got no> > good idea. If on Unix, you/we could perhaps test the behaviour> > on a different (remote) X display?> > > > Please provide more data about the problem context and how to> > reproduce it.> > > > Regards,> > > > Olaf> > > >  > 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).> >  >> >  > 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#
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/112b85c5/attachment-0001.html>

From jayk123 at hotmail.com  Fri Aug  1 11:15:56 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 1 Aug 2008 09:15:56 +0000
Subject: [M3devel] need help with cm3 problem before I deliver
	software	this week
In-Reply-To: <537778.13498.qm@web27107.mail.ukl.yahoo.com>
References: <4891A737.1E75.00D7.1@scires.com>
	<537778.13498.qm@web27107.mail.ukl.yahoo.com> 
Message-ID: <COL101-W61F864A9FD2E441743295E67F0@phx.gbl>


I take that back -- it repros better than I said.
Every time I click, arrow, type, the first text insertion happens where I clicked.
Trestle is so layered..so many calls to a function called "Mouse" when you click..
 
 - Jay



From: jayk123 at hotmail.comTo: dabenavidesd at yahoo.es; rodney.bates at wichita.edu; rcoleburn at scires.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] need help with cm3 problem before I deliver software this weekDate: Fri, 1 Aug 2008 08:43:31 +0000


I can reproduce the problem. Exactly as well reported.It kind of only happens once. Bring up formsedit, click, left arrow(s), type, it does what Randy said.Click again, arrows again, type again, not a second time. Good enough though.Close formsedit, reopen, it repros. Good.file.save, type backslash or forward slash in the dialog, press return, and boom:Most other strings are ok, but a single forward or backward slash, booms. ****** runtime error:***    An enumeration or subrange value was out of range.***    file "..\src\os\WIN32\FSWin32.m3", line 435***Stack trace:   FP         PC      Procedure---------  ---------  -------------------------------0x67afccc   0x42524f  BuildStatus + 0x21 in ..\src\os\WIN32\FSWin32.m30x67afe60   0x4251dc  Status + 0x137 in ..\src\os\WIN32\FSWin32.m30x67aff50   0xd9d131  DoStats + 0x253 in ..\src\lego\FileBrowserVBT.m30x67aff88   0x53a6ca  RunThread + 0x1f6 in ..\src\thread\WIN32\ThreadWin32.m30x67affb4   0x53a463  ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3.........  .........  ... more frames ... bugs...  And is that red line supposed to appear in the gui?  - Jay> Date: Thu, 31 Jul 2008 22:43:07 +0000> From: dabenavidesd at yahoo.es> To: rodney.bates at wichita.edu; rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] need help with cm3 problem before I deliver software this week> > Hi all:> 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.> Thanks> > --- El jue, 31/7/08, Randy Coleburn <rcoleburn at scires.com> escribi?:> De: Randy Coleburn <rcoleburn at scires.com>> Asunto: Re: [M3devel] need help with cm3 problem before I deliver software this week> Para: "Rodney M. Bates" <rodney.bates at wichita.edu>> CC: m3devel at elegosoft.com> Fecha: jueves, 31 julio, 2008 10:51> > > > Rodney:>  > I am using Windows XP Professional, Service Pack 2 (on some systems, Service Pack 3 is applied).>  > 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?>  > 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.>  > Regards,> Randy> > >>> "Rodney M. Bates" <rodney.bates at wichita.edu> 7/31/2008 9:33 AM >>>> Which variant of the M3 Windows target are you using?  I don't have any> of them built right now.> > Randy Coleburn wrote:> > Hi Olaf, Daniel, Rodney, et al:> >  > > Thanks for your responses so far.  Sorry for the delay in replying, but > > our email server has been offline for nearly 24-hours.  There were some > > severe electrical storms that took down both redundant power systems for > > our email system.  Hope I have not missed any of your replies.> >  > > Right now, I am delivering the software on Windows XP using SP2 or > > greater.  I have not tried to see if this problem also occurs on Unix.  > > I don't have ready access to a unix system from my current location.> >  > > So it is perhaps a Windows-only problem with Trestle/FormsVBT.  In any > > event, it is a real problem for me.> >  > > As for the pixmap stretching problem, I have tested various resolutions > > on the customer's computer.  Unfortunately, the customer demands that > > the display resolution stay at the 1920x1200.> > 1920x1200=pixmap stretch problem> > 1680x1050=pixmap stretch problem> > 1440x900=no problem> > 1024x768=no problem> >  > > Regards,> > Randy> > > >  >>> Olaf Wagner <wagner at elegosoft.com> 7/30/2008 2:24 AM >>>> > Quoting Randy Coleburn <rcoleburn at scires.com>:> > > >  > Hi:> >  >> >  > 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.> >  >> >  > This problem is easily reproduced using the "formsedit" program.> >  >> >  > The problem is with the TypeIn and TypeScript FormsVBT elements used > >  >  in my program.  Since formsedit uses these, you can easily > >  > reproduce  the problem.> >  >> >  > 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.> > > > Randy,> > > > I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't able> > to reproduce the problem on FreeBSD 6.3.> > > > Does the problem show up on all platforms you are working on?> > Which are these?> > > > Are there any local modifications to the libraries which I may not> > have?> > > > If it occurs only on Unix, it may be possible that a weird window> > manager interferes with the event delivery; otherwise I've got no> > good idea. If on Unix, you/we could perhaps test the behaviour> > on a different (remote) X display?> > > > Please provide more data about the problem context and how to> > reproduce it.> > > > Regards,> > > > Olaf> > > >  > 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).> >  >> >  > 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#
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/f991c98a/attachment-0001.html>

From jayk123 at hotmail.com  Fri Aug  1 15:04:13 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 1 Aug 2008 13:04:13 +0000
Subject: [M3devel] winuser.i3
Message-ID: <COL101-W12E97C0F8EA0D9038B2985E67F0@phx.gbl>


Darko,
 
1) Where did these come from?
    (* Where did these come from? *)     MFS_MASK            = 16_0000108B;     MFS_HOTTRACKDRAWN   = 16_10000000;     MFS_CACHEDBMP       = 16_20000000;     MFS_BOTTOMGAPDROP   = 16_40000000;     MFS_TOPGAPDROP      = 16_80000000;     MFS_GAPDROP         = 16_C0000000;
I can't find them in "real" headers.
 
2) Why DEFAULT_GUI_FONT here? It belongs in WinGDI.i3. I'm moving it.
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/de74cb54/attachment-0001.html>

From jayk123 at hotmail.com  Fri Aug  1 15:52:43 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 1 Aug 2008 13:52:43 +0000
Subject: [M3devel] need help with cm3 problem before I
	deliver	software	this week
In-Reply-To: <48925C6D.1E75.00D7.1@scires.com>
References: <537778.13498.qm@web27107.mail.ukl.yahoo.com>
	<464840.85424.qm@web27104.mail.ukl.yahoo.com> 
	<48925C6D.1E75.00D7.1@scires.com>
Message-ID: <COL101-W5623694736FE1A45441C7EE67F0@phx.gbl>


 > It is interesting to note that one of the messages (#533) is identified as "???"
This is not worrisome, and it should be fixed now.
They are:
#define WM_CAPTURECHANGED               0x0215
Sadly the real problem is not yet fixed -- not even understood. :(
 
It definitely doesn't occur on other systems?
It seems quite odd -- clearly formsedit is not missing any mouse or key events, and it is dealing with all of them at least partly correctly.
It clearly isn't missing any events, otherwise it wouldn't act as correctly as it does.
The mouse click moves the insertion point and the blinking cursor. The arrow keys move the blinking cursor and the "next" insertion point, typing insert the desired characters, just that FIRST character goes to the wrong place. Strange.
 
Recoding everything in C++ or C# isn't a bad idea imho, but certainly overkill for this one problem...
 
Trying with 3.6 or 4.1 would be good. I should do that very soon. Easier than reading through all the Trestle code. :(
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/d6a91b2a/attachment-0001.html>

From jayk123 at hotmail.com  Fri Aug  1 16:06:45 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 1 Aug 2008 14:06:45 +0000
Subject: [M3devel] need help with cm3 problem before
	I	deliver	software	this week
In-Reply-To: <COL101-W5623694736FE1A45441C7EE67F0@phx.gbl>
References: <537778.13498.qm@web27107.mail.ukl.yahoo.com>
	<464840.85424.qm@web27104.mail.ukl.yahoo.com> 
	<48925C6D.1E75.00D7.1@scires.com> 
	<COL101-W5623694736FE1A45441C7EE67F0@phx.gbl>
Message-ID: <COL101-W806E32408CDC1FE80AE503E67F0@phx.gbl>


It works ok with 3.6..

From: jayk123 at hotmail.comTo: rcoleburn at scires.com; rodney.bates at wichita.edu; dabenavidesd at yahoo.esDate: Fri, 1 Aug 2008 13:52:43 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] need help with cm3 problem before I deliver software this week


 > It is interesting to note that one of the messages (#533) is identified as "???"This is not worrisome, and it should be fixed now.They are:#define WM_CAPTURECHANGED               0x0215Sadly the real problem is not yet fixed -- not even understood. :( It definitely doesn't occur on other systems?It seems quite odd -- clearly formsedit is not missing any mouse or key events, and it is dealing with all of them at least partly correctly.It clearly isn't missing any events, otherwise it wouldn't act as correctly as it does.The mouse click moves the insertion point and the blinking cursor. The arrow keys move the blinking cursor and the "next" insertion point, typing insert the desired characters, just that FIRST character goes to the wrong place. Strange. Recoding everything in C++ or C# isn't a bad idea imho, but certainly overkill for this one problem... Trying with 3.6 or 4.1 would be good. I should do that very soon. Easier than reading through all the Trestle code. :(  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/217e4bbc/attachment-0001.html>

From jayk123 at hotmail.com  Fri Aug  1 16:45:02 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 1 Aug 2008 14:45:02 +0000
Subject: [M3devel] need help with cm3 problem before
	I	deliver	software	this week
In-Reply-To: <COL101-W5623694736FE1A45441C7EE67F0@phx.gbl>
References: <537778.13498.qm@web27107.mail.ukl.yahoo.com>
	<464840.85424.qm@web27104.mail.ukl.yahoo.com> 
	<48925C6D.1E75.00D7.1@scires.com> 
	<COL101-W5623694736FE1A45441C7EE67F0@phx.gbl> 
Message-ID: <COL101-W5340B42054B530082445DCE67F0@phx.gbl>


 > It works ok with 3.6..
 
a *quick* and *incomplete* survey of 3.6 vs. current shows:  - deal with change in Text type (platform independent)   - handle WM_CHAR (windows specific)   - handle newlines differently (platform independly, except maybe the data varies per platform) 
 I tried undoing the last two, still no luck. The first is harder to undo, maybe "impossible", just have to read/debug it and decide it is ok or not..?
 Next easy step is probably to see if repros with 4.1,  and then proceed with comparing the "closer" repro vs. non-repro.  If it does not repro with 4.1, and newer releases are available  between it and current -- e.g. 5.2 -- would be good to narrow  down when it started happening and compare those source trees.
The code in question is stuff like mtext and textport.
There are functions named key or Key or mouse or Mouse. Those are also important to look at, I think.
Not being particularly close to figuring this out, consider ignoring everything I have said. :)
It is hard to pass up such a simple repro. :)And the knowledge that 3.6 works, and really not much has changed in the intervening ~12 years..
Oh, and there are pixmap changes.Randy, I glossed over the mail about pixmaps.You have a simple repro of that?You can try it with 3.6?
3.6 should still be readily downloadable from the web, and it really isn'tdifficult to get it up and running, at least on Windows.(I can't speak for Linux. I ran 3.6, albeit hardly at all, on Linux 1.2 I think it was,and NT 3.51, maybe later NT and maybe Win9x)
(and 3.6 is liberally licensed, so anyone can send it around.The notion that 5.1 was the open source release always sounded wrong...)
 - Jay



From: jayk123 at hotmail.comTo: rcoleburn at scires.com; rodney.bates at wichita.edu; dabenavidesd at yahoo.esCC: m3devel at elegosoft.comSubject: RE: [M3devel] need help with cm3 problem before I deliver software this weekDate: Fri, 1 Aug 2008 14:06:45 +0000


It works ok with 3.6..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/ca6fbed3/attachment-0001.html>

From jayk123 at hotmail.com  Fri Aug  1 16:43:17 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 1 Aug 2008 14:43:17 +0000
Subject: [M3devel] winuser.i3
In-Reply-To: <CD17C8FC-CD4C-4927-85C6-6C2FB20F80A2@darko.org>
References: <COL101-W12E97C0F8EA0D9038B2985E67F0@phx.gbl>
	<CD17C8FC-CD4C-4927-85C6-6C2FB20F80A2@darko.org>
Message-ID: <COL101-W4910DD3A123B57A3DFAAE9E67F0@phx.gbl>


Yes, I wouldn't mind that either. Windows.i3, MSWindows.i3.
For now thought I have preserved the structure and moved the font to WinGDI.i3, since it is in WinGDI.h.
I commented out the others, until such time as they are found *somewhere*, so I can least verify their correctness.
(NOT that I am in general verifying everything, just random samples.)
 
 
 - Jay



CC: m3devel at elegosoft.comFrom: darko at darko.orgTo: jayk123 at hotmail.comSubject: Re: [M3devel] winuser.i3Date: Fri, 1 Aug 2008 16:29:15 +0200
I have no Idea where there came from or where they go. Personally I'm of the opinion that all the Windows defs should go in one big file (Win.i3).


On 01/08/2008, at 3:04 PM, Jay wrote:

Darko, 1) Where did these come from?    (* Where did these come from? *)     MFS_MASK            = 16_0000108B;     MFS_HOTTRACKDRAWN   = 16_10000000;     MFS_CACHEDBMP       = 16_20000000;     MFS_BOTTOMGAPDROP   = 16_40000000;     MFS_TOPGAPDROP      = 16_80000000;     MFS_GAPDROP         = 16_C0000000;I can't find them in "real" headers. 2) Why DEFAULT_GUI_FONT here? It belongs in WinGDI.i3. I'm moving it.  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/d2d11f3a/attachment-0001.html>

From darko at darko.org  Fri Aug  1 16:29:15 2008
From: darko at darko.org (Darko)
Date: Fri, 1 Aug 2008 16:29:15 +0200
Subject: [M3devel] winuser.i3
In-Reply-To: <COL101-W12E97C0F8EA0D9038B2985E67F0@phx.gbl>
References: <COL101-W12E97C0F8EA0D9038B2985E67F0@phx.gbl>
Message-ID: <CD17C8FC-CD4C-4927-85C6-6C2FB20F80A2@darko.org>

I have no Idea where there came from or where they go. Personally I'm  
of the opinion that all the Windows defs should go in one big file  
(Win.i3).


On 01/08/2008, at 3:04 PM, Jay wrote:

> Darko,
>
> 1) Where did these come from?
>     (* Where did these come from? *)
>      MFS_MASK            = 16_0000108B;
>      MFS_HOTTRACKDRAWN   = 16_10000000;
>      MFS_CACHEDBMP       = 16_20000000;
>      MFS_BOTTOMGAPDROP   = 16_40000000;
>      MFS_TOPGAPDROP      = 16_80000000;
>      MFS_GAPDROP         = 16_C0000000;
>
> I can't find them in "real" headers.
>
> 2) Why DEFAULT_GUI_FONT here? It belongs in WinGDI.i3. I'm moving it.
>
>  - Jay
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/057ae0fa/attachment-0001.html>

From jayk123 at hotmail.com  Fri Aug  1 17:28:16 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 1 Aug 2008 15:28:16 +0000
Subject: [M3devel] need help with cm3 problem
	before	I	deliver	software	this week
In-Reply-To: <COL101-W5340B42054B530082445DCE67F0@phx.gbl>
References: <537778.13498.qm@web27107.mail.ukl.yahoo.com>
	<464840.85424.qm@web27104.mail.ukl.yahoo.com> 
	<48925C6D.1E75.00D7.1@scires.com> 
	<COL101-W5623694736FE1A45441C7EE67F0@phx.gbl>  
	<COL101-W5340B42054B530082445DCE67F0@phx.gbl>
Message-ID: <COL101-W37A68B1566CAAAF8791DBFE67F0@phx.gbl>


Clarification: there are other changes.
There was a change in font stuff.
There was added batching of painting.
And more.
 
I'm still stumped. I have to be away from this for a few hours or all day.
I think seeing if 4.1 repros will be good, and then maybe widen the net on either a) what changed (not just trestle?) and b) debugging it.
Really it shouldn't be hard..to figure how out it decides where to place the character.
 
Oh, and save the text file, see if it is in memory and on disk where it is drawn on the screen.
That would be useful to know.
 
ok..the text matches the display.
 
I can roll Wintrestle.i3 back to cm3.6, still repros.
 
Ok, the reason it is platform specific is because of:
 
Searching for 'TextPortModel: TEXT := "'...C:\dev2\cm3.2\m3-ui\vbtkit\src\vbtkitutils\POSIX\VBTKitEnv.i3(30):  TextPortModel: TEXT := "emacs";C:\dev2\cm3.2\m3-ui\vbtkit\src\vbtkitutils\WIN32\VBTKitEnv.i3(30):  TextPortModel: TEXT := "mac";
If you change Windows the the emacs model, no repro.
So try Posix to mac model, hopefully it repros.
 
Ok, Randy, is this actually your bug, or just indicative of it?
 
 - Jay



From: jayk123 at hotmail.comTo: rcoleburn at scires.com; rodney.bates at wichita.edu; dabenavidesd at yahoo.esDate: Fri, 1 Aug 2008 14:45:02 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] need help with cm3 problem before I deliver software this week


 > It works ok with 3.6.. a *quick* and *incomplete* survey of 3.6 vs. current shows:  - deal with change in Text type (platform independent)   - handle WM_CHAR (windows specific)   - handle newlines differently (platform independly, except maybe the data varies per platform)  I tried undoing the last two, still no luck. The first is harder to undo, maybe "impossible", just have to read/debug it and decide it is ok or not..? Next easy step is probably to see if repros with 4.1,  and then proceed with comparing the "closer" repro vs. non-repro.  If it does not repro with 4.1, and newer releases are available  between it and current -- e.g. 5.2 -- would be good to narrow  down when it started happening and compare those source trees.The code in question is stuff like mtext and textport.There are functions named key or Key or mouse or Mouse. Those are also important to look at, I think.Not being particularly close to figuring this out, consider ignoring everything I have said. :)It is hard to pass up such a simple repro. :)And the knowledge that 3.6 works, and really not much has changed in the intervening ~12 years..Oh, and there are pixmap changes.Randy, I glossed over the mail about pixmaps.You have a simple repro of that?You can try it with 3.6?3.6 should still be readily downloadable from the web, and it really isn'tdifficult to get it up and running, at least on Windows.(I can't speak for Linux. I ran 3.6, albeit hardly at all, on Linux 1.2 I think it was,and NT 3.51, maybe later NT and maybe Win9x)(and 3.6 is liberally licensed, so anyone can send it around.The notion that 5.1 was the open source release always sounded wrong...) - Jay



From: jayk123 at hotmail.comTo: rcoleburn at scires.com; rodney.bates at wichita.edu; dabenavidesd at yahoo.esCC: m3devel at elegosoft.comSubject: RE: [M3devel] need help with cm3 problem before I deliver software this weekDate: Fri, 1 Aug 2008 14:06:45 +0000

It works ok with 3.6..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/0a69aa5b/attachment-0001.html>

From wagner at elegosoft.com  Fri Aug  1 17:59:07 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Fri, 01 Aug 2008 17:59:07 +0200
Subject: [M3devel] need help with cm3 problem before I deliver
	software	this week
In-Reply-To: <4892601C.1E75.00D7.1@scires.com>
References: <488F4292.1E75.00D7.1@scires.com>
	<20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com>
	<4890EB9C.1E75.00D7.1@scires.com> <4891BF18.8000905@wichita.edu>
	<4891A737.1E75.00D7.1@scires.com>
	<20080731184449.su7qkp9x6ocwkoo0@mail.elegosoft.com>
	<4892601C.1E75.00D7.1@scires.com>
Message-ID: <20080801175907.irr4cv7jls0gokc0@mail.elegosoft.com>

Quoting Randy Coleburn <rcoleburn at scires.com>:

> Olaf:
>
> The problem reproduces every time on my system.  I've tried it on three
> different XP computers with same results every time.
>
> 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.
>
> 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.

Randy,

indeed your compiled program shows the strange behaviour. I'll add
my version as someone may be able to compare the linked objects and
see which are significantly different.

We can now be sure that it is indeed either a difference in the source
code or a difference in the code my and your compiler generate.
I haven't upgrade my Windows compiler for more than two months.
I'll try an upgrade of the core system later.

Regards,

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194

-------------- next part --------------
A non-text attachment was scrubbed...
Name: formsedit.exe.gz
Type: application/gzip
Size: 746259 bytes
Desc: not available
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/03eb6d8b/attachment-0001.bin>

From rcoleburn at scires.com  Fri Aug  1 18:06:31 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Fri, 01 Aug 2008 12:06:31 -0400
Subject: [M3devel] need help with cm3 problem	before	I	deliver	software
	this week
In-Reply-To: <COL101-W37A68B1566CAAAF8791DBFE67F0@phx.gbl>
References: <537778.13498.qm@web27107.mail.ukl.yahoo.com>
	<464840.85424.qm@web27104.mail.ukl.yahoo.com>
	<48925C6D.1E75.00D7.1@scires.com>
	<COL101-W5623694736FE1A45441C7EE67F0@phx.gbl>
	<COL101-W5340B42054B530082445DCE67F0@phx.gbl><COL101-W5340B42054B530082445DCE67F0@phx.gbl>
	<COL101-W37A68B1566CAAAF8791DBFE67F0@phx.gbl>
Message-ID: <4892FC3F.1E75.00D7.1@scires.com>

Jay:
 
I have checked my Reactor v4.1 distribution and the problem also reproduces there as well, so this is not something new, its been around awhile.  I guess my memory must be failing that I don't remember this bug.  In any event, my customer is not happy, so I have to try and fix this and the pixmap problem.
 
I've returned back home from the customer site.  They have given me two weeks to fix these problems and to make some enhancements they want in the product before it is released to the end users.  So, that is my time interval--I've got 2 weeks max to fix everything.  The customer is not going to accept the product if I can't fix the cursor movement typein problem.  They don't like the pixmap problem, but since it is a non-functional issue, they will have to accept the defect if I can't fix it.  So, number one priority is to get the typein at cursor issue solved.
 
Note that this problem seems to reproduce in all FormsVBT places where you can type text, even in numerics.  Thus, it is a real problem.  My product uses several windows that have fields where the user has to type to change values.  In every case, when you click the mouse and also use the arrow keys, the first character typed goes to the wrong place.  I guess I never observed this because I always clicked the mouse to the exact place I wanted and didn't use the arrow keys.
 
Jay, you mention something about changing the TextPort model and ask "is this actually your bug, or just indicative of it"?  I'm not sure exactly what you are asking me, so if you will clarify your question, I'll try to give a better answer.  I don't think switching the TextPortModel will have a bearing on the problem I am having.
 
I have to leave now for a family reunion event, so I won't have email access again until late Sunday.  When I get back, I'll try to send a short program to demonstrate the pixmap problem, but then I'm not sure you can reproduce it unless you can set your screen resolution to 1920x1200.  At a minimum, I'll try and capture some screen images to show the difference in the same window when run at the various resolutions.
 
Thanks for your assistance in helping track down this problem.
 
Regards,
Randy

>>> Jay <jayk123 at hotmail.com> 8/1/2008 11:28 AM >>>
Clarification: there are other changes.
There was a change in font stuff.
There was added batching of painting.
And more.
 
I'm still stumped. I have to be away from this for a few hours or all day.
I think seeing if 4.1 repros will be good, and then maybe widen the net on either a) what changed (not just trestle?) and b) debugging it.
Really it shouldn't be hard..to figure how out it decides where to place the character.
 
Oh, and save the text file, see if it is in memory and on disk where it is drawn on the screen.
That would be useful to know.
 
ok..the text matches the display.
 
I can roll Wintrestle.i3 back to cm3.6, still repros.
 
Ok, the reason it is platform specific is because of:
 
Searching for 'TextPortModel: TEXT := "'...
C:\dev2\cm3.2\m3-ui\vbtkit\src\vbtkitutils\POSIX\VBTKitEnv.i3(30):  TextPortModel: TEXT := "emacs";
C:\dev2\cm3.2\m3-ui\vbtkit\src\vbtkitutils\WIN32\VBTKitEnv.i3(30):  TextPortModel: TEXT := "mac";

If you change Windows the the emacs model, no repro.
So try Posix to mac model, hopefully it repros.
 
Ok, Randy, is this actually your bug, or just indicative of it?
 
 - Jay



From: jayk123 at hotmail.com 
To: rcoleburn at scires.com; rodney.bates at wichita.edu; dabenavidesd at yahoo.es 
Date: Fri, 1 Aug 2008 14:45:02 +0000
CC: m3devel at elegosoft.com 
Subject: Re: [M3devel] need help with cm3 problem before I deliver software this week

 > It works ok with 3.6..

 
a *quick* and *incomplete* survey of 3.6 vs. current shows:
  - deal with change in Text type (platform independent) 
  - handle WM_CHAR (windows specific) 
  - handle newlines differently (platform independly, except maybe the data varies per platform) 

 I tried undoing the last two, still no luck.
 The first is harder to undo, maybe "impossible", just have to read/debug it and decide it is ok or not..?

 Next easy step is probably to see if repros with 4.1,
  and then proceed with comparing the "closer" repro vs. non-repro.
  If it does not repro with 4.1, and newer releases are available
  between it and current -- e.g. 5.2 -- would be good to narrow
  down when it started happening and compare those source trees.

The code in question is stuff like mtext and textport.

There are functions named key or Key or mouse or Mouse. Those are also important to look at, I think.

Not being particularly close to figuring this out, consider ignoring everything I have said. :)

It is hard to pass up such a simple repro. :)
And the knowledge that 3.6 works, and really not much has changed in the intervening ~12 years..

Oh, and there are pixmap changes.
Randy, I glossed over the mail about pixmaps.
You have a simple repro of that?
You can try it with 3.6?

3.6 should still be readily downloadable from the web, and it really isn't
difficult to get it up and running, at least on Windows.
(I can't speak for Linux. I ran 3.6, albeit hardly at all, on Linux 1.2 I think it was,
and NT 3.51, maybe later NT and maybe Win9x)
(and 3.6 is liberally licensed, so anyone can send it around.
The notion that 5.1 was the open source release always sounded wrong...)

 - Jay





From: jayk123 at hotmail.com 
To: rcoleburn at scires.com; rodney.bates at wichita.edu; dabenavidesd at yahoo.es 
CC: m3devel at elegosoft.com 
Subject: RE: [M3devel] need help with cm3 problem before I deliver software this week
Date: Fri, 1 Aug 2008 14:06:45 +0000

It works ok with 3.6..


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/811dfc2d/attachment-0001.html>

From rcoleburn at scires.com  Fri Aug  1 18:29:38 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Fri, 01 Aug 2008 12:29:38 -0400
Subject: [M3devel] need help with cm3 problem before I
	deliver	software	this week
In-Reply-To: <20080801175907.irr4cv7jls0gokc0@mail.elegosoft.com>
References: <488F4292.1E75.00D7.1@scires.com>
	<20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com>
	<4890EB9C.1E75.00D7.1@scires.com> <4891BF18.8000905@wichita.edu>
	<4891A737.1E75.00D7.1@scires.com>
	<20080731184449.su7qkp9x6ocwkoo0@mail.elegosoft.com>
	<4892601C.1E75.00D7.1@scires.com>
	<20080801175907.irr4cv7jls0gokc0@mail.elegosoft.com>
Message-ID: <489301AA.1E75.00D7.1@scires.com>

Olaf:
 
I tested your version of formsedit on my computer and it works
correctly.
 
This is a big clue I think.  We now have the same program built on two
different machines.  One works well and one has a bug.  The bug
manifests on both systems using same EXE, so we can rule out a
difference in the computer causing the bug to manifest.  Thus, there
must be either (1) a difference in the source code base, OR (2) a
difference in the way the EXE is produced.
 
If we could compare the two source trees and find them identical, then
the problem could be traced to #2.  If the sources differ, the problem
could still be #2, but more likely would be #1.
 
Would it make sense for me to make a tar gzip file of my cm3 source
tree and send to you for compare?  Alternately, you could make the
tarball and send to me for compare with my source tree.
 
Regards,
Randy

>>> Olaf Wagner <wagner at elegosoft.com> 8/1/2008 11:59 AM >>>
Quoting Randy Coleburn <rcoleburn at scires.com>:

> Olaf:
>
> The problem reproduces every time on my system.  I've tried it on
three
> different XP computers with same results every time.
>
> 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.
>
> 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.

Randy,

indeed your compiled program shows the strange behaviour. I'll add
my version as someone may be able to compare the linked objects and
see which are significantly different.

We can now be sure that it is indeed either a difference in the source
code or a difference in the code my and your compiler generate.
I haven't upgrade my Windows compiler for more than two months.
I'll try an upgrade of the core system later.

Regards,

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin,
Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45
86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz:
Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:
DE163214194

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/ead69b46/attachment-0001.html>

From wagner at elegosoft.com  Fri Aug  1 19:33:11 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Fri, 01 Aug 2008 19:33:11 +0200
Subject: [M3devel] need help with cm3 problem before I deliver
	software	this week
In-Reply-To: <489301AA.1E75.00D7.1@scires.com>
References: <488F4292.1E75.00D7.1@scires.com>
	<20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com>
	<4890EB9C.1E75.00D7.1@scires.com> <4891BF18.8000905@wichita.edu>
	<4891A737.1E75.00D7.1@scires.com>
	<20080731184449.su7qkp9x6ocwkoo0@mail.elegosoft.com>
	<4892601C.1E75.00D7.1@scires.com>
	<20080801175907.irr4cv7jls0gokc0@mail.elegosoft.com>
	<489301AA.1E75.00D7.1@scires.com>
Message-ID: <20080801193311.cr577vkk8cw88w4s@mail.elegosoft.com>

Quoting Randy Coleburn <rcoleburn at scires.com>:

> Olaf:
>
> I tested your version of formsedit on my computer and it works
> correctly.
>
> This is a big clue I think.  We now have the same program built on two
> different machines.  One works well and one has a bug.  The bug
> manifests on both systems using same EXE, so we can rule out a
> difference in the computer causing the bug to manifest.  Thus, there
> must be either (1) a difference in the source code base, OR (2) a
> difference in the way the EXE is produced.
>
> If we could compare the two source trees and find them identical, then
> the problem could be traced to #2.  If the sources differ, the problem
> could still be #2, but more likely would be #1.
>
> Would it make sense for me to make a tar gzip file of my cm3 source
> tree and send to you for compare?  Alternately, you could make the
> tarball and send to me for compare with my source tree.

In the meantime I have updated my core system on Windows (m3-sys and
m3-libs and performed scripts/upgrade.sh) and rebuilt all the GUI
sources (they were already up-to-date). Now I can reproduce the problem.
So something must definitely been broken in the recent months.

Of course I saved all the old sources and binaries before, so I am now
able to compare them. There have been quite a lot of changes though,
so it may take a while. I don't think it is necessary that you send
me your sources now. I'll let you know what I find.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From wagner at elegosoft.com  Fri Aug  1 22:15:51 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Fri, 01 Aug 2008 22:15:51 +0200
Subject: [M3devel] need help with cm3 problem before I deliver
	software	this week
In-Reply-To: <489301AA.1E75.00D7.1@scires.com>
References: <488F4292.1E75.00D7.1@scires.com>
	<20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com>
	<4890EB9C.1E75.00D7.1@scires.com> <4891BF18.8000905@wichita.edu>
	<4891A737.1E75.00D7.1@scires.com>
	<20080731184449.su7qkp9x6ocwkoo0@mail.elegosoft.com>
	<4892601C.1E75.00D7.1@scires.com>
	<20080801175907.irr4cv7jls0gokc0@mail.elegosoft.com>
	<489301AA.1E75.00D7.1@scires.com>
Message-ID: <20080801221551.padpgo9q4gsssgsk@mail.elegosoft.com>

Quoting Randy Coleburn <rcoleburn at scires.com>:

> Olaf:
>
> I tested your version of formsedit on my computer and it works
> correctly.
>
> This is a big clue I think.  We now have the same program built on two
> different machines.  One works well and one has a bug.  The bug
> manifests on both systems using same EXE, so we can rule out a
> difference in the computer causing the bug to manifest.  Thus, there
> must be either (1) a difference in the source code base, OR (2) a
> difference in the way the EXE is produced.
>
> If we could compare the two source trees and find them identical, then
> the problem could be traced to #2.  If the sources differ, the problem
> could still be #2, but more likely would be #1.

After I first had problems to reproduce the problem, I now seem unable
to make it disappear again. I saved all sources and executables
(cm3 installation, m3-libs, m3-sys) before I did a cvs update and
upgrade on them (after which the problem showed up), but moving back
the old sources and compiler produces the same failure still.

I'm at a complete loss right now. Perhaps we really need to compare
the linked objects in both the working and broken executable after all :-/
I seem unable to narrow down the faulting component.

Perhaps I need something to eat and then some sleep...

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From jayk123 at hotmail.com  Sat Aug  2 03:18:40 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 2 Aug 2008 01:18:40 +0000
Subject: [M3devel] formsedit/pixmap bugs
In-Reply-To: <20080801221551.padpgo9q4gsssgsk@mail.elegosoft.com>
References: <488F4292.1E75.00D7.1@scires.com>
	<20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com>
	<4890EB9C.1E75.00D7.1@scires.com> <4891BF18.8000905@wichita.edu>
	<4891A737.1E75.00D7.1@scires.com>
	<20080731184449.su7qkp9x6ocwkoo0@mail.elegosoft.com>
	<4892601C.1E75.00D7.1@scires.com>
	<20080801175907.irr4cv7jls0gokc0@mail.elegosoft.com>
	<489301AA.1E75.00D7.1@scires.com> 
	<20080801221551.padpgo9q4gsssgsk@mail.elegosoft.com>
Message-ID: <COL101-W16F4A874630C2E5F5A76CEE67E0@phx.gbl>


Darnit I realized what I should have quickly checked for before disappearing for a few hours.
(and darnit, did anyone else look at any code?)


The bug is in 3.6, essentially.
Anyone have anything older?
I think older might be readily available, but I also think 3.6 might be the first version with a Win32 Trestle, declared experimental at that.


3.6:
Searching for 'TextPortModel'...
D:\modula-3\src\vbtkit\src\vbtkitutils\VBTKitEnv.i3(30):  TextPortModel: TEXT := "emacs";
D:\modula-3\src\vbtkit\src\vbtkitutils\VBTKitEnv.m3(27):      IF Text.Equal (s, "ivy") THEN TextPortModel := "ivy" 
D:\modula-3\src\vbtkit\src\vbtkitutils\VBTKitEnv.m3(28):      ELSIF Text.Equal (s, "mac") THEN TextPortModel := "mac" 
D:\modula-3\src\vbtkit\src\vbtkitutils\VBTKitEnv.m3(29):      ELSIF Text.Equal (s, "xterm") THEN TextPortModel := "xterm"


The environment variable being checked for in the last lines didn't seem to work.
So I fiddled with the first line directly.
Change it to "mac" and it repros with 3.6.


Short term fix:
  Change the default to emacs for all platforms.


After that:
 Fix the mac model.


This is all related to how selection works.
Like if I select text, and then type, does the selected text get wholly replaced (mac) or does something wierd happen (emacs).
Or something like that.
"Model" is a plugin to "TextPort" that varies some of the behavior.
I only first heard of this this morning, skimming the code


If anyone can show me it *working* with the mac model in any version, I'm slightly interested.
Really we should just focus on MacModel.m3 and fix it, for the first time.
The problem is narrowed down enough, that it should be easy.


Please make the pixmap bug clear to me. I've only skimmed and I have noticed no description at all of the bug.
Just that there is a problem with pixmaps.
There was churn here between 3.6 and current.
Please test with 3.6 and/or 4.1 if you can.


I assume the "formsedit" bug is bad behavior in various "text fields" in a gui.
Formsedit is just one user of that -- of TextPort.


 - Jay

From jayk123 at hotmail.com  Sat Aug  2 03:39:34 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 2 Aug 2008 01:39:34 +0000
Subject: [M3devel] formsedit/pixmap bugs
In-Reply-To: <COL101-W16F4A874630C2E5F5A76CEE67E0@phx.gbl>
References: <488F4292.1E75.00D7.1@scires.com>
	<20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com>
	<4890EB9C.1E75.00D7.1@scires.com> <4891BF18.8000905@wichita.edu>
	<4891A737.1E75.00D7.1@scires.com>
	<20080731184449.su7qkp9x6ocwkoo0@mail.elegosoft.com>
	<4892601C.1E75.00D7.1@scires.com>
	<20080801175907.irr4cv7jls0gokc0@mail.elegosoft.com>
	<489301AA.1E75.00D7.1@scires.com> 
	<20080801221551.padpgo9q4gsssgsk@mail.elegosoft.com> 
	<COL101-W16F4A874630C2E5F5A76CEE67E0@phx.gbl>
Message-ID: <COL101-W71F979196B1C29448A15C2E67E0@phx.gbl>


Duh, it's obvious why the environment variable didn't work.
 
You can now revert to the "working" 3.6 behavior by setting the environment variable TEXTPORTMODEL=emacs.
It already supported TEXTPORTMODEL=mac, TEXTPORTMODEL=ivy, TEXTPORTMODEL=and xterm, and defaulted to emacs on Posix, but defaults to mac on Win32, without enabling getting the emacs mode.
3.6 defaulted to emacs for all platforms, that's why 3.6 "worked".
 
The mac model should still be fixed.
 
Some of the relevant files are:
 
D:\modula-3\src>dir /s/b *model*3D:\modula-3\src\vbtkit\src\etext\EmacsModel.i3D:\modula-3\src\vbtkit\src\etext\EmacsModel.m3D:\modula-3\src\vbtkit\src\etext\IvyModel.i3D:\modula-3\src\vbtkit\src\etext\IvyModel.m3D:\modula-3\src\vbtkit\src\etext\MacModel.i3D:\modula-3\src\vbtkit\src\etext\MacModel.m3D:\modula-3\src\vbtkit\src\etext\XtermModel.i3D:\modula-3\src\vbtkit\src\etext\XtermModel.m3
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080802/f17547df/attachment-0001.html>

From rcoleburn at scires.com  Sat Aug  2 05:18:56 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Fri, 01 Aug 2008 23:18:56 -0400
Subject: [M3devel] screen shots of pixmap problem
Message-ID: <489399D1.1E75.00D7.1@scires.com>

I managed to get the customer to grab a few screen images that illustrate the pixmap problem we are having.  These screen shots supplied by the customer don't show the full extent of the pixmap problem, but I do think they show the basic issues.  Quality of the bitmaps isn't great, but I think it illustrates the problem.  
 
I think my whole application is fairly sophisticated in its use of Trestle/FormsVBT.  After the delivery, I'll try to provide the community with a portfolio of pictures we can add to the web site to show the capability of Trestle/FormsVBT.
 
The attached ZIP file contains the following files:
1.  splash_1440.bmp = the startup splash screen bitmap viewed at 1440x900 resolution.
 
2.  splash_1920.bmp = same bitmap as #1, but viewed at 1920x1200 resolution.  It is huge compared to #1.  Normally, when you increase resolution on the same screen, the images get smaller, but this time they get larger.
 
3.  aoi_1440.bmp = one of the windows viewed at 1440x900 resolution.
 
4.  aoi_1920.bmp = same window viewed at 1920x1200 resolution.  Notice that the black triangles in front of Polygon and Minutes are huge.  The text seems to be scaling fine, but the bitmaps are scaling much larger to be out of proportion with the text.  Also notice that the choice radio buttons in the Coordinates block are enlarged out of proportion.  If you look at the numeric in the lower right corner you will notice that the numeric text is elevated in the pixmap background rather than centered.  This is because the pixmap has been enlarged.  
 
Hope these screen shots help illustrate the types of problems I am having.  I have another window that has a number of Boolean choice boxes on it.  When you go to 1920x1200 these boolean pixmaps get enlarged so much that the window won't fit vertically on the screen anymore.  The OK, Close, Cancel buttons actually show off the screen, so the user can't even complete the interaction.  This same window at 1440x900 or lower looks fine and fits on the screen with no issue.
 
Any insight folks can supply on how to resolve this issue would be appreciated.
 
Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/831cb092/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pics.zip
Type: application/x-zip-compressed
Size: 419491 bytes
Desc: not available
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/831cb092/attachment-0001.bin>

From jayk123 at hotmail.com  Tue Aug  5 13:40:12 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 5 Aug 2008 11:40:12 +0000
Subject: [M3devel] formsediit/macmodel problem
Message-ID: <COL101-W272B732C79E4B4AD2F0202E67B0@phx.gbl>


That's better, thanks!
I still have little idea what is going on here.
I can test it out a bit, can't vouch for it via code review,
at least not yet.

If you have multiple lines, of varying lengths..
not sure if this is due to word wrap or not,
and click in empty space past the end of one of the lines
and type, letters do not appear.

If you click at the end of the line ok.
I think clicking past the end of the line needs to pin the resulting
cursor location to the end of the line.

 I really don't know this code. :(
I think it was written by people who had implemented the same
things multiple times and by this time had all exactly in their head
just how to factor it perfectly for the right amount of flexibility.
"Right amount of flexibility" => "harder for newbies to understand.." :(
I need to read the green book and pay close attn the whole time. :)

I still get a sort of stray looking vertical red line when I first type after clicking.
But it can be deemed minor (depending on Randy's customer really).
Probably should focus on the pixmap problem.
Can I repro it on one machine???

Randy, you might want to try out the "emacs" model, perhaps it is better tested
and works ok. ?

 - Jay



> Date: Sun, 3 Aug 2008 11:44:54 +0000
> To: m3commit at elegosoft.com
> From: wagner at elego.de
> Subject: [M3commit] CVS Update: cm3
>
> CVSROOT: /usr/cvs
> Changes by: wagner at birch. 08/08/03 11:44:54
>
> Modified files:
> cm3/m3-ui/vbtkit/src/: m3overrides
> cm3/m3-ui/vbtkit/src/etext/: MacModel.m3 TextPort.m3
>
> Log message:
> tentative fix for text selection and insertion in the Mac TextPortModel:
>
> The strange behaviour reported by Randy Coleburn (mouse click, left, left,
> insert --> first character inserted at mouse click point) should now be gone;
> cursor up and down at the right end of ragged paragraphs still looks
> a bit strange, but that seems to be not worse than before. It still
> should be fixed though.
>
> These changes should be reviewed and tested by others; they seem to do
> the right thing for me, but I haven't done extensive testing, especially
> in other modes.
>


From wagner at elegosoft.com  Tue Aug  5 14:05:40 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 05 Aug 2008 14:05:40 +0200
Subject: [M3devel] formsediit/macmodel problem
In-Reply-To: <COL101-W272B732C79E4B4AD2F0202E67B0@phx.gbl>
References: <COL101-W272B732C79E4B4AD2F0202E67B0@phx.gbl>
Message-ID: <20080805140540.16dyn3kxc04ogkww@mail.elegosoft.com>

Quoting Jay <jayk123 at hotmail.com>:

> That's better, thanks!
> I still have little idea what is going on here.
> I can test it out a bit, can't vouch for it via code review,
> at least not yet.
>
> If you have multiple lines, of varying lengths..
> not sure if this is due to word wrap or not,
> and click in empty space past the end of one of the lines
> and type, letters do not appear.

Yes, the end-of-line behaviour is strange.

> If you click at the end of the line ok.
> I think clicking past the end of the line needs to pin the resulting
> cursor location to the end of the line.
>
>  I really don't know this code. :(

I doubt there is somebody around in our community who really does ;-)

> I think it was written by people who had implemented the same
> things multiple times and by this time had all exactly in their head
> just how to factor it perfectly for the right amount of flexibility.
> "Right amount of flexibility" => "harder for newbies to understand.." :(
> I need to read the green book and pay close attn the whole time. :)
>
> I still get a sort of stray looking vertical red line when I first   
> type after clicking.
> But it can be deemed minor (depending on Randy's customer really).
> Probably should focus on the pixmap problem.
> Can I repro it on one machine???
>
> Randy, you might want to try out the "emacs" model, perhaps it is   
> better tested
> and works ok. ?

I doubt that anybody used to working on Windows or Apple would like
to use the Emacs model...

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From hosking at cs.purdue.edu  Tue Aug  5 15:38:18 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 5 Aug 2008 09:38:18 -0400
Subject: [M3devel] formsediit/macmodel problem
In-Reply-To: <20080805140540.16dyn3kxc04ogkww@mail.elegosoft.com>
References: <COL101-W272B732C79E4B4AD2F0202E67B0@phx.gbl>
	<20080805140540.16dyn3kxc04ogkww@mail.elegosoft.com>
Message-ID: <109A2D6C-1849-4F77-8323-B55A97D5BB92@cs.purdue.edu>

I use emacs bindings all the time on OS X (it tends to support them in  
most apps).

On Aug 5, 2008, at 8:05 AM, Olaf Wagner wrote:

> Quoting Jay <jayk123 at hotmail.com>:
>
>> That's better, thanks!
>> I still have little idea what is going on here.
>> I can test it out a bit, can't vouch for it via code review,
>> at least not yet.
>>
>> If you have multiple lines, of varying lengths..
>> not sure if this is due to word wrap or not,
>> and click in empty space past the end of one of the lines
>> and type, letters do not appear.
>
> Yes, the end-of-line behaviour is strange.
>
>> If you click at the end of the line ok.
>> I think clicking past the end of the line needs to pin the resulting
>> cursor location to the end of the line.
>>
>> I really don't know this code. :(
>
> I doubt there is somebody around in our community who really does ;-)
>
>> I think it was written by people who had implemented the same
>> things multiple times and by this time had all exactly in their head
>> just how to factor it perfectly for the right amount of flexibility.
>> "Right amount of flexibility" => "harder for newbies to  
>> understand.." :(
>> I need to read the green book and pay close attn the whole time. :)
>>
>> I still get a sort of stray looking vertical red line when I first   
>> type after clicking.
>> But it can be deemed minor (depending on Randy's customer really).
>> Probably should focus on the pixmap problem.
>> Can I repro it on one machine???
>>
>> Randy, you might want to try out the "emacs" model, perhaps it is   
>> better tested
>> and works ok. ?
>
> I doubt that anybody used to working on Windows or Apple would like
> to use the Emacs model...
>
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin,  
> Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23  
> 45 86 95
>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz:  
> Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:  
> DE163214194
>



From jayk123 at hotmail.com  Tue Aug  5 15:01:54 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 5 Aug 2008 13:01:54 +0000
Subject: [M3devel] pixmap problem
Message-ID: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>



Randy, I'm pretty clueless here.
I don't do gui or graphics.
If anyone has a clue, please stand up.
If you can get us code to run, please do.
But I think I need multiple particularly configured machines too.

I'm curious what this code prints on the systems:

#include
#include

int main()
{
int pix_ver = { 0 };
int pix_hor = { 0 };
int mm_hor = { 0 };
int mm_ver = { 0 };
HWND hwnd = { 0 };
HDC hdc = { 0 };

hwnd = GetDesktopWindow();
hdc = GetDC(hwnd);
mm_hor = GetDeviceCaps(hdc, HORZSIZE);
mm_ver = GetDeviceCaps(hdc, VERTSIZE);
pix_hor = GetSystemMetrics(SM_CXSCREEN);
pix_ver = GetSystemMetrics(SM_CYSCREEN);

printf("horizonal pixels %d\n", pix_hor);
printf("veritical pixels SM_CYSCREEN %d\n", pix_ver);
printf("horizontal millimeters %d\n", mm_hor);
printf("veritical millimeters %d\n", mm_ver);

printf("horizontal pixels per millimeter %f\n", (((float) pix_hor) / ((float) mm_hor)));
printf("vertical pixels per millimeter %f\n", (((float) pix_ver) / ((float) mm_ver)));

printf("horizontal pixels per inch %f\n", (((float) pix_hor) / ((float) mm_hor) * 10.0 * 2.54));
printf("vertical pixels per inch %f\n", (((float) pix_ver) / ((float) mm_ver) * 10.0 * 2.54));

return 0;
}


for me:

$ gcc dpi.c -luser32 -lgdi32

jay at jay-win9 /dev2/j/dpi
$ ./a
horizonal pixels 1280
veritical pixels SM_CYSCREEN 800
horizontal millimeters 384
veritical millimeters 240
horizontal pixels per millimeter 3.333333
vertical pixels per millimeter 3.333333
horizontal pixels per inch 84.666667
vertical pixels per inch 84.666667

(Visual C++ is fine:
cl dpi.c user32.lib gdi32.lib
.\dpi
)

I wonder if lying in this code:

Searching for 'GetDeviceCaps'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(25): VAR res := NEW(T); n_colors := GetDeviceCaps (WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(32): res.depth := GetDeviceCaps(WinGDI.BITSPIXEL); (* John Karnak 8/3/98 *)
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(68): mm_hor = GetDeviceCaps (WinGDI.HORZSIZE),
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(69): mm_ver = GetDeviceCaps (WinGDI.VERTSIZE) DO

Searching for 'res.res[Axis.T.'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(71): res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(72): res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);


D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(89):PROCEDURE GetDeviceCaps (cap: Ctypes.int): INTEGER =
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(93): res := WinGDI.GetDeviceCaps (hdc, cap);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(98): END GetDeviceCaps;
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnColorMap.m3(268): cnt := WinGDI.GetDeviceCaps (hdc, WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnFont.m3(316): LogicalPixelsPerVertInch := WinGDI.GetDeviceCaps(er.hdc, WinGDI.LOGPIXELSY);
9 occurrence(s) have been found.


Searching for '1000.0'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(463): bmih.biXPelsPerMeter := ROUND (st.res[Axis.T.Hor] * 1000.0);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(464): bmih.biYPelsPerMeter := ROUND (st.res[Axis.T.Ver] * 1000.0);


and just claiming 96dpi is the way to go.
Can you try that??


Specifically try setting res.res[Axis.T.Hor] and .Ver to 3.779527559055118.
Or heck to 3.3333 like my laptop has.


Or maybe claiming ignorance and setting biXPelsPerMeter and biYPelsPerMeter to 0???
Claiming ignorance feels better than lying of course. :)

Hm, so throw in also:

printf("LogicalPixelsX %u\n", GetDeviceCaps(hdc, LOGPIXELSX));
printf("LogicalPixelsY %u\n", GetDeviceCaps(hdc, LOGPIXELSY));

I get the magic number 96.

- Jay
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dpi.c
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080805/2ec540e4/attachment-0001.c>

From dabenavidesd at yahoo.es  Tue Aug  5 15:02:28 2008
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 5 Aug 2008 13:02:28 +0000 (GMT)
Subject: [M3devel] screen shots of pixmap problem
In-Reply-To: <489399D1.1E75.00D7.1@scires.com>
Message-ID: <46113.94040.qm@web27103.mail.ukl.yahoo.com>

Dear Randy:
Could you try to check (with cm3ide)
http://localhost:3800/public/vbtkit/src/lego/Image.i3/Raw#_DECL_ (or just on cm3/m3-ui/vbtkit/src/lego/Image.i3 )
see that line 43 has 
xres, yres: REAL := 75.0; (* in pixels per inch *) 
which is set from the sourcecode (not from the runtime variables).
you can calulate with 1920x1200 screen resolution pixels per inch
first, you apply pythogorean theorem with both catets 
Dp=sqrt(Wp^2+Wh^2)
Then PPI(or Pixels Per inch)=Dp/Di
where Di is the diagonal size in inches (the screen size), as Wikipedia says:
http://en.wikipedia.org/wiki/Pixels_per_inch
?In my case a SyncMaster 753DFX the PPI=96.42351792840054493 (Iguess the monitor you have should have more, rigth?). So you should fixed if needed the PPI rate in the source code or maybe use another variable that has the correct value.

I hope this helps, let me know
Thanks


--- El vie, 1/8/08, Randy Coleburn <rcoleburn at scires.com> escribi?:
De: Randy Coleburn <rcoleburn at scires.com>
Asunto: [M3devel] screen shots of pixmap problem
Para: m3devel at elegosoft.com
Fecha: viernes, 1 agosto, 2008 10:18


 
I managed to get the customer to grab a few screen images that illustrate the pixmap problem we are having.? These screen shots supplied by the customer don't show the full extent of the pixmap problem, but I do think they show the basic issues.? Quality of the bitmaps isn't great, but I think it illustrates the problem.? 
?
I think my whole application is fairly sophisticated in its use of Trestle/FormsVBT.? After the delivery, I'll try to provide the community with a portfolio of pictures we can add to the web site to show the capability of Trestle/FormsVBT.
?
The attached ZIP file contains the following files:
1.? splash_1440.bmp = the startup splash screen bitmap viewed at 1440x900 resolution.
?
2.? splash_1920.bmp = same bitmap as #1, but viewed at 1920x1200 resolution.? It is huge compared to #1.? Normally, when you increase resolution on the same screen, the images get smaller, but this time they get larger.
?
3.? aoi_1440.bmp = one of the windows viewed at 1440x900 resolution.
?
4.? aoi_1920.bmp = same window viewed at 1920x1200 resolution.? Notice that the black triangles in front of Polygon and Minutes are huge.? The text seems to be scaling fine, but the bitmaps are scaling much larger to be out of proportion with the text.? Also notice that the choice radio buttons in the Coordinates block are enlarged out of proportion.? If you look at the numeric in the lower right corner you will notice that the numeric text is elevated in the pixmap background rather than centered.? This is because the pixmap has been enlarged.? 
?
Hope these screen shots help illustrate the types of problems I am having.? I have another window that has a number of Boolean choice boxes on it.? When you go to 1920x1200 these boolean pixmaps get enlarged so much that the window won't fit vertically on the screen anymore.? The OK, Close, Cancel buttons actually show off the screen, so the user can't even complete the interaction.? This same window at 1440x900 or lower looks fine and fits on the screen with no issue.
?
Any insight folks can supply on how to resolve this issue would be appreciated.
?
Regards,
Randy


      ______________________________________________ 
Enviado desde Correo Yahoo! La bandeja de entrada m?s inteligente.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080805/054f3fd5/attachment-0001.html>

From rcoleburn at scires.com  Tue Aug  5 16:00:54 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Tue, 05 Aug 2008 10:00:54 -0400
Subject: [M3devel] screen shots of pixmap problem
In-Reply-To: <46113.94040.qm@web27103.mail.ukl.yahoo.com>
References: <489399D1.1E75.00D7.1@scires.com>
	<46113.94040.qm@web27103.mail.ukl.yahoo.com>
Message-ID: <489824D0.1E75.00D7.1@scires.com>

Daniel:
 
Thanks, I will check this out today.
 
In my experience, the normal dpi setting on most all Windows computers
is 96 dpi.  If the source is fixing it at 75 dpi, that would be a
problem.
 
Regards,
Randy

>>> "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> 8/5/2008
9:02 AM >>>

Dear Randy:
Could you try to check (with cm3ide)
http://localhost:3800/public/vbtkit/src/lego/Image.i3/Raw#_DECL_ (or
just on cm3/m3-ui/vbtkit/src/lego/Image.i3 )
see that line 43 has 
xres, yres: REAL := 75.0; (* in pixels per inch *) 
which is set from the sourcecode (not from the runtime variables).
you can calulate with 1920x1200 screen resolution pixels per inch
first, you apply pythogorean theorem with both catets 
Dp=sqrt(Wp^2+Wh^2)
Then PPI(or Pixels Per inch)=Dp/Di
where Di is the diagonal size in inches (the screen size), as Wikipedia
says:
http://en.wikipedia.org/wiki/Pixels_per_inch 
 In my case a SyncMaster 753DFX the PPI=96.42351792840054493 (Iguess
the monitor you have should have more, rigth?). So you should fixed if
needed the PPI rate in the source code or maybe use another variable
that has the correct value.

I hope this helps, let me know
Thanks


--- El vie, 1/8/08, Randy Coleburn <rcoleburn at scires.com> escribi?:


De: Randy Coleburn <rcoleburn at scires.com>
Asunto: [M3devel] screen shots of pixmap problem
Para: m3devel at elegosoft.com 
Fecha: viernes, 1 agosto, 2008 10:18

I managed to get the customer to grab a few screen images that
illustrate the pixmap problem we are having.  These screen shots
supplied by the customer don't show the full extent of the pixmap
problem, but I do think they show the basic issues.  Quality of the
bitmaps isn't great, but I think it illustrates the problem.  
 
I think my whole application is fairly sophisticated in its use of
Trestle/FormsVBT.  After the delivery, I'll try to provide the community
with a portfolio of pictures we can add to the web site to show the
capability of Trestle/FormsVBT.
 
The attached ZIP file contains the following files:
1.  splash_1440.bmp = the startup splash screen bitmap viewed at
1440x900 resolution.
 
2.  splash_1920.bmp = same bitmap as #1, but viewed at 1920x1200
resolution.  It is huge compared to #1.  Normally, when you increase
resolution on the same screen, the images get smaller, but this time
they get larger.
 
3.  aoi_1440.bmp = one of the windows viewed at 1440x900 resolution.
 
4.  aoi_1920.bmp = same window viewed at 1920x1200 resolution.  Notice
that the black triangles in front of Polygon and Minutes are huge.  The
text seems to be scaling fine, but the bitmaps are scaling much larger
to be out of proportion with the text.  Also notice that the choice
radio buttons in the Coordinates block are enlarged out of proportion. 
If you look at the numeric in the lower right corner you will notice
that the numeric text is elevated in the pixmap background rather than
centered.  This is because the pixmap has been enlarged.  
 
Hope these screen shots help illustrate the types of problems I am
having.  I have another window that has a number of Boolean choice boxes
on it.  When you go to 1920x1200 these boolean pixmaps get enlarged so
much that the window won't fit vertically on the screen anymore.  The
OK, Close, Cancel buttons actually show off the screen, so the user
can't even complete the interaction.  This same window at 1440x900 or
lower looks fine and fits on the screen with no issue.
 
Any insight folks can supply on how to resolve this issue would be
appreciated.
 
Regards,
Randy



Enviado desde Correo Yahoo! (
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
)
La bandeja de entrada m?s inteligente.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080805/4f349ebe/attachment-0001.html>

From rcoleburn at scires.com  Fri Aug  8 01:22:39 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Thu, 07 Aug 2008 19:22:39 -0400
Subject: [M3devel] pixmap problem
In-Reply-To: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>
References: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>
Message-ID: <489B4B79.1E75.00D7.1@scires.com>

Jay, I ran your program on a Lenovo/IBM ThinkPad T60 running at 1280x1024 resolution.  Here are the results:
 
horizonal pixels 1280
veritical pixels SM_CYSCREEN 1024
horizontal millimeters 375
veritical millimeters 300
horizontal pixels per millimeter 3.413333
vertical pixels per millimeter 3.413333
horizontal pixels per inch 86.698667
vertical pixels per inch 86.698667
 
I tried to run this program on the Dell M4300 system at 1920x1200, but I'm running into some stupid Microsoft problem.  I installed the VC_Redist, but it still doesn't work on this system.  Not sure what is wrong yet.
 
Regards,
Randy

>>> Jay <jayk123 at hotmail.com> 8/5/2008 9:01 AM >>>


Randy, I'm pretty clueless here.
I don't do gui or graphics.
If anyone has a clue, please stand up.
If you can get us code to run, please do.
But I think I need multiple particularly configured machines too.

I'm curious what this code prints on the systems:

#include
#include

int main()
{
int pix_ver = { 0 };
int pix_hor = { 0 };
int mm_hor = { 0 };
int mm_ver = { 0 };
HWND hwnd = { 0 };
HDC hdc = { 0 };

hwnd = GetDesktopWindow();
hdc = GetDC(hwnd);
mm_hor = GetDeviceCaps(hdc, HORZSIZE);
mm_ver = GetDeviceCaps(hdc, VERTSIZE);
pix_hor = GetSystemMetrics(SM_CXSCREEN);
pix_ver = GetSystemMetrics(SM_CYSCREEN);

printf("horizonal pixels %d\n", pix_hor);
printf("veritical pixels SM_CYSCREEN %d\n", pix_ver);
printf("horizontal millimeters %d\n", mm_hor);
printf("veritical millimeters %d\n", mm_ver);

printf("horizontal pixels per millimeter %f\n", (((float) pix_hor) / ((float) mm_hor)));
printf("vertical pixels per millimeter %f\n", (((float) pix_ver) / ((float) mm_ver)));

printf("horizontal pixels per inch %f\n", (((float) pix_hor) / ((float) mm_hor) * 10.0 * 2.54));
printf("vertical pixels per inch %f\n", (((float) pix_ver) / ((float) mm_ver) * 10.0 * 2.54));

return 0;
}


for me:

$ gcc dpi.c -luser32 -lgdi32

jay at jay-win9 /dev2/j/dpi
$ ./a
horizonal pixels 1280
veritical pixels SM_CYSCREEN 800
horizontal millimeters 384
veritical millimeters 240
horizontal pixels per millimeter 3.333333
vertical pixels per millimeter 3.333333
horizontal pixels per inch 84.666667
vertical pixels per inch 84.666667

(Visual C++ is fine:
cl dpi.c user32.lib gdi32.lib
.\dpi
)

I wonder if lying in this code:

Searching for 'GetDeviceCaps'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(25): VAR res := NEW(T); n_colors := GetDeviceCaps (WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(32): res.depth := GetDeviceCaps(WinGDI.BITSPIXEL); (* John Karnak 8/3/98 *)
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(68): mm_hor = GetDeviceCaps (WinGDI.HORZSIZE),
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(69): mm_ver = GetDeviceCaps (WinGDI.VERTSIZE) DO

Searching for 'res.res[Axis.T.'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(71): res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(72): res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);


D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(89):PROCEDURE GetDeviceCaps (cap: Ctypes.int): INTEGER =
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(93): res := WinGDI.GetDeviceCaps (hdc, cap);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(98): END GetDeviceCaps;
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnColorMap.m3(268): cnt := WinGDI.GetDeviceCaps (hdc, WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnFont.m3(316): LogicalPixelsPerVertInch := WinGDI.GetDeviceCaps(er.hdc, WinGDI.LOGPIXELSY);
9 occurrence(s) have been found.


Searching for '1000.0'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(463): bmih.biXPelsPerMeter := ROUND (st.res[Axis.T.Hor] * 1000.0);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(464): bmih.biYPelsPerMeter := ROUND (st.res[Axis.T.Ver] * 1000.0);


and just claiming 96dpi is the way to go.
Can you try that??


Specifically try setting res.res[Axis.T.Hor] and .Ver to 3.779527559055118.
Or heck to 3.3333 like my laptop has.


Or maybe claiming ignorance and setting biXPelsPerMeter and biYPelsPerMeter to 0???
Claiming ignorance feels better than lying of course. :)

Hm, so throw in also:

printf("LogicalPixelsX %u\n", GetDeviceCaps(hdc, LOGPIXELSX));
printf("LogicalPixelsY %u\n", GetDeviceCaps(hdc, LOGPIXELSY));

I get the magic number 96.

- Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080807/734b84fd/attachment-0001.html>

From jayk123 at hotmail.com  Fri Aug  8 01:33:09 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 7 Aug 2008 23:33:09 +0000
Subject: [M3devel] pixmap problem
In-Reply-To: <489B4B79.1E75.00D7.1@scires.com>
References: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>
	<489B4B79.1E75.00D7.1@scires.com>
Message-ID: <COL101-W61DE171DBB93FC8E684658E6750@phx.gbl>


Randy, this might be useful, or it might be yanking your chain and wasting your time. I don't know.


Please try this:

Run my C code on "both" machines/settings, one that looks right, one that looks wrong.
Actually I'm not going to use that data as far as I can figure now, but I am curious.
Look at the Modula-3 code I showed, like where GetDeviceCaps is called.
Try out some hardcoded values.
See what the effect is on the display.
Bigger numbers look better?
Small numbers look better?
No difference?


Then again..I don't think the Modula-3 code any "scaling" ever, not of pixmaps,
probably not of text.
What it could do is pick different fonts, scale squares and other polygons, and
scale the location of pixmaps. It could perhaps scale their dimensions and let
underlying code scale. I have to look into this. But it'll be a bit.

If you see any calls to GetSystemMetrics in the Modula-3, dork around with those too.


 - Jay



________________________________

Date: Thu, 7 Aug 2008 19:22:39 -0400
From: rcoleburn at scires.com
To: m3devel at elegosoft.com; jayk123 at hotmail.com
Subject: Re: [M3devel] pixmap problem



Jay, I ran your program on a Lenovo/IBM ThinkPad T60 running at 1280x1024 resolution.  Here are the results:



horizonal pixels 1280
veritical pixels SM_CYSCREEN 1024
horizontal millimeters 375
veritical millimeters 300
horizontal pixels per millimeter 3.413333
vertical pixels per millimeter 3.413333
horizontal pixels per inch 86.698667
vertical pixels per inch 86.698667



I tried to run this program on the Dell M4300 system at 1920x1200, but I'm running into some stupid Microsoft problem.  I installed the VC_Redist, but it still doesn't work on this system.  Not sure what is wrong yet.



Regards,

Randy

>>> Jay  8/5/2008 9:01 AM>>>


Randy, I'm pretty clueless here.
I don't do gui or graphics.
If anyone has a clue, please stand up.
If you can get us code to run, please do.
But I think I need multiple particularly configured machines too.

I'm curious what this code prints on the systems:

#include
#include

int main()
{
int pix_ver = { 0 };
int pix_hor = { 0 };
int mm_hor = { 0 };
int mm_ver = { 0 };
HWND hwnd = { 0 };
HDC hdc = { 0 };

hwnd = GetDesktopWindow();
hdc = GetDC(hwnd);
mm_hor = GetDeviceCaps(hdc, HORZSIZE);
mm_ver = GetDeviceCaps(hdc, VERTSIZE);
pix_hor = GetSystemMetrics(SM_CXSCREEN);
pix_ver = GetSystemMetrics(SM_CYSCREEN);

printf("horizonal pixels %d\n", pix_hor);
printf("veritical pixels SM_CYSCREEN %d\n", pix_ver);
printf("horizontal millimeters %d\n", mm_hor);
printf("veritical millimeters %d\n", mm_ver);

printf("horizontal pixels per millimeter %f\n", (((float) pix_hor) / ((float) mm_hor)));
printf("vertical pixels per millimeter %f\n", (((float) pix_ver) / ((float) mm_ver)));

printf("horizontal pixels per inch %f\n", (((float) pix_hor) / ((float) mm_hor) * 10.0 * 2.54));
printf("vertical pixels per inch %f\n", (((float) pix_ver) / ((float) mm_ver) * 10.0 * 2.54));

return 0;
}


for me:

$ gcc dpi.c -luser32 -lgdi32

jay at jay-win9 /dev2/j/dpi
$ ./a
horizonal pixels 1280
veritical pixels SM_CYSCREEN 800
horizontal millimeters 384
veritical millimeters 240
horizontal pixels per millimeter 3.333333
vertical pixels per millimeter 3.333333
horizontal pixels per inch 84.666667
vertical pixels per inch 84.666667

(Visual C++ is fine:
cl dpi.c user32.lib gdi32.lib
.\dpi
)

I wonder if lying in this code:

Searching for 'GetDeviceCaps'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(25): VAR res := NEW(T); n_colors := GetDeviceCaps (WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(32): res.depth := GetDeviceCaps(WinGDI.BITSPIXEL); (* John Karnak 8/3/98 *)
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(68): mm_hor = GetDeviceCaps (WinGDI.HORZSIZE),
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(69): mm_ver = GetDeviceCaps (WinGDI.VERTSIZE) DO

Searching for 'res.res[Axis.T.'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(71): res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(72): res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);


D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(89):PROCEDURE GetDeviceCaps (cap: Ctypes.int): INTEGER =
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(93): res := WinGDI.GetDeviceCaps (hdc, cap);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(98): END GetDeviceCaps;
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnColorMap.m3(268): cnt := WinGDI.GetDeviceCaps (hdc, WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnFont.m3(316): LogicalPixelsPerVertInch := WinGDI.GetDeviceCaps(er.hdc, WinGDI.LOGPIXELSY);
9 occurrence(s) have been found.


Searching for '1000.0'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(463): bmih.biXPelsPerMeter := ROUND (st.res[Axis.T.Hor] * 1000.0);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(464): bmih.biYPelsPerMeter := ROUND (st.res[Axis.T.Ver] * 1000.0);


and just claiming 96dpi is the way to go.
Can you try that??


Specifically try setting res.res[Axis.T.Hor] and .Ver to 3.779527559055118.
Or heck to 3.3333 like my laptop has.


Or maybe claiming ignorance and setting biXPelsPerMeter and biYPelsPerMeter to 0???
Claiming ignorance feels better than lying of course. :)

Hm, so throw in also:

printf("LogicalPixelsX %u\n", GetDeviceCaps(hdc, LOGPIXELSX));
printf("LogicalPixelsY %u\n", GetDeviceCaps(hdc, LOGPIXELSY));

I get the magic number 96.

- Jay


From rcoleburn at scires.com  Fri Aug  8 01:42:33 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Thu, 07 Aug 2008 19:42:33 -0400
Subject: [M3devel] pixmap problem (some success)
In-Reply-To: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>
References: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>
Message-ID: <489B5023.1E75.00D7.1@scires.com>

Ok, I solved the Microsoft problem.
 
Here are the results on Dell M4300 at 1920x1200:
 
horizonal pixels 1920
veritical pixels SM_CYSCREEN 1200
horizontal millimeters 330
veritical millimeters 206
horizontal pixels per millimeter 5.818182
vertical pixels per millimeter 5.825243
horizontal pixels per inch 147.781818
vertical pixels per inch 147.961165
Wow!  these numbers are radically different than the IBM T60 at 1280x1024:
 
horizonal pixels 1280
veritical pixels SM_CYSCREEN 1024
horizontal millimeters 375
veritical millimeters 300
horizontal pixels per millimeter 3.413333
vertical pixels per millimeter 3.413333
horizontal pixels per inch 86.698667
vertical pixels per inch 86.698667
Now, if you look at the Windows dpi setting for the 1920x1200 machine, it says 96dpi, but this is in the General tab of the Display properties Advanced settings.  I suspect this is just the dpi setting applied to fonts.
 
I tried plugging the numbers into Image.i3 as suggested by Daniel:
TYPE
  Raw = OBJECT
      width, height: INTEGER;
      xres: REAL := 147.781818; (* in pixels per inch *)
      yres: REAL := 147.961165; (* in pixels per inch *)
    METHODS
      get (h, v: INTEGER): Pixel;
      set (h, v: INTEGER; pixel: Pixel);
    END;
When I do this, my pixmaps look correct on the 1920x1200 display!!!!!
 
Now, the problem I am faced with is how to come up with a way that the code will work on any type of monitor.  I can't edit Image.i3 for every resolution and produce a different binary.  Any ideas?
 
Regards,
Randy

>>> Jay <jayk123 at hotmail.com> 8/5/2008 9:01 AM >>>


Randy, I'm pretty clueless here.
I don't do gui or graphics.
If anyone has a clue, please stand up.
If you can get us code to run, please do.
But I think I need multiple particularly configured machines too.

I'm curious what this code prints on the systems:

#include
#include

int main()
{
int pix_ver = { 0 };
int pix_hor = { 0 };
int mm_hor = { 0 };
int mm_ver = { 0 };
HWND hwnd = { 0 };
HDC hdc = { 0 };

hwnd = GetDesktopWindow();
hdc = GetDC(hwnd);
mm_hor = GetDeviceCaps(hdc, HORZSIZE);
mm_ver = GetDeviceCaps(hdc, VERTSIZE);
pix_hor = GetSystemMetrics(SM_CXSCREEN);
pix_ver = GetSystemMetrics(SM_CYSCREEN);

printf("horizonal pixels %d\n", pix_hor);
printf("veritical pixels SM_CYSCREEN %d\n", pix_ver);
printf("horizontal millimeters %d\n", mm_hor);
printf("veritical millimeters %d\n", mm_ver);

printf("horizontal pixels per millimeter %f\n", (((float) pix_hor) / ((float) mm_hor)));
printf("vertical pixels per millimeter %f\n", (((float) pix_ver) / ((float) mm_ver)));

printf("horizontal pixels per inch %f\n", (((float) pix_hor) / ((float) mm_hor) * 10.0 * 2.54));
printf("vertical pixels per inch %f\n", (((float) pix_ver) / ((float) mm_ver) * 10.0 * 2.54));

return 0;
}


for me:

$ gcc dpi.c -luser32 -lgdi32

jay at jay-win9 /dev2/j/dpi
$ ./a
horizonal pixels 1280
veritical pixels SM_CYSCREEN 800
horizontal millimeters 384
veritical millimeters 240
horizontal pixels per millimeter 3.333333
vertical pixels per millimeter 3.333333
horizontal pixels per inch 84.666667
vertical pixels per inch 84.666667

(Visual C++ is fine:
cl dpi.c user32.lib gdi32.lib
.\dpi
)

I wonder if lying in this code:

Searching for 'GetDeviceCaps'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(25): VAR res := NEW(T); n_colors := GetDeviceCaps (WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(32): res.depth := GetDeviceCaps(WinGDI.BITSPIXEL); (* John Karnak 8/3/98 *)
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(68): mm_hor = GetDeviceCaps (WinGDI.HORZSIZE),
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(69): mm_ver = GetDeviceCaps (WinGDI.VERTSIZE) DO

Searching for 'res.res[Axis.T.'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(71): res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(72): res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);


D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(89):PROCEDURE GetDeviceCaps (cap: Ctypes.int): INTEGER =
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(93): res := WinGDI.GetDeviceCaps (hdc, cap);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(98): END GetDeviceCaps;
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnColorMap.m3(268): cnt := WinGDI.GetDeviceCaps (hdc, WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnFont.m3(316): LogicalPixelsPerVertInch := WinGDI.GetDeviceCaps(er.hdc, WinGDI.LOGPIXELSY);
9 occurrence(s) have been found.


Searching for '1000.0'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(463): bmih.biXPelsPerMeter := ROUND (st.res[Axis.T.Hor] * 1000.0);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(464): bmih.biYPelsPerMeter := ROUND (st.res[Axis.T.Ver] * 1000.0);


and just claiming 96dpi is the way to go.
Can you try that??


Specifically try setting res.res[Axis.T.Hor] and .Ver to 3.779527559055118.
Or heck to 3.3333 like my laptop has.


Or maybe claiming ignorance and setting biXPelsPerMeter and biYPelsPerMeter to 0???
Claiming ignorance feels better than lying of course. :)

Hm, so throw in also:

printf("LogicalPixelsX %u\n", GetDeviceCaps(hdc, LOGPIXELSX));
printf("LogicalPixelsY %u\n", GetDeviceCaps(hdc, LOGPIXELSY));

I get the magic number 96.

- Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080807/86bd50b5/attachment-0001.html>

From jayk123 at hotmail.com  Fri Aug  8 02:12:24 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 8 Aug 2008 00:12:24 +0000
Subject: [M3devel] pixmap problem
In-Reply-To: <489B4B79.1E75.00D7.1@scires.com>
References: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>
	<489B4B79.1E75.00D7.1@scires.com> 
Message-ID: <COL101-W9A274E937044BF90CB8B0E6740@phx.gbl>


 > Then again..I don't think the Modula-3 code any "scaling" ever, not of pixmaps, 
False.
 
m3-ui\vbtkit\src\lego\Image.m3 is very much in the business of scalling.
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080808/982de9d6/attachment-0001.html>

From jayk123 at hotmail.com  Fri Aug  8 02:16:49 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 8 Aug 2008 00:16:49 +0000
Subject: [M3devel] pixmap problem (some success)
In-Reply-To: <489B5023.1E75.00D7.1@scires.com>
References: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>
	<489B5023.1E75.00D7.1@scires.com>
Message-ID: <COL101-W279710F3EF9B814B1DA853E6740@phx.gbl>


Awesome. I expect it is easy from here. Thanks David!

I *assume* the 75 should have been 86 in the one case,
but close enough that nobody noticed.
So these numbers come pretty directly from the GetDeviceCaps / GetSystemMetrics.

And then X Windows too.
Does anyone have a high DPI monitor running X Windows?
Probably easy enough to do this blind.

I'm trying to ignore the fact that systems have multiple
monitors, with varying dpi. You are supposed to loop your
drawing over monitors and compute what it looks like per-monitor.
I'm just making that up, right? :)

 - Jay

________________________________

Date: Thu, 7 Aug 2008 19:42:33 -0400
From: rcoleburn at scires.com
To: m3devel at elegosoft.com; jayk123 at hotmail.com; dabenavidesd at yahoo.es
Subject: Re: [M3devel] pixmap problem (some success)



Ok, I solved the Microsoft problem.



Here are the results on Dell M4300 at 1920x1200:



horizonal pixels 1920
veritical pixels SM_CYSCREEN 1200
horizontal millimeters 330
veritical millimeters 206
horizontal pixels per millimeter 5.818182
vertical pixels per millimeter 5.825243
horizontal pixels per inch 147.781818
vertical pixels per inch 147.961165

Wow!  these numbers are radically different than the IBM T60 at 1280x1024:



horizonal pixels 1280
veritical pixels SM_CYSCREEN 1024
horizontal millimeters 375
veritical millimeters 300
horizontal pixels per millimeter 3.413333
vertical pixels per millimeter 3.413333
horizontal pixels per inch 86.698667
vertical pixels per inch 86.698667

Now, if you look at the Windows dpi setting for the 1920x1200 machine, it says 96dpi, but this is in the General tab of the Display properties Advanced settings.  I suspect this is just the dpi setting applied to fonts.



I tried plugging the numbers into Image.i3 as suggested by Daniel:

TYPE
  Raw = OBJECT
      width, height: INTEGER;
      xres: REAL := 147.781818; (* in pixels per inch *)
      yres: REAL := 147.961165; (* in pixels per inch *)
    METHODS
      get (h, v: INTEGER): Pixel;
      set (h, v: INTEGER; pixel: Pixel);
    END;

When I do this, my pixmaps look correct on the 1920x1200 display!!!!!



Now, the problem I am faced with is how to come up with a way that the code will work on any type of monitor.  I can't edit Image.i3 for every resolution and produce a different binary.  Any ideas?



Regards,

Randy


>>> Jay  8/5/2008 9:01 AM>>>


Randy, I'm pretty clueless here.
I don't do gui or graphics.
If anyone has a clue, please stand up.
If you can get us code to run, please do.
But I think I need multiple particularly configured machines too.

I'm curious what this code prints on the systems:

#include
#include

int main()
{
int pix_ver = { 0 };
int pix_hor = { 0 };
int mm_hor = { 0 };
int mm_ver = { 0 };
HWND hwnd = { 0 };
HDC hdc = { 0 };

hwnd = GetDesktopWindow();
hdc = GetDC(hwnd);
mm_hor = GetDeviceCaps(hdc, HORZSIZE);
mm_ver = GetDeviceCaps(hdc, VERTSIZE);
pix_hor = GetSystemMetrics(SM_CXSCREEN);
pix_ver = GetSystemMetrics(SM_CYSCREEN);

printf("horizonal pixels %d\n", pix_hor);
printf("veritical pixels SM_CYSCREEN %d\n", pix_ver);
printf("horizontal millimeters %d\n", mm_hor);
printf("veritical millimeters %d\n", mm_ver);

printf("horizontal pixels per millimeter %f\n", (((float) pix_hor) / ((float) mm_hor)));
printf("vertical pixels per millimeter %f\n", (((float) pix_ver) / ((float) mm_ver)));

printf("horizontal pixels per inch %f\n", (((float) pix_hor) / ((float) mm_hor) * 10.0 * 2.54));
printf("vertical pixels per inch %f\n", (((float) pix_ver) / ((float) mm_ver) * 10.0 * 2.54));

return 0;
}


for me:

$ gcc dpi.c -luser32 -lgdi32

jay at jay-win9 /dev2/j/dpi
$ ./a
horizonal pixels 1280
veritical pixels SM_CYSCREEN 800
horizontal millimeters 384
veritical millimeters 240
horizontal pixels per millimeter 3.333333
vertical pixels per millimeter 3.333333
horizontal pixels per inch 84.666667
vertical pixels per inch 84.666667

(Visual C++ is fine:
cl dpi.c user32.lib gdi32.lib
.\dpi
)

I wonder if lying in this code:

Searching for 'GetDeviceCaps'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(25): VAR res := NEW(T); n_colors := GetDeviceCaps (WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(32): res.depth := GetDeviceCaps(WinGDI.BITSPIXEL); (* John Karnak 8/3/98 *)
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(68): mm_hor = GetDeviceCaps (WinGDI.HORZSIZE),
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(69): mm_ver = GetDeviceCaps (WinGDI.VERTSIZE) DO

Searching for 'res.res[Axis.T.'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(71): res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(72): res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);


D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(89):PROCEDURE GetDeviceCaps (cap: Ctypes.int): INTEGER =
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(93): res := WinGDI.GetDeviceCaps (hdc, cap);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(98): END GetDeviceCaps;
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnColorMap.m3(268): cnt := WinGDI.GetDeviceCaps (hdc, WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnFont.m3(316): LogicalPixelsPerVertInch := WinGDI.GetDeviceCaps(er.hdc, WinGDI.LOGPIXELSY);
9 occurrence(s) have been found.


Searching for '1000.0'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(463): bmih.biXPelsPerMeter := ROUND (st.res[Axis.T.Hor] * 1000.0);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(464): bmih.biYPelsPerMeter := ROUND (st.res[Axis.T.Ver] * 1000.0);


and just claiming 96dpi is the way to go.
Can you try that??


Specifically try setting res.res[Axis.T.Hor] and .Ver to 3.779527559055118.
Or heck to 3.3333 like my laptop has.


Or maybe claiming ignorance and setting biXPelsPerMeter and biYPelsPerMeter to 0???
Claiming ignorance feels better than lying of course. :)

Hm, so throw in also:

printf("LogicalPixelsX %u\n", GetDeviceCaps(hdc, LOGPIXELSX));
printf("LogicalPixelsY %u\n", GetDeviceCaps(hdc, LOGPIXELSY));

I get the magic number 96.

- Jay


From rcoleburn at scires.com  Fri Aug  8 02:26:13 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Thu, 07 Aug 2008 20:26:13 -0400
Subject: [M3devel] pixmap problem (some success)
In-Reply-To: <COL101-W279710F3EF9B814B1DA853E6740@phx.gbl>
References: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>
	<489B5023.1E75.00D7.1@scires.com>
	<COL101-W279710F3EF9B814B1DA853E6740@phx.gbl>
Message-ID: <489B5A5F.1E75.00D7.1@scires.com>

Well, I hope to soon share your optimism for "easy".  
 
Since these numbers wind up being default values for the xres/yres and since changing the defaults has made a big difference in the results, it would seem that most code must not be computing these, but relying on the default values to be correct.  
 
Since these numbers may be different for every program run on a different monitor (potentially), the question becomes how to effect a change that will work in all cases without having to recompile vbtkit.
 
Does this mean we have to track down each use of Image.Raw and put in code to compute the dpi?  Or is there some way we can do this during an initialization sequence? but alas, how to deal with the defaults supplied in the declaration?
 
Regards,
Randy

>>> Jay <jayk123 at hotmail.com> 8/7/2008 8:16 PM >>>

Awesome. I expect it is easy from here. Thanks David!

I *assume* the 75 should have been 86 in the one case,
but close enough that nobody noticed.
So these numbers come pretty directly from the GetDeviceCaps / GetSystemMetrics.

And then X Windows too.
Does anyone have a high DPI monitor running X Windows?
Probably easy enough to do this blind.

I'm trying to ignore the fact that systems have multiple
monitors, with varying dpi. You are supposed to loop your
drawing over monitors and compute what it looks like per-monitor.
I'm just making that up, right? :)

- Jay

________________________________

Date: Thu, 7 Aug 2008 19:42:33 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com; jayk123 at hotmail.com; dabenavidesd at yahoo.es 
Subject: Re: [M3devel] pixmap problem (some success)



Ok, I solved the Microsoft problem.



Here are the results on Dell M4300 at 1920x1200:



horizonal pixels 1920
veritical pixels SM_CYSCREEN 1200
horizontal millimeters 330
veritical millimeters 206
horizontal pixels per millimeter 5.818182
vertical pixels per millimeter 5.825243
horizontal pixels per inch 147.781818
vertical pixels per inch 147.961165

Wow!  these numbers are radically different than the IBM T60 at 1280x1024:



horizonal pixels 1280
veritical pixels SM_CYSCREEN 1024
horizontal millimeters 375
veritical millimeters 300
horizontal pixels per millimeter 3.413333
vertical pixels per millimeter 3.413333
horizontal pixels per inch 86.698667
vertical pixels per inch 86.698667

Now, if you look at the Windows dpi setting for the 1920x1200 machine, it says 96dpi, but this is in the General tab of the Display properties Advanced settings.  I suspect this is just the dpi setting applied to fonts.



I tried plugging the numbers into Image.i3 as suggested by Daniel:

TYPE
  Raw = OBJECT
      width, height: INTEGER;
      xres: REAL := 147.781818; (* in pixels per inch *)
      yres: REAL := 147.961165; (* in pixels per inch *)
    METHODS
      get (h, v: INTEGER): Pixel;
      set (h, v: INTEGER; pixel: Pixel);
    END;

When I do this, my pixmaps look correct on the 1920x1200 display!!!!!



Now, the problem I am faced with is how to come up with a way that the code will work on any type of monitor.  I can't edit Image.i3 for every resolution and produce a different binary.  Any ideas?



Regards,

Randy


>>> Jay  8/5/2008 9:01 AM>>>


Randy, I'm pretty clueless here.
I don't do gui or graphics.
If anyone has a clue, please stand up.
If you can get us code to run, please do.
But I think I need multiple particularly configured machines too.

I'm curious what this code prints on the systems:

#include
#include

int main()
{
int pix_ver = { 0 };
int pix_hor = { 0 };
int mm_hor = { 0 };
int mm_ver = { 0 };
HWND hwnd = { 0 };
HDC hdc = { 0 };

hwnd = GetDesktopWindow();
hdc = GetDC(hwnd);
mm_hor = GetDeviceCaps(hdc, HORZSIZE);
mm_ver = GetDeviceCaps(hdc, VERTSIZE);
pix_hor = GetSystemMetrics(SM_CXSCREEN);
pix_ver = GetSystemMetrics(SM_CYSCREEN);

printf("horizonal pixels %d\n", pix_hor);
printf("veritical pixels SM_CYSCREEN %d\n", pix_ver);
printf("horizontal millimeters %d\n", mm_hor);
printf("veritical millimeters %d\n", mm_ver);

printf("horizontal pixels per millimeter %f\n", (((float) pix_hor) / ((float) mm_hor)));
printf("vertical pixels per millimeter %f\n", (((float) pix_ver) / ((float) mm_ver)));

printf("horizontal pixels per inch %f\n", (((float) pix_hor) / ((float) mm_hor) * 10.0 * 2.54));
printf("vertical pixels per inch %f\n", (((float) pix_ver) / ((float) mm_ver) * 10.0 * 2.54));

return 0;
}


for me:

$ gcc dpi.c -luser32 -lgdi32

jay at jay-win9 /dev2/j/dpi
$ ./a
horizonal pixels 1280
veritical pixels SM_CYSCREEN 800
horizontal millimeters 384
veritical millimeters 240
horizontal pixels per millimeter 3.333333
vertical pixels per millimeter 3.333333
horizontal pixels per inch 84.666667
vertical pixels per inch 84.666667

(Visual C++ is fine:
cl dpi.c user32.lib gdi32.lib
.\dpi
)

I wonder if lying in this code:

Searching for 'GetDeviceCaps'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(25): VAR res := NEW(T); n_colors := GetDeviceCaps (WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(32): res.depth := GetDeviceCaps(WinGDI.BITSPIXEL); (* John Karnak 8/3/98 *)
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(68): mm_hor = GetDeviceCaps (WinGDI.HORZSIZE),
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(69): mm_ver = GetDeviceCaps (WinGDI.VERTSIZE) DO

Searching for 'res.res[Axis.T.'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(71): res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(72): res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);


D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(89):PROCEDURE GetDeviceCaps (cap: Ctypes.int): INTEGER =
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(93): res := WinGDI.GetDeviceCaps (hdc, cap);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(98): END GetDeviceCaps;
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnColorMap.m3(268): cnt := WinGDI.GetDeviceCaps (hdc, WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnFont.m3(316): LogicalPixelsPerVertInch := WinGDI.GetDeviceCaps(er.hdc, WinGDI.LOGPIXELSY);
9 occurrence(s) have been found.


Searching for '1000.0'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(463): bmih.biXPelsPerMeter := ROUND (st.res[Axis.T.Hor] * 1000.0);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(464): bmih.biYPelsPerMeter := ROUND (st.res[Axis.T.Ver] * 1000.0);


and just claiming 96dpi is the way to go.
Can you try that??


Specifically try setting res.res[Axis.T.Hor] and .Ver to 3.779527559055118.
Or heck to 3.3333 like my laptop has.


Or maybe claiming ignorance and setting biXPelsPerMeter and biYPelsPerMeter to 0???
Claiming ignorance feels better than lying of course. :)

Hm, so throw in also:

printf("LogicalPixelsX %u\n", GetDeviceCaps(hdc, LOGPIXELSX));
printf("LogicalPixelsY %u\n", GetDeviceCaps(hdc, LOGPIXELSY));

I get the magic number 96.

- Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080807/576a96e4/attachment-0001.html>

From jayk123 at hotmail.com  Fri Aug  8 03:35:10 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 8 Aug 2008 01:35:10 +0000
Subject: [M3devel] pixmap problem (some success)
In-Reply-To: <489B5A5F.1E75.00D7.1@scires.com>
References: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>
	<489B5023.1E75.00D7.1@scires.com>
	<COL101-W279710F3EF9B814B1DA853E6740@phx.gbl> 
	<489B5A5F.1E75.00D7.1@scires.com>
Message-ID: <COL101-W76DCEA23FC2EA0FD299A3DE6740@phx.gbl>


Computing the values is probably easy. It appears we already have the code to do that -- the program I had you run and report the numbers.

It is true there is a *small* problem of computing them early enough, but..yeah, I expect that's just done in the module initializer. I really don't like "global initialization" code ala C++ global constructors/destructors, but Modula-3 is rife with them and they aren't going away, so I'll just pile in a few more bits.

I don't know if is legal Modula-3 code, but if fields can be initialized from globals, that's about all it takes.

SOMETHING LIKE (don't castigate me where I am wrong)
In the platform-independent code, add two private globals:
DefaultXRes : INTEGER;
DefaultYRes : INTEGER;

heck, default them to 75, for the Posix case.

In the platform independent interface, functions to set them:
PROCEDURE SetDefaultXRes(a: INTEGER);
PROCEDURE SetDefaultYRes(a: INTEGER);

Nothing else on Posix, for now.

On Windows, add another module WinImage.m3 that imports Image and just has a module initializer:

BEGIN
  Image.SetDefaultXRes(ComputedSomehowNotDifficult());
  Image.SetDefaultYRes(ComputedSomehowNotDifficult());
END.

If fields cannot be initialized from globals (or function calls..heh, that has a niceness!), then you have to search out all the uses and change them to function calls, possibly a lot, possibly tedious, definitely a "breaking change", but probably just fine, really.

And then, if fields can be initialized from functions, that'd be better -- that way no module initializer.


Module initializers are "bad" in that they cause a startup cost for "everyone", even if they aren't needed for a particular scenario. It is "best" imho to have constant initialization as much as possible, and where values must be computed, use an explicit function call when needed. You can still cache the values upon first computation.


> would seem that most code must not be computing these, but relying on the default values to be correct.

Or that "most code" doesn't care what the values are, doesn't use them at all.
Like, maybe they are only used for pixmaps and not text or lines?

Anyway, I can't look into this now, but hopefully "soon".
If your customer is antsy, "the problem is mostly understood and a fix will definitely be available soon".
I think "patch Tuesday" is coming up. Let's make it by then? :)


Really, I can't believe they'd call for a rewrite over this small issue.
Presumably they really want the rewrite and are looking for any excuse they can find.
Also, if you removed the "advertising" from the splash screen, they might not have even noticed?
Or, I guess if this is Windows only, the odd look could not be noticed.
But if they also want it on X and you showed it there, and it looked the same on Windows, well...
(Really this is just a general dilemna -- app looks the same as app on all platforms, or app looks like the platform on all platforms.)


 - Jay

________________________________

Date: Thu, 7 Aug 2008 20:26:13 -0400
From: rcoleburn at scires.com
To: m3devel at elegosoft.com; jayk123 at hotmail.com; dabenavidesd at yahoo.es
Subject: RE: [M3devel] pixmap problem (some success)



Well, I hope to soon share your optimism for "easy".



Since these numbers wind up being default values for the xres/yres and since changing the defaults has made a big difference in the results, it would seem that most code must not be computing these, but relying on the default values to be correct.



Since these numbers may be different for every program run on a different monitor (potentially), the question becomes how to effect a change that will work in all cases without having to recompile vbtkit.



Does this mean we have to track down each use of Image.Raw and put in code to compute the dpi?  Or is there some way we can do this during an initialization sequence? but alas, how to deal with the defaults supplied in the declaration?



Regards,

Randy

>>> Jay  8/7/2008 8:16 PM>>>

Awesome. I expect it is easy from here. Thanks David!

I *assume* the 75 should have been 86 in the one case,
but close enough that nobody noticed.
So these numbers come pretty directly from the GetDeviceCaps / GetSystemMetrics.

And then X Windows too.
Does anyone have a high DPI monitor running X Windows?
Probably easy enough to do this blind.

I'm trying to ignore the fact that systems have multiple
monitors, with varying dpi. You are supposed to loop your
drawing over monitors and compute what it looks like per-monitor.
I'm just making that up, right? :)

- Jay

________________________________

Date: Thu, 7 Aug 2008 19:42:33 -0400
From: rcoleburn at scires.com
To: m3devel at elegosoft.com; jayk123 at hotmail.com; dabenavidesd at yahoo.es
Subject: Re: [M3devel] pixmap problem (some success)



Ok, I solved the Microsoft problem.



Here are the results on Dell M4300 at 1920x1200:



horizonal pixels 1920
veritical pixels SM_CYSCREEN 1200
horizontal millimeters 330
veritical millimeters 206
horizontal pixels per millimeter 5.818182
vertical pixels per millimeter 5.825243
horizontal pixels per inch 147.781818
vertical pixels per inch 147.961165

Wow!  these numbers are radically different than the IBM T60 at 1280x1024:



horizonal pixels 1280
veritical pixels SM_CYSCREEN 1024
horizontal millimeters 375
veritical millimeters 300
horizontal pixels per millimeter 3.413333
vertical pixels per millimeter 3.413333
horizontal pixels per inch 86.698667
vertical pixels per inch 86.698667

Now, if you look at the Windows dpi setting for the 1920x1200 machine, it says 96dpi, but this is in the General tab of the Display properties Advanced settings.  I suspect this is just the dpi setting applied to fonts.



I tried plugging the numbers into Image.i3 as suggested by Daniel:

TYPE
  Raw = OBJECT
      width, height: INTEGER;
      xres: REAL := 147.781818; (* in pixels per inch *)
      yres: REAL := 147.961165; (* in pixels per inch *)
    METHODS
      get (h, v: INTEGER): Pixel;
      set (h, v: INTEGER; pixel: Pixel);
    END;

When I do this, my pixmaps look correct on the 1920x1200 display!!!!!



Now, the problem I am faced with is how to come up with a way that the code will work on any type of monitor.  I can't edit Image.i3 for every resolution and produce a different binary.  Any ideas?



Regards,

Randy


>>> Jay  8/5/2008 9:01 AM>>>


Randy, I'm pretty clueless here.
I don't do gui or graphics.
If anyone has a clue, please stand up.
If you can get us code to run, please do.
But I think I need multiple particularly configured machines too.

I'm curious what this code prints on the systems:

#include
#include

int main()
{
int pix_ver = { 0 };
int pix_hor = { 0 };
int mm_hor = { 0 };
int mm_ver = { 0 };
HWND hwnd = { 0 };
HDC hdc = { 0 };

hwnd = GetDesktopWindow();
hdc = GetDC(hwnd);
mm_hor = GetDeviceCaps(hdc, HORZSIZE);
mm_ver = GetDeviceCaps(hdc, VERTSIZE);
pix_hor = GetSystemMetrics(SM_CXSCREEN);
pix_ver = GetSystemMetrics(SM_CYSCREEN);

printf("horizonal pixels %d\n", pix_hor);
printf("veritical pixels SM_CYSCREEN %d\n", pix_ver);
printf("horizontal millimeters %d\n", mm_hor);
printf("veritical millimeters %d\n", mm_ver);

printf("horizontal pixels per millimeter %f\n", (((float) pix_hor) / ((float) mm_hor)));
printf("vertical pixels per millimeter %f\n", (((float) pix_ver) / ((float) mm_ver)));

printf("horizontal pixels per inch %f\n", (((float) pix_hor) / ((float) mm_hor) * 10.0 * 2.54));
printf("vertical pixels per inch %f\n", (((float) pix_ver) / ((float) mm_ver) * 10.0 * 2.54));

return 0;
}


for me:

$ gcc dpi.c -luser32 -lgdi32

jay at jay-win9 /dev2/j/dpi
$ ./a
horizonal pixels 1280
veritical pixels SM_CYSCREEN 800
horizontal millimeters 384
veritical millimeters 240
horizontal pixels per millimeter 3.333333
vertical pixels per millimeter 3.333333
horizontal pixels per inch 84.666667
vertical pixels per inch 84.666667

(Visual C++ is fine:
cl dpi.c user32.lib gdi32.lib
.\dpi
)

I wonder if lying in this code:

Searching for 'GetDeviceCaps'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(25): VAR res := NEW(T); n_colors := GetDeviceCaps (WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(32): res.depth := GetDeviceCaps(WinGDI.BITSPIXEL); (* John Karnak 8/3/98 *)
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(68): mm_hor = GetDeviceCaps (WinGDI.HORZSIZE),
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(69): mm_ver = GetDeviceCaps (WinGDI.VERTSIZE) DO

Searching for 'res.res[Axis.T.'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(71): res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(72): res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);


D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(89):PROCEDURE GetDeviceCaps (cap: Ctypes.int): INTEGER =
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(93): res := WinGDI.GetDeviceCaps (hdc, cap);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(98): END GetDeviceCaps;
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnColorMap.m3(268): cnt := WinGDI.GetDeviceCaps (hdc, WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnFont.m3(316): LogicalPixelsPerVertInch := WinGDI.GetDeviceCaps(er.hdc, WinGDI.LOGPIXELSY);
9 occurrence(s) have been found.


Searching for '1000.0'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(463): bmih.biXPelsPerMeter := ROUND (st.res[Axis.T.Hor] * 1000.0);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(464): bmih.biYPelsPerMeter := ROUND (st.res[Axis.T.Ver] * 1000.0);


and just claiming 96dpi is the way to go.
Can you try that??


Specifically try setting res.res[Axis.T.Hor] and .Ver to 3.779527559055118.
Or heck to 3.3333 like my laptop has.


Or maybe claiming ignorance and setting biXPelsPerMeter and biYPelsPerMeter to 0???
Claiming ignorance feels better than lying of course. :)

Hm, so throw in also:

printf("LogicalPixelsX %u\n", GetDeviceCaps(hdc, LOGPIXELSX));
printf("LogicalPixelsY %u\n", GetDeviceCaps(hdc, LOGPIXELSY));

I get the magic number 96.

- Jay



From rcoleburn at scires.com  Fri Aug  8 03:59:07 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Thu, 07 Aug 2008 21:59:07 -0400
Subject: [M3devel] pixmap problem (some success)
In-Reply-To: <COL101-W76DCEA23FC2EA0FD299A3DE6740@phx.gbl>
References: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>
	<489B5023.1E75.00D7.1@scires.com>
	<COL101-W279710F3EF9B814B1DA853E6740@phx.gbl>
	<489B5A5F.1E75.00D7.1@scires.com>
	<COL101-W76DCEA23FC2EA0FD299A3DE6740@phx.gbl>
Message-ID: <489B7025.1E75.00D7.1@scires.com>

Jay,
 
The splash screen is not the major issue.  The pixmaps used for boolean choices, radio choices, numerics, etc. get enlarged to the point that some windows won't fit on the screen.  Also, it looks really bad--like both a first-grader with a big marker and a college-student with a fine tip pencil worked on the same window.
 
I've tried very hard to make Trestle/FormsVBT look and act like Windows GUI, but it is indeed different.  For example, on menus, you have to hold down the mouse to keep the menu open.  All these were small issues 10 years ago, but now they seem to be looming large in the customer's mind.
 
So, bottom line is that if I can't fix what they deem to be functional problems, they will indeed call for a rewrite.
 
Now that we've got the typein problem solved (thanks Olaf) and are on track for the pixmap issue, I feel better.  I have recently discovered that the numeric keys on the numeric keypad aren't accepted, so I have yet to track that problem down.
 
As for your idea of using a variable as the default initializer for xres/yres, this is not legal Modula-3.  You will get a compile error that the default is not constant.  Otherwise, it was a good idea.
 
Since Raw is an object and objects are created dynamically and new subtypes can be created (inheritance), I think the problem of how to properly set xres/yres is complicated.
 
Seems like what we need is some way to adjust these fields when the object is created initially.  Alas, Raw does not have an init() method!
 
Regards,
Randy

>>> Jay <jayk123 at hotmail.com> 8/7/2008 9:35 PM >>>

Computing the values is probably easy. It appears we already have the code to do that -- the program I had you run and report the numbers.

It is true there is a *small* problem of computing them early enough, but..yeah, I expect that's just done in the module initializer. I really don't like "global initialization" code ala C++ global constructors/destructors, but Modula-3 is rife with them and they aren't going away, so I'll just pile in a few more bits.

I don't know if is legal Modula-3 code, but if fields can be initialized from globals, that's about all it takes.

SOMETHING LIKE (don't castigate me where I am wrong)
In the platform-independent code, add two private globals:
DefaultXRes : INTEGER;
DefaultYRes : INTEGER;

heck, default them to 75, for the Posix case.

In the platform independent interface, functions to set them:
PROCEDURE SetDefaultXRes(a: INTEGER);
PROCEDURE SetDefaultYRes(a: INTEGER);

Nothing else on Posix, for now.

On Windows, add another module WinImage.m3 that imports Image and just has a module initializer:

BEGIN
  Image.SetDefaultXRes(ComputedSomehowNotDifficult());
  Image.SetDefaultYRes(ComputedSomehowNotDifficult());
END.

If fields cannot be initialized from globals (or function calls..heh, that has a niceness!), then you have to search out all the uses and change them to function calls, possibly a lot, possibly tedious, definitely a "breaking change", but probably just fine, really.

And then, if fields can be initialized from functions, that'd be better -- that way no module initializer.


Module initializers are "bad" in that they cause a startup cost for "everyone", even if they aren't needed for a particular scenario. It is "best" imho to have constant initialization as much as possible, and where values must be computed, use an explicit function call when needed. You can still cache the values upon first computation.


> would seem that most code must not be computing these, but relying on the default values to be correct.

Or that "most code" doesn't care what the values are, doesn't use them at all.
Like, maybe they are only used for pixmaps and not text or lines?

Anyway, I can't look into this now, but hopefully "soon".
If your customer is antsy, "the problem is mostly understood and a fix will definitely be available soon".
I think "patch Tuesday" is coming up. Let's make it by then? :)


Really, I can't believe they'd call for a rewrite over this small issue.
Presumably they really want the rewrite and are looking for any excuse they can find.
Also, if you removed the "advertising" from the splash screen, they might not have even noticed?
Or, I guess if this is Windows only, the odd look could not be noticed.
But if they also want it on X and you showed it there, and it looked the same on Windows, well...
(Really this is just a general dilemna -- app looks the same as app on all platforms, or app looks like the platform on all platforms.)


- Jay

________________________________

Date: Thu, 7 Aug 2008 20:26:13 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com; jayk123 at hotmail.com; dabenavidesd at yahoo.es 
Subject: RE: [M3devel] pixmap problem (some success)



Well, I hope to soon share your optimism for "easy".



Since these numbers wind up being default values for the xres/yres and since changing the defaults has made a big difference in the results, it would seem that most code must not be computing these, but relying on the default values to be correct.



Since these numbers may be different for every program run on a different monitor (potentially), the question becomes how to effect a change that will work in all cases without having to recompile vbtkit.



Does this mean we have to track down each use of Image.Raw and put in code to compute the dpi?  Or is there some way we can do this during an initialization sequence? but alas, how to deal with the defaults supplied in the declaration?



Regards,

Randy

>>> Jay  8/7/2008 8:16 PM>>>

Awesome. I expect it is easy from here. Thanks David!

I *assume* the 75 should have been 86 in the one case,
but close enough that nobody noticed.
So these numbers come pretty directly from the GetDeviceCaps / GetSystemMetrics.

And then X Windows too.
Does anyone have a high DPI monitor running X Windows?
Probably easy enough to do this blind.

I'm trying to ignore the fact that systems have multiple
monitors, with varying dpi. You are supposed to loop your
drawing over monitors and compute what it looks like per-monitor.
I'm just making that up, right? :)

- Jay

________________________________

Date: Thu, 7 Aug 2008 19:42:33 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com; jayk123 at hotmail.com; dabenavidesd at yahoo.es 
Subject: Re: [M3devel] pixmap problem (some success)



Ok, I solved the Microsoft problem.



Here are the results on Dell M4300 at 1920x1200:



horizonal pixels 1920
veritical pixels SM_CYSCREEN 1200
horizontal millimeters 330
veritical millimeters 206
horizontal pixels per millimeter 5.818182
vertical pixels per millimeter 5.825243
horizontal pixels per inch 147.781818
vertical pixels per inch 147.961165

Wow!  these numbers are radically different than the IBM T60 at 1280x1024:



horizonal pixels 1280
veritical pixels SM_CYSCREEN 1024
horizontal millimeters 375
veritical millimeters 300
horizontal pixels per millimeter 3.413333
vertical pixels per millimeter 3.413333
horizontal pixels per inch 86.698667
vertical pixels per inch 86.698667

Now, if you look at the Windows dpi setting for the 1920x1200 machine, it says 96dpi, but this is in the General tab of the Display properties Advanced settings.  I suspect this is just the dpi setting applied to fonts.



I tried plugging the numbers into Image.i3 as suggested by Daniel:

TYPE
  Raw = OBJECT
      width, height: INTEGER;
      xres: REAL := 147.781818; (* in pixels per inch *)
      yres: REAL := 147.961165; (* in pixels per inch *)
    METHODS
      get (h, v: INTEGER): Pixel;
      set (h, v: INTEGER; pixel: Pixel);
    END;

When I do this, my pixmaps look correct on the 1920x1200 display!!!!!



Now, the problem I am faced with is how to come up with a way that the code will work on any type of monitor.  I can't edit Image.i3 for every resolution and produce a different binary.  Any ideas?



Regards,

Randy


>>> Jay  8/5/2008 9:01 AM>>>


Randy, I'm pretty clueless here.
I don't do gui or graphics.
If anyone has a clue, please stand up.
If you can get us code to run, please do.
But I think I need multiple particularly configured machines too.

I'm curious what this code prints on the systems:

#include
#include

int main()
{
int pix_ver = { 0 };
int pix_hor = { 0 };
int mm_hor = { 0 };
int mm_ver = { 0 };
HWND hwnd = { 0 };
HDC hdc = { 0 };

hwnd = GetDesktopWindow();
hdc = GetDC(hwnd);
mm_hor = GetDeviceCaps(hdc, HORZSIZE);
mm_ver = GetDeviceCaps(hdc, VERTSIZE);
pix_hor = GetSystemMetrics(SM_CXSCREEN);
pix_ver = GetSystemMetrics(SM_CYSCREEN);

printf("horizonal pixels %d\n", pix_hor);
printf("veritical pixels SM_CYSCREEN %d\n", pix_ver);
printf("horizontal millimeters %d\n", mm_hor);
printf("veritical millimeters %d\n", mm_ver);

printf("horizontal pixels per millimeter %f\n", (((float) pix_hor) / ((float) mm_hor)));
printf("vertical pixels per millimeter %f\n", (((float) pix_ver) / ((float) mm_ver)));

printf("horizontal pixels per inch %f\n", (((float) pix_hor) / ((float) mm_hor) * 10.0 * 2.54));
printf("vertical pixels per inch %f\n", (((float) pix_ver) / ((float) mm_ver) * 10.0 * 2.54));

return 0;
}


for me:

$ gcc dpi.c -luser32 -lgdi32

jay at jay-win9 /dev2/j/dpi
$ ./a
horizonal pixels 1280
veritical pixels SM_CYSCREEN 800
horizontal millimeters 384
veritical millimeters 240
horizontal pixels per millimeter 3.333333
vertical pixels per millimeter 3.333333
horizontal pixels per inch 84.666667
vertical pixels per inch 84.666667

(Visual C++ is fine:
cl dpi.c user32.lib gdi32.lib
.\dpi
)

I wonder if lying in this code:

Searching for 'GetDeviceCaps'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(25): VAR res := NEW(T); n_colors := GetDeviceCaps (WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(32): res.depth := GetDeviceCaps(WinGDI.BITSPIXEL); (* John Karnak 8/3/98 *)
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(68): mm_hor = GetDeviceCaps (WinGDI.HORZSIZE),
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(69): mm_ver = GetDeviceCaps (WinGDI.VERTSIZE) DO

Searching for 'res.res[Axis.T.'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(71): res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(72): res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);


D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(89):PROCEDURE GetDeviceCaps (cap: Ctypes.int): INTEGER =
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(93): res := WinGDI.GetDeviceCaps (hdc, cap);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(98): END GetDeviceCaps;
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnColorMap.m3(268): cnt := WinGDI.GetDeviceCaps (hdc, WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnFont.m3(316): LogicalPixelsPerVertInch := WinGDI.GetDeviceCaps(er.hdc, WinGDI.LOGPIXELSY);
9 occurrence(s) have been found.


Searching for '1000.0'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(463): bmih.biXPelsPerMeter := ROUND (st.res[Axis.T.Hor] * 1000.0);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(464): bmih.biYPelsPerMeter := ROUND (st.res[Axis.T.Ver] * 1000.0);


and just claiming 96dpi is the way to go.
Can you try that??


Specifically try setting res.res[Axis.T.Hor] and .Ver to 3.779527559055118.
Or heck to 3.3333 like my laptop has.


Or maybe claiming ignorance and setting biXPelsPerMeter and biYPelsPerMeter to 0???
Claiming ignorance feels better than lying of course. :)

Hm, so throw in also:

printf("LogicalPixelsX %u\n", GetDeviceCaps(hdc, LOGPIXELSX));
printf("LogicalPixelsY %u\n", GetDeviceCaps(hdc, LOGPIXELSY));

I get the magic number 96.

- Jay


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080807/9548b783/attachment-0001.html>

From jayk123 at hotmail.com  Fri Aug  8 16:05:15 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 8 Aug 2008 14:05:15 +0000
Subject: [M3devel] pixmap problem (some success)
In-Reply-To: <489B7025.1E75.00D7.1@scires.com>
References: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>
	<489B5023.1E75.00D7.1@scires.com>
	<COL101-W279710F3EF9B814B1DA853E6740@phx.gbl>
	<489B5A5F.1E75.00D7.1@scires.com>
	<COL101-W76DCEA23FC2EA0FD299A3DE6740@phx.gbl> 
	<489B7025.1E75.00D7.1@scires.com>
Message-ID: <COL101-W49AB1574C557B5343D724DE6740@phx.gbl>


I committed a possible fix here.
Please see how it fairs.

I have a few Modula-3 questions related to the fix.

 - Did I have to expose the functions in the .i3 file
  that implement the methods? That seems "wrong".


   - Could I have used "stronger language opacity" instead
    of "informal privacy"? That is, could I have used an
    opaque type?

   - Will the change break pickles?
     "Both" due to the addition of data "or" methods?
     ie: What breaks pickles?
     Do I need to think in the mindset of
      C:
       typedef struct {
         int a,b;
       } foo_t;

       foo_t f;
       fwrite(&f, sizeof(f), 1, file);

      and not breaking such code? 
     Only if the type is "branded"? Or if types derived from it are branded?
        There could be derived types not in the cm3 tree though.
        How much do we care about breaking code outside the cm3 tree?
        e.g. in this change, I had to change every use of .xres and .yres.
       I did that, but only in the code "we have". There could be more out there.
       Personally, I get quite frustrated by this issue. I'm very willng to "fix"
        and maybe test pretty large amounts of code -- pay the price for fixing things with
        "breaking" changes, or else not make the change, but if I don't have the code, I can't.

  If this breaks pickles, I can restate the fix in a slightly "weaker" way,
    that has some risk of missing code paths, but will likely suffice.

    That is, initialize to a distinguished value like 0 or -1
     and get rid of the booleans. And, i necessary for pickling,
     put the fields back out in "public".


 The name of the ImageInit module, I wonder what it should be.


   - Jay
     


________________________________

Date: Thu, 7 Aug 2008 21:59:07 -0400
From: rcoleburn at scires.com
To: m3devel at elegosoft.com; jayk123 at hotmail.com; dabenavidesd at yahoo.es
Subject: RE: [M3devel] pixmap problem (some success)



Jay,



The splash screen is not the major issue.  The pixmaps used for boolean choices, radio choices, numerics, etc. get enlarged to the point that some windows won't fit on the screen.  Also, it looks really bad--like both a first-grader with a big marker and a college-student with a fine tip pencil worked on the same window.



I've tried very hard to make Trestle/FormsVBT look and act like Windows GUI, but it is indeed different.  For example, on menus, you have to hold down the mouse to keep the menu open.  All these were small issues 10 years ago, but now they seem to be looming large in the customer's mind.



So, bottom line is that if I can't fix what they deem to be functional problems, they will indeed call for a rewrite.



Now that we've got the typein problem solved (thanks Olaf) and are on track for the pixmap issue, I feel better.  I have recently discovered that the numeric keys on the numeric keypad aren't accepted, so I have yet to track that problem down.



As for your idea of using a variable as the default initializer for xres/yres, this is not legal Modula-3.  You will get a compile error that the default is not constant.  Otherwise, it was a good idea.



Since Raw is an object and objects are created dynamically and new subtypes can be created (inheritance), I think the problem of how to properly set xres/yres is complicated.



Seems like what we need is some way to adjust these fields when the object is created initially.  Alas, Raw does not have an init() method!



Regards,

Randy

>>> Jay  8/7/2008 9:35 PM>>>

Computing the values is probably easy. It appears we already have the code to do that -- the program I had you run and report the numbers.

It is true there is a *small* problem of computing them early enough, but..yeah, I expect that's just done in the module initializer. I really don't like "global initialization" code ala C++ global constructors/destructors, but Modula-3 is rife with them and they aren't going away, so I'll just pile in a few more bits.

I don't know if is legal Modula-3 code, but if fields can be initialized from globals, that's about all it takes.

SOMETHING LIKE (don't castigate me where I am wrong)
In the platform-independent code, add two private globals:
DefaultXRes : INTEGER;
DefaultYRes : INTEGER;

heck, default them to 75, for the Posix case.

In the platform independent interface, functions to set them:
PROCEDURE SetDefaultXRes(a: INTEGER);
PROCEDURE SetDefaultYRes(a: INTEGER);

Nothing else on Posix, for now.

On Windows, add another module WinImage.m3 that imports Image and just has a module initializer:

BEGIN
  Image.SetDefaultXRes(ComputedSomehowNotDifficult());
  Image.SetDefaultYRes(ComputedSomehowNotDifficult());
END.

If fields cannot be initialized from globals (or function calls..heh, that has a niceness!), then you have to search out all the uses and change them to function calls, possibly a lot, possibly tedious, definitely a "breaking change", but probably just fine, really.

And then, if fields can be initialized from functions, that'd be better -- that way no module initializer.


Module initializers are "bad" in that they cause a startup cost for "everyone", even if they aren't needed for a particular scenario. It is "best" imho to have constant initialization as much as possible, and where values must be computed, use an explicit function call when needed. You can still cache the values upon first computation.


> would seem that most code must not be computing these, but relying on the default values to be correct.

Or that "most code" doesn't care what the values are, doesn't use them at all.
Like, maybe they are only used for pixmaps and not text or lines?

Anyway, I can't look into this now, but hopefully "soon".
If your customer is antsy, "the problem is mostly understood and a fix will definitely be available soon".
I think "patch Tuesday" is coming up. Let's make it by then? :)


Really, I can't believe they'd call for a rewrite over this small issue.
Presumably they really want the rewrite and are looking for any excuse they can find.
Also, if you removed the "advertising" from the splash screen, they might not have even noticed?
Or, I guess if this is Windows only, the odd look could not be noticed.
But if they also want it on X and you showed it there, and it looked the same on Windows, well...
(Really this is just a general dilemna -- app looks the same as app on all platforms, or app looks like the platform on all platforms.)


- Jay

________________________________

Date: Thu, 7 Aug 2008 20:26:13 -0400
From: rcoleburn at scires.com
To: m3devel at elegosoft.com; jayk123 at hotmail.com; dabenavidesd at yahoo.es
Subject: RE: [M3devel] pixmap problem (some success)



Well, I hope to soon share your optimism for "easy".



Since these numbers wind up being default values for the xres/yres and since changing the defaults has made a big difference in the results, it would seem that most code must not be computing these, but relying on the default values to be correct.



Since these numbers may be different for every program run on a different monitor (potentially), the question becomes how to effect a change that will work in all cases without having to recompile vbtkit.



Does this mean we have to track down each use of Image.Raw and put in code to compute the dpi?  Or is there some way we can do this during an initialization sequence? but alas, how to deal with the defaults supplied in the declaration?



Regards,

Randy

>>> Jay  8/7/2008 8:16 PM>>>

Awesome. I expect it is easy from here. Thanks David!

I *assume* the 75 should have been 86 in the one case,
but close enough that nobody noticed.
So these numbers come pretty directly from the GetDeviceCaps / GetSystemMetrics.

And then X Windows too.
Does anyone have a high DPI monitor running X Windows?
Probably easy enough to do this blind.

I'm trying to ignore the fact that systems have multiple
monitors, with varying dpi. You are supposed to loop your
drawing over monitors and compute what it looks like per-monitor.
I'm just making that up, right? :)

- Jay

________________________________

Date: Thu, 7 Aug 2008 19:42:33 -0400
From: rcoleburn at scires.com
To: m3devel at elegosoft.com; jayk123 at hotmail.com; dabenavidesd at yahoo.es
Subject: Re: [M3devel] pixmap problem (some success)



Ok, I solved the Microsoft problem.



Here are the results on Dell M4300 at 1920x1200:



horizonal pixels 1920
veritical pixels SM_CYSCREEN 1200
horizontal millimeters 330
veritical millimeters 206
horizontal pixels per millimeter 5.818182
vertical pixels per millimeter 5.825243
horizontal pixels per inch 147.781818
vertical pixels per inch 147.961165

Wow!  these numbers are radically different than the IBM T60 at 1280x1024:



horizonal pixels 1280
veritical pixels SM_CYSCREEN 1024
horizontal millimeters 375
veritical millimeters 300
horizontal pixels per millimeter 3.413333
vertical pixels per millimeter 3.413333
horizontal pixels per inch 86.698667
vertical pixels per inch 86.698667

Now, if you look at the Windows dpi setting for the 1920x1200 machine, it says 96dpi, but this is in the General tab of the Display properties Advanced settings.  I suspect this is just the dpi setting applied to fonts.



I tried plugging the numbers into Image.i3 as suggested by Daniel:

TYPE
  Raw = OBJECT
      width, height: INTEGER;
      xres: REAL := 147.781818; (* in pixels per inch *)
      yres: REAL := 147.961165; (* in pixels per inch *)
    METHODS
      get (h, v: INTEGER): Pixel;
      set (h, v: INTEGER; pixel: Pixel);
    END;

When I do this, my pixmaps look correct on the 1920x1200 display!!!!!



Now, the problem I am faced with is how to come up with a way that the code will work on any type of monitor.  I can't edit Image.i3 for every resolution and produce a different binary.  Any ideas?



Regards,

Randy


>>> Jay  8/5/2008 9:01 AM>>>


Randy, I'm pretty clueless here.
I don't do gui or graphics.
If anyone has a clue, please stand up.
If you can get us code to run, please do.
But I think I need multiple particularly configured machines too.

I'm curious what this code prints on the systems:

#include
#include

int main()
{
int pix_ver = { 0 };
int pix_hor = { 0 };
int mm_hor = { 0 };
int mm_ver = { 0 };
HWND hwnd = { 0 };
HDC hdc = { 0 };

hwnd = GetDesktopWindow();
hdc = GetDC(hwnd);
mm_hor = GetDeviceCaps(hdc, HORZSIZE);
mm_ver = GetDeviceCaps(hdc, VERTSIZE);
pix_hor = GetSystemMetrics(SM_CXSCREEN);
pix_ver = GetSystemMetrics(SM_CYSCREEN);

printf("horizonal pixels %d\n", pix_hor);
printf("veritical pixels SM_CYSCREEN %d\n", pix_ver);
printf("horizontal millimeters %d\n", mm_hor);
printf("veritical millimeters %d\n", mm_ver);

printf("horizontal pixels per millimeter %f\n", (((float) pix_hor) / ((float) mm_hor)));
printf("vertical pixels per millimeter %f\n", (((float) pix_ver) / ((float) mm_ver)));

printf("horizontal pixels per inch %f\n", (((float) pix_hor) / ((float) mm_hor) * 10.0 * 2.54));
printf("vertical pixels per inch %f\n", (((float) pix_ver) / ((float) mm_ver) * 10.0 * 2.54));

return 0;
}


for me:

$ gcc dpi.c -luser32 -lgdi32

jay at jay-win9 /dev2/j/dpi
$ ./a
horizonal pixels 1280
veritical pixels SM_CYSCREEN 800
horizontal millimeters 384
veritical millimeters 240
horizontal pixels per millimeter 3.333333
vertical pixels per millimeter 3.333333
horizontal pixels per inch 84.666667
vertical pixels per inch 84.666667

(Visual C++ is fine:
cl dpi.c user32.lib gdi32.lib
.\dpi
)

I wonder if lying in this code:

Searching for 'GetDeviceCaps'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(25): VAR res := NEW(T); n_colors := GetDeviceCaps (WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(32): res.depth := GetDeviceCaps(WinGDI.BITSPIXEL); (* John Karnak 8/3/98 *)
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(68): mm_hor = GetDeviceCaps (WinGDI.HORZSIZE),
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(69): mm_ver = GetDeviceCaps (WinGDI.VERTSIZE) DO

Searching for 'res.res[Axis.T.'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(71): res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(72): res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);


D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(89):PROCEDURE GetDeviceCaps (cap: Ctypes.int): INTEGER =
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(93): res := WinGDI.GetDeviceCaps (hdc, cap);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(98): END GetDeviceCaps;
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnColorMap.m3(268): cnt := WinGDI.GetDeviceCaps (hdc, WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnFont.m3(316): LogicalPixelsPerVertInch := WinGDI.GetDeviceCaps(er.hdc, WinGDI.LOGPIXELSY);
9 occurrence(s) have been found.


Searching for '1000.0'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(463): bmih.biXPelsPerMeter := ROUND (st.res[Axis.T.Hor] * 1000.0);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(464): bmih.biYPelsPerMeter := ROUND (st.res[Axis.T.Ver] * 1000.0);


and just claiming 96dpi is the way to go.
Can you try that??


Specifically try setting res.res[Axis.T.Hor] and .Ver to 3.779527559055118.
Or heck to 3.3333 like my laptop has.


Or maybe claiming ignorance and setting biXPelsPerMeter and biYPelsPerMeter to 0???
Claiming ignorance feels better than lying of course. :)

Hm, so throw in also:

printf("LogicalPixelsX %u\n", GetDeviceCaps(hdc, LOGPIXELSX));
printf("LogicalPixelsY %u\n", GetDeviceCaps(hdc, LOGPIXELSY));

I get the magic number 96.

- Jay




From rcoleburn at scires.com  Sat Aug  9 07:48:15 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Sat, 09 Aug 2008 01:48:15 -0400
Subject: [M3devel] pixmap problem (! big success !)
In-Reply-To: <COL101-W49AB1574C557B5343D724DE6740@phx.gbl>
References: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>
	<489B5023.1E75.00D7.1@scires.com>
	<COL101-W279710F3EF9B814B1DA853E6740@phx.gbl>
	<489B5A5F.1E75.00D7.1@scires.com>
	<COL101-W76DCEA23FC2EA0FD299A3DE6740@phx.gbl>
	<489B7025.1E75.00D7.1@scires.com>
	<COL101-W49AB1574C557B5343D724DE6740@phx.gbl>
Message-ID: <489CF759.1E75.00D7.1@scires.com>

Jay:
 
Thanks so much for your work on this issue!!!  In my sleep-deprived state I didn't think of switching these fields to be "accessor-based."
 
I've tested your changes and they seem to work fine for me.  I've rebuilt all of cm3 just to make sure there were no compile-time errors.
 
I also had to adjust my scroll bar implementation on Windows to scale the scroll bar slider.  (The slider was not a pixmap and was being drawn based on a default size in millimeters.  Since the arrow buttons at the top and bottom of the scroll bar are pixmaps, I had to ensure the slider and margins didn't exceed the width of these pixmaps.)  Your procedures in ImageInit made this easy for me.  The revised code is now checked into the repository.
 
I probably need to make the same fix to the slider in the Posix implementation, but since we aren't yet dealing with resolution differences on Posix, maybe it doesn't matter for now.  Also, there are no arrow buttons on the Posix scroll bar, so it will probably be okay to just let the slider be the default width in millimeters.  The reason I had trouble on Windows was that the slider was wider than the arrow pixmaps when rendered on the hi-res display.
 
After reflecting on your comments and discussion, I will volunteer with your kind permission to adjust your Image.i3/Image.m3 implementation to be "more in the spirit of Modula-3".  Namely, I do think it makes sense to make these fields truly opaque so that access must be governed by the methods.  I feel pretty good about the fact that your change didn't break any of the rest of the code in the cm3 tree, so I think there will be few, if any, code breaks in other client code.
 
Also, I did notice that in ImageInit.m3 you declare a global var "init" but never assign the default value of "FALSE" to this variable before it is tested in the two procedures.  Shouldn't this be set to FALSE, or are you relying on something of which I'm unaware?  
 
Also, in ImageInit.m3 you call WinNT.MemoryBarrier().  I looked in the WinNT.i3 file, but there is no comment describing this function.  I'm unfamiliar with this function, so I would welcome any explanation you can offer as to what it does.
 
As for pickles, I don't see how any of your changes would break pickles.  The pickler should still be able to pickle these types.  Of course, anyone who is using pickles will need to recompile to see the new format, but there should not be any source code changes required.
 
I also need to thank Daniel for cluing us into the pixmap scaling problem in the first place by pointing out the xres/yres constants of 75.0.
 
At some point, I do think it makes sense to make a similar set of fixes on Posix because I'm sure that the 75 dpi is not going to be accurate for most modern displays.  Of course, we will need to find a way to come up with the right value in a platform-independent way.
 
Regards,
Randy

>>> Jay <jayk123 at hotmail.com> 8/8/2008 10:05 AM >>>

I committed a possible fix here.
Please see how it fairs.

I have a few Modula-3 questions related to the fix.

- Did I have to expose the functions in the .i3 file
  that implement the methods? That seems "wrong".


   - Could I have used "stronger language opacity" instead
    of "informal privacy"? That is, could I have used an
    opaque type?

   - Will the change break pickles?
     "Both" due to the addition of data "or" methods?
     ie: What breaks pickles?
     Do I need to think in the mindset of
      C:
       typedef struct {
         int a,b;
       } foo_t;

       foo_t f;
       fwrite(&f, sizeof(f), 1, file);

      and not breaking such code? 
     Only if the type is "branded"? Or if types derived from it are branded?
        There could be derived types not in the cm3 tree though.
        How much do we care about breaking code outside the cm3 tree?
        e.g. in this change, I had to change every use of .xres and .yres.
       I did that, but only in the code "we have". There could be more out there.
       Personally, I get quite frustrated by this issue. I'm very willng to "fix"
        and maybe test pretty large amounts of code -- pay the price for fixing things with
        "breaking" changes, or else not make the change, but if I don't have the code, I can't.

  If this breaks pickles, I can restate the fix in a slightly "weaker" way,
    that has some risk of missing code paths, but will likely suffice.

    That is, initialize to a distinguished value like 0 or -1
     and get rid of the booleans. And, i necessary for pickling,
     put the fields back out in "public".


The name of the ImageInit module, I wonder what it should be.


   - Jay
     


________________________________

Date: Thu, 7 Aug 2008 21:59:07 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com; jayk123 at hotmail.com; dabenavidesd at yahoo.es 
Subject: RE: [M3devel] pixmap problem (some success)



Jay,



The splash screen is not the major issue.  The pixmaps used for boolean choices, radio choices, numerics, etc. get enlarged to the point that some windows won't fit on the screen.  Also, it looks really bad--like both a first-grader with a big marker and a college-student with a fine tip pencil worked on the same window.



I've tried very hard to make Trestle/FormsVBT look and act like Windows GUI, but it is indeed different.  For example, on menus, you have to hold down the mouse to keep the menu open.  All these were small issues 10 years ago, but now they seem to be looming large in the customer's mind.



So, bottom line is that if I can't fix what they deem to be functional problems, they will indeed call for a rewrite.



Now that we've got the typein problem solved (thanks Olaf) and are on track for the pixmap issue, I feel better.  I have recently discovered that the numeric keys on the numeric keypad aren't accepted, so I have yet to track that problem down.



As for your idea of using a variable as the default initializer for xres/yres, this is not legal Modula-3.  You will get a compile error that the default is not constant.  Otherwise, it was a good idea.



Since Raw is an object and objects are created dynamically and new subtypes can be created (inheritance), I think the problem of how to properly set xres/yres is complicated.



Seems like what we need is some way to adjust these fields when the object is created initially.  Alas, Raw does not have an init() method!



Regards,

Randy

>>> Jay  8/7/2008 9:35 PM>>>

Computing the values is probably easy. It appears we already have the code to do that -- the program I had you run and report the numbers.

It is true there is a *small* problem of computing them early enough, but..yeah, I expect that's just done in the module initializer. I really don't like "global initialization" code ala C++ global constructors/destructors, but Modula-3 is rife with them and they aren't going away, so I'll just pile in a few more bits.

I don't know if is legal Modula-3 code, but if fields can be initialized from globals, that's about all it takes.

SOMETHING LIKE (don't castigate me where I am wrong)
In the platform-independent code, add two private globals:
DefaultXRes : INTEGER;
DefaultYRes : INTEGER;

heck, default them to 75, for the Posix case.

In the platform independent interface, functions to set them:
PROCEDURE SetDefaultXRes(a: INTEGER);
PROCEDURE SetDefaultYRes(a: INTEGER);

Nothing else on Posix, for now.

On Windows, add another module WinImage.m3 that imports Image and just has a module initializer:

BEGIN
  Image.SetDefaultXRes(ComputedSomehowNotDifficult());
  Image.SetDefaultYRes(ComputedSomehowNotDifficult());
END.

If fields cannot be initialized from globals (or function calls..heh, that has a niceness!), then you have to search out all the uses and change them to function calls, possibly a lot, possibly tedious, definitely a "breaking change", but probably just fine, really.

And then, if fields can be initialized from functions, that'd be better -- that way no module initializer.


Module initializers are "bad" in that they cause a startup cost for "everyone", even if they aren't needed for a particular scenario. It is "best" imho to have constant initialization as much as possible, and where values must be computed, use an explicit function call when needed. You can still cache the values upon first computation.


> would seem that most code must not be computing these, but relying on the default values to be correct.

Or that "most code" doesn't care what the values are, doesn't use them at all.
Like, maybe they are only used for pixmaps and not text or lines?

Anyway, I can't look into this now, but hopefully "soon".
If your customer is antsy, "the problem is mostly understood and a fix will definitely be available soon".
I think "patch Tuesday" is coming up. Let's make it by then? :)


Really, I can't believe they'd call for a rewrite over this small issue.
Presumably they really want the rewrite and are looking for any excuse they can find.
Also, if you removed the "advertising" from the splash screen, they might not have even noticed?
Or, I guess if this is Windows only, the odd look could not be noticed.
But if they also want it on X and you showed it there, and it looked the same on Windows, well...
(Really this is just a general dilemna -- app looks the same as app on all platforms, or app looks like the platform on all platforms.)


- Jay

________________________________

Date: Thu, 7 Aug 2008 20:26:13 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com; jayk123 at hotmail.com; dabenavidesd at yahoo.es 
Subject: RE: [M3devel] pixmap problem (some success)



Well, I hope to soon share your optimism for "easy".



Since these numbers wind up being default values for the xres/yres and since changing the defaults has made a big difference in the results, it would seem that most code must not be computing these, but relying on the default values to be correct.



Since these numbers may be different for every program run on a different monitor (potentially), the question becomes how to effect a change that will work in all cases without having to recompile vbtkit.



Does this mean we have to track down each use of Image.Raw and put in code to compute the dpi?  Or is there some way we can do this during an initialization sequence? but alas, how to deal with the defaults supplied in the declaration?



Regards,

Randy

>>> Jay  8/7/2008 8:16 PM>>>

Awesome. I expect it is easy from here. Thanks David!

I *assume* the 75 should have been 86 in the one case,
but close enough that nobody noticed.
So these numbers come pretty directly from the GetDeviceCaps / GetSystemMetrics.

And then X Windows too.
Does anyone have a high DPI monitor running X Windows?
Probably easy enough to do this blind.

I'm trying to ignore the fact that systems have multiple
monitors, with varying dpi. You are supposed to loop your
drawing over monitors and compute what it looks like per-monitor.
I'm just making that up, right? :)

- Jay

________________________________

Date: Thu, 7 Aug 2008 19:42:33 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com; jayk123 at hotmail.com; dabenavidesd at yahoo.es 
Subject: Re: [M3devel] pixmap problem (some success)



Ok, I solved the Microsoft problem.



Here are the results on Dell M4300 at 1920x1200:



horizonal pixels 1920
veritical pixels SM_CYSCREEN 1200
horizontal millimeters 330
veritical millimeters 206
horizontal pixels per millimeter 5.818182
vertical pixels per millimeter 5.825243
horizontal pixels per inch 147.781818
vertical pixels per inch 147.961165

Wow!  these numbers are radically different than the IBM T60 at 1280x1024:



horizonal pixels 1280
veritical pixels SM_CYSCREEN 1024
horizontal millimeters 375
veritical millimeters 300
horizontal pixels per millimeter 3.413333
vertical pixels per millimeter 3.413333
horizontal pixels per inch 86.698667
vertical pixels per inch 86.698667

Now, if you look at the Windows dpi setting for the 1920x1200 machine, it says 96dpi, but this is in the General tab of the Display properties Advanced settings.  I suspect this is just the dpi setting applied to fonts.



I tried plugging the numbers into Image.i3 as suggested by Daniel:

TYPE
  Raw = OBJECT
      width, height: INTEGER;
      xres: REAL := 147.781818; (* in pixels per inch *)
      yres: REAL := 147.961165; (* in pixels per inch *)
    METHODS
      get (h, v: INTEGER): Pixel;
      set (h, v: INTEGER; pixel: Pixel);
    END;

When I do this, my pixmaps look correct on the 1920x1200 display!!!!!



Now, the problem I am faced with is how to come up with a way that the code will work on any type of monitor.  I can't edit Image.i3 for every resolution and produce a different binary.  Any ideas?



Regards,

Randy


>>> Jay  8/5/2008 9:01 AM>>>


Randy, I'm pretty clueless here.
I don't do gui or graphics.
If anyone has a clue, please stand up.
If you can get us code to run, please do.
But I think I need multiple particularly configured machines too.

I'm curious what this code prints on the systems:

#include
#include

int main()
{
int pix_ver = { 0 };
int pix_hor = { 0 };
int mm_hor = { 0 };
int mm_ver = { 0 };
HWND hwnd = { 0 };
HDC hdc = { 0 };

hwnd = GetDesktopWindow();
hdc = GetDC(hwnd);
mm_hor = GetDeviceCaps(hdc, HORZSIZE);
mm_ver = GetDeviceCaps(hdc, VERTSIZE);
pix_hor = GetSystemMetrics(SM_CXSCREEN);
pix_ver = GetSystemMetrics(SM_CYSCREEN);

printf("horizonal pixels %d\n", pix_hor);
printf("veritical pixels SM_CYSCREEN %d\n", pix_ver);
printf("horizontal millimeters %d\n", mm_hor);
printf("veritical millimeters %d\n", mm_ver);

printf("horizontal pixels per millimeter %f\n", (((float) pix_hor) / ((float) mm_hor)));
printf("vertical pixels per millimeter %f\n", (((float) pix_ver) / ((float) mm_ver)));

printf("horizontal pixels per inch %f\n", (((float) pix_hor) / ((float) mm_hor) * 10.0 * 2.54));
printf("vertical pixels per inch %f\n", (((float) pix_ver) / ((float) mm_ver) * 10.0 * 2.54));

return 0;
}


for me:

$ gcc dpi.c -luser32 -lgdi32

jay at jay-win9 /dev2/j/dpi
$ ./a
horizonal pixels 1280
veritical pixels SM_CYSCREEN 800
horizontal millimeters 384
veritical millimeters 240
horizontal pixels per millimeter 3.333333
vertical pixels per millimeter 3.333333
horizontal pixels per inch 84.666667
vertical pixels per inch 84.666667

(Visual C++ is fine:
cl dpi.c user32.lib gdi32.lib
.\dpi
)

I wonder if lying in this code:

Searching for 'GetDeviceCaps'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(25): VAR res := NEW(T); n_colors := GetDeviceCaps (WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(32): res.depth := GetDeviceCaps(WinGDI.BITSPIXEL); (* John Karnak 8/3/98 *)
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(68): mm_hor = GetDeviceCaps (WinGDI.HORZSIZE),
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(69): mm_ver = GetDeviceCaps (WinGDI.VERTSIZE) DO

Searching for 'res.res[Axis.T.'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(71): res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(72): res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);


D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(89):PROCEDURE GetDeviceCaps (cap: Ctypes.int): INTEGER =
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(93): res := WinGDI.GetDeviceCaps (hdc, cap);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(98): END GetDeviceCaps;
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnColorMap.m3(268): cnt := WinGDI.GetDeviceCaps (hdc, WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnFont.m3(316): LogicalPixelsPerVertInch := WinGDI.GetDeviceCaps(er.hdc, WinGDI.LOGPIXELSY);
9 occurrence(s) have been found.


Searching for '1000.0'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(463): bmih.biXPelsPerMeter := ROUND (st.res[Axis.T.Hor] * 1000.0);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(464): bmih.biYPelsPerMeter := ROUND (st.res[Axis.T.Ver] * 1000.0);


and just claiming 96dpi is the way to go.
Can you try that??


Specifically try setting res.res[Axis.T.Hor] and .Ver to 3.779527559055118.
Or heck to 3.3333 like my laptop has.


Or maybe claiming ignorance and setting biXPelsPerMeter and biYPelsPerMeter to 0???
Claiming ignorance feels better than lying of course. :)

Hm, so throw in also:

printf("LogicalPixelsX %u\n", GetDeviceCaps(hdc, LOGPIXELSX));
printf("LogicalPixelsY %u\n", GetDeviceCaps(hdc, LOGPIXELSY));

I get the magic number 96.

- Jay



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080809/00e22eca/attachment-0001.html>

From rodney.bates at wichita.edu  Sat Aug  9 17:45:45 2008
From: rodney.bates at wichita.edu (Rodney M. Bates)
Date: Sat, 09 Aug 2008 10:45:45 -0500
Subject: [M3devel] pixmap problem (some success)
In-Reply-To: <COL101-W49AB1574C557B5343D724DE6740@phx.gbl>
References: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>
	<489B5023.1E75.00D7.1@scires.com>
	<COL101-W279710F3EF9B814B1DA853E6740@phx.gbl>
	<489B5A5F.1E75.00D7.1@scires.com>
	<COL101-W76DCEA23FC2EA0FD299A3DE6740@phx.gbl>
	<489B7025.1E75.00D7.1@scires.com>
	<COL101-W49AB1574C557B5343D724DE6740@phx.gbl>
Message-ID: <489DBBA9.8020109@wichita.edu>



Jay wrote:
> I committed a possible fix here.
> Please see how it fairs.
> 
> I have a few Modula-3 questions related to the fix.
> 
>  - Did I have to expose the functions in the .i3 file
>   that implement the methods? That seems "wrong".
> 
> 
>    - Could I have used "stronger language opacity" instead
>     of "informal privacy"? That is, could I have used an
>     opaque type?

I have a number of comments on this.
Here are 3 examples of different styles of coding in Modula-3.

---------------------------------------------------------------------------------
INTERFACE M1
; TYPE T <: REFANY
; PROCEDURE Op ( Arg : T )
; END M1 .

MODULE M1
; REVEAL T = BRANDED REF RECORD (
                * Fields of T, hidden from clients. *)
              END (* T *)
; PROCEDURE Op ( Arg : T ) = (* A body that uses the fields of T. *)
; BEGIN END M1 .

; MODULE Client1 EXPORTS Main
; IMPORT M1
; VAR Obj := NEW ( M1 . T )
; BEGIN
     M1 . Op ( Obj )
   END Client1 .

I would call this the _abstract data type_ style.  It uses a plain procedure Op,
not a method.  The type T is opaque in the interface, so clients can manipulate
values of it only by calling Op (and, presumably, other procedures whose signatures
would also be given in the interface).

-------------------------------------------------------------------------------
INTERFACE M2
; TYPE T <: Public
; TYPE Public = OBJECT METHODS op ( ) (* No default method body given here. *)
                 END (* Public *)
; END M2 .

MODULE M2
; REVEAL T = Public BRANDED OBJECT (* Same fields as M1.T. *)
                     OVERRIDES op := Op (* Provide the method body for op. *)
                     END (* T *)
; PROCEDURE Op ( Arg : T ) = (* Pretty much the same as M1.Op, maybe even exactly. *)
; BEGIN END M2 .

; MODULE Client2 EXPORTS Main
; IMPORT M2
; VAR Obj : M2 . T := NEW ( M2 . T )
; BEGIN
     Obj . op ( )
   END Client2 .

This is the OO style.  The operation is an overridable method.  Clients can still
manipulate objects of type T only by using the operation op, but here, op is a
method, not a procedure, so they must use a method call.  It will dispatch, but
without further code, it will always dispatch to M2.Op.

But, if client code were to:
1) declare a subtype Sub, of M2.T,
2) which has a method override for op, say procedure OpSub,
3) provide OpSub,
4) then allocate an object of type Sub,
5) but assign this object to variable Client2.Obj (whose type is M2.T, not Sub),
then the method call Obj.op() would dispatch to OpSub.

-------------------------------------------------------------------------------
Here is a side point that I think is confusing about Modula-3 opaque types.  At least
it took me years to fully understand.  The same subtype mechanism is used in Modula-3
in two different ways.  One is for creating a hierarchy of dynamically typed objects.
This is the usual OO use.  The other is in opaque types.  When used in the usual way,
actual objects of opaque type Public are never allocated.  Public is only a static
structure to hold the subset of the properties of type T that are known everywhere.

When you execute NEW(M2.T), you get a complete object of type T, with all its fields and
method overrides, even though you are in a context where these are not known.  In a
sense, these things are hidden only from the programmer of this client code.  But the
compiler may have to know at least some of the hidden information at the site of the
NEW call.

(Actually, through clever implementation techniques, I think the compiler needs to
know at most the size of fully revealed type T and could probably do without that.
The messages about recompiling modules because of new opaque info are, I am sure,
the compiler generating better code by using revelations it didn't have the first time.)

-------------------------------------------------------------------------------
INTERFACE M3
; TYPE T <: Public
; TYPE Public = OBJECT METHODS op ( )
                                := Op (* Specify the body of op, here in the interface. *)
                 END (* Public *)
; PROCEDURE Op ( Arg : T ) = (* A body that uses the fields of T. *)
; END M3 .

MODULE M3
; REVEAL T = Public BRANDED OBJECT (* Same fields as M1.T and M2.T. *)
                     (* No override for op needed. Its body was already
                        given in type Public. *)
                     END T
; PROCEDURE Op ( Arg : T ) = (* Pretty much the same as M1.Op. *)
; BEGIN END M3 .

; MODULE Client3 EXPORTS Main
; IMPORT M3
; VAR Obj := NEW ( M3 . T )
; BEGIN
     Obj . op ( )
   ; M3 . Op ( Obj )
   END Client3 .

This is a hybrid.  Still opaque, as before.  But a client can either call plain
procedure M3.Op, which will be statically known to always invoke Op, or a method
call on op, which might  dispatch to Op or OpSub, if the latter exists.

------------------------------------------------------------------------------------
An OO purist would say that every programmer-defined type should be opaque, hiding its
fields, and that every operation should always be a method, in case some later code
has a need to create a subtype and override the methods.

The problem with (dispatching) methods is it makes tracking down bugs a nightmare.  The
whole abstraction idea works great when designing one layer at a time, or even testing
one layer at a time.  But when you have a specific bug, you can't do it a layer at a time.
You often have to trace, mentally or with actual execution, in and out of the calls and
returns, through the layers.

If you see a procedure call, it is statically known and quite direct, at least in a
modular language, to find the code that is called.  Every time you see a method call,
there is a big tangential process to try to figure out if there are overrides, what
subtype the object might be, etc., and the results may be dynamic.  This can make an
otherwise sstraightforward process extremely tedious.

I am a strong believer in using methods when there is a good reason, i.e., you know
or reasonably suspect there will be a need to actually create overrides and have
nontrivial dispatching happen.  Otherwise, stick to static procedure calls.  The
pickle code, for example, uses methods all over the place.  Nearly all of them always
dispatch to exactly one place, but for each such, it takes a lot of work to ascertain
this.  It is very hard code to vet.

-------------------------------------------------------------------------------------
The hybrid approach, perhaps surprisingly, is sometimes very useful.  For example,
you have a complex tree with several node types that are different subtypes of a
common parent node type.  In some places, you have a node pointer that could be
any of the subtypes.  Then you would want to make a method call.  In other places,
you already know exactly what type node you have, perhaps because you are inside
a TYPECASE or a procedure that was already dispatched-to.  Here, I prefer to use
a non-dispatching call.  Aside from saving a tiny bit of runtime overhead for the
dispatch (which is minor), you avoid the debug problem above.


> 
>    - Will the change break pickles?
>      "Both" due to the addition of data "or" methods?
>      ie: What breaks pickles?
>      Do I need to think in the mindset of
>       C:
>        typedef struct {
>          int a,b;
>        } foo_t;
> 
>        foo_t f;
>        fwrite(&f, sizeof(f), 1, file);
> 
>       and not breaking such code? 
>      Only if the type is "branded"? Or if types derived from it are branded?
>         There could be derived types not in the cm3 tree though.
>         How much do we care about breaking code outside the cm3 tree?
>         e.g. in this change, I had to change every use of .xres and .yres

If by "break pickles" you mean invalidating existing pickle _data_ that was written
before the change, then yes.  When reading an object from a pickle, the reading
program must contain a type that is exactly the same type as was used to write
the object.  So if the program that reads the pickle is recompiled after the change,
then existing pickle data will have to be rewritten.

A change to anything that is a property of a type, according to the rules of
the language, will cause this.  For example, changes in brandedness, changes in
the string value of the brand, or, probably, the use of an anonymous brand would
all change the type.  Note that the full revelation of any opaque type is required
by the language to be branded, though not necessarily with a string value.

Also, note that the names of fields are part of a record or object type, so
changing .xres to a different name will invalidate existing pickle data.  This
does not necessarily mean it's a bad idea.

On the other hand, if you are willing/able to recompile and rerun both the program
that writes and the program that reads the pickle data, such changes will work fine.
Neither the source code in the Pickle library nor its client code will break.

We definitely do care about breaking code outside the cm3 tree.  Randy's application
would be a good example.  So removing functions, constants, etc. just because they
are unused in cm3 would not be good.  Nor would merging differently-named things,
just because they always have the same properties in cm3, because they could have
different properties in other code.


-- 
-------------------------------------------------------------
Rodney M. Bates, retired assistant professor
Dept. of Computer Science, Wichita State University
Wichita, KS 67260-0083
316-978-3922
rodney.bates at wichita.edu


From jayk123 at hotmail.com  Sat Aug  9 20:41:36 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 9 Aug 2008 18:41:36 +0000
Subject: [M3devel] pixmap problem (some success)
In-Reply-To: <489DBBA9.8020109@wichita.edu>
References: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>
	<489B5023.1E75.00D7.1@scires.com>
	<COL101-W279710F3EF9B814B1DA853E6740@phx.gbl>
	<489B5A5F.1E75.00D7.1@scires.com>
	<COL101-W76DCEA23FC2EA0FD299A3DE6740@phx.gbl>
	<489B7025.1E75.00D7.1@scires.com>
	<COL101-W49AB1574C557B5343D724DE6740@phx.gbl> 
	<489DBBA9.8020109@wichita.edu>
Message-ID: <COL101-W25A5930EE4E6CFB7E6BA7AE6770@phx.gbl>


Thanks Rodney, good summary. I have been "almost aware" of much of this.I didn't think you could derive from opaque types for some reason.
So I instead relied on "gentleman's agreement", naming things "private".
Like how Modula-3 doesn't have constructors, but relies on people to call "init".Randy, go ahead and change what you want. I don't like red tape myself.
  You're welcome and definitely thanks to David.
Regarding pickles, are we to consider all types as likely to be pickled?
And therefore we are very stuck unable to change?Or only branded types? Or ...?
Or we don't believe people build up significant investment in pickle files
and can throw them all away upon rebuilding their code from current source?
 
This change could be restarted without breaking pickles.
As it is currently stated, it deliberately breaks existing code in order to
be certain the fix works, to be absolutely sure the wrong values aren't used.
That is, I didn't want to rely on any particular preexisting function call
being made before the values are read. There is no way to do that
given the "fully unprotected" form that was there before.
 
Agreed -- layering is great for design, and "agility" (ability to change),
but more code = more bugs, more code = more code to read when debugging,
more code = more code to understand when maintaining.
 
I don't think you need to know the size of things at the NEW site.
In a general "if I were designing the system" sense, not in the
"I know how Modula-3 works" (I don't yet).
NEW(T) could include within it a function call, or global read, to get the size of T.
Or heck, NEW(T) could call a function that passes the size on to
the next level down.
That is, in C, it could look like one of:
 
original code:
client:
 T* t = NEW(T) 
 
option 1 - function call
client:
T* t = (T*) malloc(GetSizeOfT());
 
implementation:
size_T GetSizeOfT() { return 42; }
 
option 2 - global read 
client:
T* t = (T*) malloc(SizeOfT);
 
implementation:
extern const SizeOfT = 42;
 
option 3 - 
client:
T* t = NewT();
 
implementation:
T* NewT(void) { return (T*) malloc(sizeof(T)); }
 
The compiler could go back later and recompile things to
client, or sometimes it could do this the first time:
t = (T*) malloc(sizeof(T));
 
Though option 3 potentially generates smaller code, if there are
many places that make a T.
This is just the usual "inlining can bloat code size" point.
"Make functions out of frequently occuring blocks of code
to reduce code size".
 
Option 3 becomes "better" as there are more used default
field initializers.
That is:
T = RECORD
  a := 1; b:= 2; c:=3; d:=4;e:=5;f:=6;
END;
 
If there are lots of NEW(T), without
replacements for the initial values (not sure you can do that,
but I think so), then one function to call malloc and fill in
all the values could be a win over inlining the initialization
everywhere, due to code size.
 
Code size is usually important for performance.
You want the code to be small to fit in cache.
And to reduce the cost of paging it in.
 
 - Jay> Date: Sat, 9 Aug 2008 10:45:45 -0500> From: rodney.bates at wichita.edu> To: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem (some success)> > > > Jay wrote:> > I committed a possible fix here.> > Please see how it fairs.> > > > I have a few Modula-3 questions related to the fix.> > > > - Did I have to expose the functions in the .i3 file> > that implement the methods? That seems "wrong".> > > > > > - Could I have used "stronger language opacity" instead> > of "informal privacy"? That is, could I have used an> > opaque type?> > I have a number of comments on this.> Here are 3 examples of different styles of coding in Modula-3.> > ---------------------------------------------------------------------------------> INTERFACE M1> ; TYPE T <: REFANY> ; PROCEDURE Op ( Arg : T )> ; END M1 .> > MODULE M1> ; REVEAL T = BRANDED REF RECORD (> * Fields of T, hidden from clients. *)> END (* T *)> ; PROCEDURE Op ( Arg : T ) = (* A body that uses the fields of T. *)> ; BEGIN END M1 .> > ; MODULE Client1 EXPORTS Main> ; IMPORT M1> ; VAR Obj := NEW ( M1 . T )> ; BEGIN> M1 . Op ( Obj )> END Client1 .> > I would call this the _abstract data type_ style. It uses a plain procedure Op,> not a method. The type T is opaque in the interface, so clients can manipulate> values of it only by calling Op (and, presumably, other procedures whose signatures> would also be given in the interface).> > -------------------------------------------------------------------------------> INTERFACE M2> ; TYPE T <: Public> ; TYPE Public = OBJECT METHODS op ( ) (* No default method body given here. *)> END (* Public *)> ; END M2 .> > MODULE M2> ; REVEAL T = Public BRANDED OBJECT (* Same fields as M1.T. *)> OVERRIDES op := Op (* Provide the method body for op. *)> END (* T *)> ; PROCEDURE Op ( Arg : T ) = (* Pretty much the same as M1.Op, maybe even exactly. *)> ; BEGIN END M2 .> > ; MODULE Client2 EXPORTS Main> ; IMPORT M2> ; VAR Obj : M2 . T := NEW ( M2 . T )> ; BEGIN> Obj . op ( )> END Client2 .> > This is the OO style. The operation is an overridable method. Clients can still> manipulate objects of type T only by using the operation op, but here, op is a> method, not a procedure, so they must use a method call. It will dispatch, but> without further code, it will always dispatch to M2.Op.> > But, if client code were to:> 1) declare a subtype Sub, of M2.T,> 2) which has a method override for op, say procedure OpSub,> 3) provide OpSub,> 4) then allocate an object of type Sub,> 5) but assign this object to variable Client2.Obj (whose type is M2.T, not Sub),> then the method call Obj.op() would dispatch to OpSub.> > -------------------------------------------------------------------------------> Here is a side point that I think is confusing about Modula-3 opaque types. At least> it took me years to fully understand. The same subtype mechanism is used in Modula-3> in two different ways. One is for creating a hierarchy of dynamically typed objects.> This is the usual OO use. The other is in opaque types. When used in the usual way,> actual objects of opaque type Public are never allocated. Public is only a static> structure to hold the subset of the properties of type T that are known everywhere.> > When you execute NEW(M2.T), you get a complete object of type T, with all its fields and> method overrides, even though you are in a context where these are not known. In a> sense, these things are hidden only from the programmer of this client code. But the> compiler may have to know at least some of the hidden information at the site of the> NEW call.> > (Actually, through clever implementation techniques, I think the compiler needs to> know at most the size of fully revealed type T and could probably do without that.> The messages about recompiling modules because of new opaque info are, I am sure,> the compiler generating better code by using revelations it didn't have the first time.)> > -------------------------------------------------------------------------------> INTERFACE M3> ; TYPE T <: Public> ; TYPE Public = OBJECT METHODS op ( )> := Op (* Specify the body of op, here in the interface. *)> END (* Public *)> ; PROCEDURE Op ( Arg : T ) = (* A body that uses the fields of T. *)> ; END M3 .> > MODULE M3> ; REVEAL T = Public BRANDED OBJECT (* Same fields as M1.T and M2.T. *)> (* No override for op needed. Its body was already> given in type Public. *)> END T> ; PROCEDURE Op ( Arg : T ) = (* Pretty much the same as M1.Op. *)> ; BEGIN END M3 .> > ; MODULE Client3 EXPORTS Main> ; IMPORT M3> ; VAR Obj := NEW ( M3 . T )> ; BEGIN> Obj . op ( )> ; M3 . Op ( Obj )> END Client3 .> > This is a hybrid. Still opaque, as before. But a client can either call plain> procedure M3.Op, which will be statically known to always invoke Op, or a method> call on op, which might dispatch to Op or OpSub, if the latter exists.> > ------------------------------------------------------------------------------------> An OO purist would say that every programmer-defined type should be opaque, hiding its> fields, and that every operation should always be a method, in case some later code> has a need to create a subtype and override the methods.> > The problem with (dispatching) methods is it makes tracking down bugs a nightmare. The> whole abstraction idea works great when designing one layer at a time, or even testing> one layer at a time. But when you have a specific bug, you can't do it a layer at a time.> You often have to trace, mentally or with actual execution, in and out of the calls and> returns, through the layers.> > If you see a procedure call, it is statically known and quite direct, at least in a> modular language, to find the code that is called. Every time you see a method call,> there is a big tangential process to try to figure out if there are overrides, what> subtype the object might be, etc., and the results may be dynamic. This can make an> otherwise sstraightforward process extremely tedious.> > I am a strong believer in using methods when there is a good reason, i.e., you know> or reasonably suspect there will be a need to actually create overrides and have> nontrivial dispatching happen. Otherwise, stick to static procedure calls. The> pickle code, for example, uses methods all over the place. Nearly all of them always> dispatch to exactly one place, but for each such, it takes a lot of work to ascertain> this. It is very hard code to vet.> > -------------------------------------------------------------------------------------> The hybrid approach, perhaps surprisingly, is sometimes very useful. For example,> you have a complex tree with several node types that are different subtypes of a> common parent node type. In some places, you have a node pointer that could be> any of the subtypes. Then you would want to make a method call. In other places,> you already know exactly what type node you have, perhaps because you are inside> a TYPECASE or a procedure that was already dispatched-to. Here, I prefer to use> a non-dispatching call. Aside from saving a tiny bit of runtime overhead for the> dispatch (which is minor), you avoid the debug problem above.> > > > > > - Will the change break pickles?> > "Both" due to the addition of data "or" methods?> > ie: What breaks pickles?> > Do I need to think in the mindset of> > C:> > typedef struct {> > int a,b;> > } foo_t;> > > > foo_t f;> > fwrite(&f, sizeof(f), 1, file);> > > > and not breaking such code? > > Only if the type is "branded"? Or if types derived from it are branded?> > There could be derived types not in the cm3 tree though.> > How much do we care about breaking code outside the cm3 tree?> > e.g. in this change, I had to change every use of .xres and .yres> > If by "break pickles" you mean invalidating existing pickle _data_ that was written> before the change, then yes. When reading an object from a pickle, the reading> program must contain a type that is exactly the same type as was used to write> the object. So if the program that reads the pickle is recompiled after the change,> then existing pickle data will have to be rewritten.> > A change to anything that is a property of a type, according to the rules of> the language, will cause this. For example, changes in brandedness, changes in> the string value of the brand, or, probably, the use of an anonymous brand would> all change the type. Note that the full revelation of any opaque type is required> by the language to be branded, though not necessarily with a string value.> > Also, note that the names of fields are part of a record or object type, so> changing .xres to a different name will invalidate existing pickle data. This> does not necessarily mean it's a bad idea.> > On the other hand, if you are willing/able to recompile and rerun both the program> that writes and the program that reads the pickle data, such changes will work fine.> Neither the source code in the Pickle library nor its client code will break.> > We definitely do care about breaking code outside the cm3 tree. Randy's application> would be a good example. So removing functions, constants, etc. just because they> are unused in cm3 would not be good. Nor would merging differently-named things,> just because they always have the same properties in cm3, because they could have> different properties in other code.> > > -- > -------------------------------------------------------------> Rodney M. Bates, retired assistant professor> Dept. of Computer Science, Wichita State University> Wichita, KS 67260-0083> 316-978-3922> rodney.bates at wichita.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080809/86c51ed0/attachment-0001.html>

From rcoleburn at scires.com  Mon Aug 11 21:23:17 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Mon, 11 Aug 2008 15:23:17 -0400
Subject: [M3devel] strange problem w/new Image/ImageInit
In-Reply-To: <COL101-W13606B4823978F6670D3C9E6710@phx.gbl>
References: <489FAA38.1E75.00D7.1@scires.com>
	<COL101-W158F68823847D036260F0FE6710@phx.gbl>
	<48A02D67.1E75.00D7.1@scires.com>
	<COL101-W13606B4823978F6670D3C9E6710@phx.gbl>
Message-ID: <48A05960.1E75.00D7.1@scires.com>

Jay:
 
I have been experimenting quite a bit and I've come up with some "new old" information.
 
I say "new old" because, after spending the time to read some of the comments in the original code (before we modified it), I think I now have a better idea of what the designers intended and why I had/have a problem.
 
If you read carefully, the xres/yres fields in Image.Raw are supposed to represent the resolution at which the pixmap was originally DEVELOPED, not the resolution of the current screen.  It seems the designers went to great lengths to represent everything as screen-independent until it is actually rendered.  
 
The Image interface gives 3 ways of dealing with pixmaps:  (1) unscaled, (2) scaled, and (3) scaled to "most appropriate".  The change you and I conspired actually changes this behavior to make #2 (scaled) work as #1 (unscaled).  (It probably also changes #3.)  This is the behavior I want for my current program, but it changes the intent of the original interface, so I'm afraid we are going to have to revert all those changes.
 
Digging deeper into Image.m3, I've discovered that it is smart-enough already to deduce the screen resolution.  If you look into the ApplyScaled1 procedure, you see that it converts the current screen resolution in millimeters to pixels in order to scale the pixmap.  The change we introduced, namely making Raw.xres/yres equal to the current screen resolution, effectively caused the Scaled procedure to do nothing since (ScreenDPI / ImageDPI) = 1.
 
The problem that brought all this on in the first place is that my GUI was looking bad on the 1920x1200 screen.  The reason I have discovered *now* is that FormsVBT apparently uses the #2 (scaled) version for pixmaps.  In the old code, the interface defaulted the developed resolution of the pixmaps to be 75 dpi.  At my 147+ dpi screen, the scaled implementation would effectively double the size of the pixmap when rendered on the screen in an effort to make the pixmap look the same size on the 147dpi screen that it appeared on a 75 dpi screen.
 
All of this to say that the changes to Image.i3/m3 need to be undone in order to get back the original intent of the developers.
 
Of course, once these changes are undone, my problem returns with the GUI looking bad on 1920x1200 at 147+ dpi.  So, how to solve it properly now requires more thought.
 
I need to do some more reading of the code I guess to see if there is a way already to cause FormsVBT to use unscaled for all pixmaps.  Otherwise, a quick fix would be to add a new procedure to the interface that would force use of the unscaled implementation.
 
Now, back to the problem of not being able to drag the subwindows, I'm still puzzled.  To test my "understanding" as related above, I went back to the original Image.i3/m3, but this time changed the Scaled procedure to effectively do the same thing as Unscaled.  The pixmaps render fine on the 1920x1200 monitor, but the subwindows still can't be dragged.  If I back out my change to Scaled (effectively, revert to the original Image.m3), the subwindows drag with ease on the 1920x1200 monitor, but of course the pixmaps look bad.  I can't explain this behavior yet.  Any ideas?
 
Regards,
Randy

>>> Jay <jay.krell at cornell.edu> 8/11/2008 2:41 PM >>>

MemoryBarrier ensures that all the reads and writes before it finish before any reads and writes after it.
Look at winnt.h or MSDN, as well the comment I put in explains it.
It probably has no effect, since our compiler is not aggressive.
What is confusing in these cases is the compiler and processor both need to be informed.
There is a concurrency issue and the barrier should make extra certain to solve it.

Multiple monitors are not considered.
Do you have them?

Randy, please experiment.
Change the code to return hard coded numbers -- like the old 75.
   Either without the globals, or initialize the globals.
And then add in the the various calls one at a time, ignoring their return values.  

Furthermore, I guess you could just say:

    IF xres = 0 THEN Init() END;

and

    IF yres = 0 THEN Init() END;

and maybe change the globals to INTEGER.
Though REAL should be 32 bits and be written atomatically.

The idea is, even if the code does run multiple times concurrently, it should always return the same information.

Anyway, like I said, try various or every combination between the two and find
out which part triggers the difference, then we can think more about just that.

I might be able to get an expert friend to give me some help, later.

- Jay


________________________________

Date: Mon, 11 Aug 2008 12:15:40 -0400
From: rcoleburn at scires.com 
To: jay.krell at cornell.edu 
CC: wagner at elegosoft.com 
Subject: RE: strange problem w/new Image/ImageInit



Jay:



I tested your change, but it has no effect on the problem I am having.  I also tried having the accessor functions just return a hardcoded number, but again, no effect on the problem.  This is real strange to me, because if I remove ImageInit and revert Image.i3/m3 back to the way it was before, the problem disappears.



Questions,

1.  What does the WinNT.MemoryBarrier() call do?

2.  What would happen if this code was run by multiple threads?  Are there any concurrency issues that need to be guarded?

3.  What would happen in the case of multiple monitors at different resolutions?



Regards,

Randy

>>> Jay  8/11/2008 6:46 AM>>>

Also try the change I just commited with ReleaseDC.

- Jay


> From: jayk123 at hotmail.com 
> To: rcoleburn at scires.com 
> CC: wagner at elegosoft.com 
> Subject: RE: strange problem w/new Image/ImageInit
> Date: Mon, 11 Aug 2008 07:51:52 +0000
>
>
> Randy, this makes no sense to me.
> What happens if you just hardcode the numbers instead of computing them?
>
>
> - Jay
>
>
>
>
>
>
> ________________________________
>
>
>
> Date: Mon, 11 Aug 2008 02:55:56 -0400
> From: rcoleburn at scires.com 
> To: jayk123 at hotmail.com 
> CC: Olaf Wagner


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080811/ead5acd5/attachment-0001.html>

From jay.krell at cornell.edu  Mon Aug 11 21:52:52 2008
From: jay.krell at cornell.edu (Jay)
Date: Mon, 11 Aug 2008 19:52:52 +0000
Subject: [M3devel] strange problem w/new Image/ImageInit
In-Reply-To: <48A05960.1E75.00D7.1@scires.com>
References: <489FAA38.1E75.00D7.1@scires.com>
	<COL101-W158F68823847D036260F0FE6710@phx.gbl>
	<48A02D67.1E75.00D7.1@scires.com>
	<COL101-W13606B4823978F6670D3C9E6710@phx.gbl> 
	<48A05960.1E75.00D7.1@scires.com>
Message-ID: <COL101-W65ECE9C2B48E275288EAF0E6710@phx.gbl>


Hm. Ok then, where does it get the screen resolution from?

Probably here?

WinScreenType.m3:

PROCEDURE InnerNew ((* IN-OUT *) res: T) =
  BEGIN
    WITH pix_hor = WinUser.GetSystemMetrics(WinUser.SM_CXSCREEN),
         pix_ver = WinUser.GetSystemMetrics(WinUser.SM_CYSCREEN),
         mm_hor  = GetDeviceCaps (WinGDI.HORZSIZE),
         mm_ver  = GetDeviceCaps (WinGDI.VERTSIZE) DO
      res.rootDom := Rect.FromSize(pix_hor, pix_ver);
      res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
      res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);

ok.

Perhaps we should accept the numbers that Windows makes up instead?

GetDeviceCaps(LOGPIXELSX)
and GetDeviceCaps(LOGPIXELSY)

Please try that, in the WinScreenType.m3 code.
With removing ImageInit (or just have it hardcoded at 75).

This will most likely be 96 even on your high dpi system, unless you are on Vista
and tell the system you are high dpi aware.

I think there is disagreement in drawing vs. hit test as to where you are clicking.
Try making ImageInit always 75.
Try making the above convert from a hardcoded 96.
And then try GetDeviceCaps(LOGPIXELSX and Y) -- which I expect always returns 96 for you.
You can plug that into my dpi.c to see what it prints.

I think part of what is happening is that Modula-3 was very rare in doing the right thing for high dpi
monitors. But so much code is wrong that Windows has to counteract the wrongness,
which means Modula-3 needs to go along and do things wrong in order for the counteraction
to leave it doing the right thing also.
I'm not sure.
Oh, and presumably other places in Modula-3 are wrong, and the counteraction works for them.
That's a bit of a mystery -- drawing of pixmaps vs. drawing of everything else.

 - Jay


________________________________

Date: Mon, 11 Aug 2008 15:23:17 -0400
From: rcoleburn at scires.com
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com; wagner at elegosoft.com
Subject: RE: strange problem w/new Image/ImageInit



Jay:



I have been experimenting quite a bit and I've come up with some "new old" information.



I say "new old" because, after spending the time to read some of the comments in the original code (before we modified it), I think I now have a better idea of what the designers intended and why I had/have a problem.



If you read carefully, the xres/yres fields in Image.Raw are supposed to represent the resolution at which the pixmap was originally DEVELOPED, not the resolution of the current screen.  It seems the designers went to great lengths to represent everything as screen-independent until it is actually rendered.



The Image interface gives 3 ways of dealing with pixmaps:  (1) unscaled, (2) scaled, and (3) scaled to "most appropriate".  The change you and I conspired actually changes this behavior to make #2 (scaled) work as #1 (unscaled).  (It probably also changes #3.)  This is the behavior I want for my current program, but it changes the intent of the original interface, so I'm afraid we are going to have to revert all those changes.



Digging deeper into Image.m3, I've discovered that it is smart-enough already to deduce the screen resolution.  If you look into the ApplyScaled1 procedure, you see that it converts the current screen resolution in millimeters to pixels in order to scale the pixmap.  The change we introduced, namely making Raw.xres/yres equal to the current screen resolution, effectively caused the Scaled procedure to do nothing since (ScreenDPI / ImageDPI) = 1.



The problem that brought all this on in the first place is that my GUI was looking bad on the 1920x1200 screen.  The reason I have discovered *now* is that FormsVBT apparently uses the #2 (scaled) version for pixmaps.  In the old code, the interface defaulted the developed resolution of the pixmaps to be 75 dpi.  At my 147+ dpi screen, the scaled implementation would effectively double the size of the pixmap when rendered on the screen in an effort to make the pixmap look the same size on the 147dpi screen that it appeared on a 75 dpi screen.



All of this to say that the changes to Image.i3/m3 need to be undone in order to get back the original intent of the developers.



Of course, once these changes are undone, my problem returns with the GUI looking bad on 1920x1200 at 147+ dpi.  So, how to solve it properly now requires more thought.



I need to do some more reading of the code I guess to see if there is a way already to cause FormsVBT to use unscaled for all pixmaps.  Otherwise, a quick fix would be to add a new procedure to the interface that would force use of the unscaled implementation.



Now, back to the problem of not being able to drag the subwindows, I'm still puzzled.  To test my "understanding" as related above, I went back to the original Image.i3/m3, but this time changed the Scaled procedure to effectively do the same thing as Unscaled.  The pixmaps render fine on the 1920x1200 monitor, but the subwindows still can't be dragged.  If I back out my change to Scaled (effectively, revert to the original Image.m3), the subwindows drag with ease on the 1920x1200 monitor, but of course the pixmaps look bad.  I can't explain this behavior yet.  Any ideas?



Regards,

Randy

>>> Jay  8/11/2008 2:41 PM>>>

MemoryBarrier ensures that all the reads and writes before it finish before any reads and writes after it.
Look at winnt.h or MSDN, as well the comment I put in explains it.
It probably has no effect, since our compiler is not aggressive.
What is confusing in these cases is the compiler and processor both need to be informed.
There is a concurrency issue and the barrier should make extra certain to solve it.

Multiple monitors are not considered.
Do you have them?

Randy, please experiment.
Change the code to return hard coded numbers -- like the old 75.
   Either without the globals, or initialize the globals.
And then add in the the various calls one at a time, ignoring their return values.

Furthermore, I guess you could just say:

    IF xres = 0 THEN Init() END;

and

    IF yres = 0 THEN Init() END;

and maybe change the globals to INTEGER.
Though REAL should be 32 bits and be written atomatically.

The idea is, even if the code does run multiple times concurrently, it should always return the same information.

Anyway, like I said, try various or every combination between the two and find
out which part triggers the difference, then we can think more about just that.

I might be able to get an expert friend to give me some help, later.

- Jay


________________________________

Date: Mon, 11 Aug 2008 12:15:40 -0400
From: rcoleburn at scires.com
To: jay.krell at cornell.edu
CC: wagner at elegosoft.com
Subject: RE: strange problem w/new Image/ImageInit



Jay:



I tested your change, but it has no effect on the problem I am having.  I also tried having the accessor functions just return a hardcoded number, but again, no effect on the problem.  This is real strange to me, because if I remove ImageInit and revert Image.i3/m3 back to the way it was before, the problem disappears.



Questions,

1.  What does the WinNT.MemoryBarrier() call do?

2.  What would happen if this code was run by multiple threads?  Are there any concurrency issues that need to be guarded?

3.  What would happen in the case of multiple monitors at different resolutions?



Regards,

Randy

>>> Jay  8/11/2008 6:46 AM>>>

Also try the change I just commited with ReleaseDC.

- Jay


> From: jayk123 at hotmail.com
> To: rcoleburn at scires.com
> CC: wagner at elegosoft.com
> Subject: RE: strange problem w/new Image/ImageInit
> Date: Mon, 11 Aug 2008 07:51:52 +0000
>
>
> Randy, this makes no sense to me.
> What happens if you just hardcode the numbers instead of computing them?
>
>
> - Jay
>
>
>
>
>
>
> ________________________________
>
>
>
> Date: Mon, 11 Aug 2008 02:55:56 -0400
> From: rcoleburn at scires.com
> To: jayk123 at hotmail.com
> CC: Olaf Wagner




From rcoleburn at scires.com  Tue Aug 12 10:25:11 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Tue, 12 Aug 2008 04:25:11 -0400
Subject: [M3devel] strange problem w/new Image/ImageInit
In-Reply-To: <COL101-W65ECE9C2B48E275288EAF0E6710@phx.gbl>
References: <489FAA38.1E75.00D7.1@scires.com>
	<COL101-W158F68823847D036260F0FE6710@phx.gbl>
	<48A02D67.1E75.00D7.1@scires.com>
	<COL101-W13606B4823978F6670D3C9E6710@phx.gbl>
	<48A05960.1E75.00D7.1@scires.com>
	<COL101-W65ECE9C2B48E275288EAF0E6710@phx.gbl>
Message-ID: <48A110A3.1E75.00D7.1@scires.com>

Jay:
 
For LOGPIXELS X & Y, I get 96 on the hi-res Dell M4300 system and also on my ThinkPad T60.
 
I've put together revised versions of Image.i3/m3 and my ScrollerVBTClass.m3.  The good news is that I've managed to get the scroll bar to look correct in both scaled and unscaled modes.  
 
I've added a new procedure to Image.i3/m3 that will force subsequent calls to Scaled() to behave like Unscaled().  Using this, I can get the appearance I need on the hi-res monitor without resorting to changes in the original intent of the Image interface.  The advantage of this procedure is that it does not change the Image interface (except for addition of the procedure) and it therefore won't have any affect on pickles or anyone else's code.  Plus, it lets the programmer override use of Scaled() in all library modules without having to modify any source code.
 
Before I commit any of these changes, I want to do some more testing and to fix the problem with subwindows (ZChassisVBT) not being able to move.
 
Alas, my problem of the ZChassisVBTs not being able to move on the hi-res monitor persists with these changes, even though I left the xres/yres at 75.  Of course, these numbers are ignored for Unscaled images anyway.
 
I'm at a loss to explain this behavior.  Here is what I know based on testing:
1.  Using Scaled images and Image.Raw.xres/yres = 75.0, ZChassisVBT movement works on the hi-res monitor.
2.  Using Scaled images and Image.Raw.xres/yres set to 86.xxx or to 147.xxx, ZChassisVBT movement does not work on the hi-res 147.xxx dpi monitor, but it still works on my 86.xxx dpi monitor
3.  Using Unscaled images, ZChassisVBT movement does not work on the hi-res 147.xxx dpi monitor, but it still works on my 86.xxx dpi monitor
 
So, there seems to be something in the implementation somewhere of ZChassisVBT, or maybe ZMoveVBT, that doesn't like 147.xxx dpi monitors unless you scale all images assuming they were designed at 75 dpi.  At the 147 dpi, the 75 dpi pixmaps will be scaled by a factor of 2, which corresponds to what I am seeing on the screen.
 
I'm too sleepy to make any more progress for now.  If anyone has an idea on what to do next, please let me know.  I'm stumped at this point.
 
Regards,
Randy

>>> Jay <jay.krell at cornell.edu> 8/11/2008 3:52 PM >>>

Hm. Ok then, where does it get the screen resolution from?

Probably here?

WinScreenType.m3:

PROCEDURE InnerNew ((* IN-OUT *) res: T) =
  BEGIN
    WITH pix_hor = WinUser.GetSystemMetrics(WinUser.SM_CXSCREEN),
         pix_ver = WinUser.GetSystemMetrics(WinUser.SM_CYSCREEN),
         mm_hor  = GetDeviceCaps (WinGDI.HORZSIZE),
         mm_ver  = GetDeviceCaps (WinGDI.VERTSIZE) DO
      res.rootDom := Rect.FromSize(pix_hor, pix_ver);
      res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
      res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);

ok.

Perhaps we should accept the numbers that Windows makes up instead?

GetDeviceCaps(LOGPIXELSX)
and GetDeviceCaps(LOGPIXELSY)

Please try that, in the WinScreenType.m3 code.
With removing ImageInit (or just have it hardcoded at 75).

This will most likely be 96 even on your high dpi system, unless you are on Vista
and tell the system you are high dpi aware.

I think there is disagreement in drawing vs. hit test as to where you are clicking.
Try making ImageInit always 75.
Try making the above convert from a hardcoded 96.
And then try GetDeviceCaps(LOGPIXELSX and Y) -- which I expect always returns 96 for you.
You can plug that into my dpi.c to see what it prints.

I think part of what is happening is that Modula-3 was very rare in doing the right thing for high dpi
monitors. But so much code is wrong that Windows has to counteract the wrongness,
which means Modula-3 needs to go along and do things wrong in order for the counteraction
to leave it doing the right thing also.
I'm not sure.
Oh, and presumably other places in Modula-3 are wrong, and the counteraction works for them.
That's a bit of a mystery -- drawing of pixmaps vs. drawing of everything else.

- Jay


________________________________

Date: Mon, 11 Aug 2008 15:23:17 -0400
From: rcoleburn at scires.com 
To: jay.krell at cornell.edu 
CC: m3devel at elegosoft.com; wagner at elegosoft.com 
Subject: RE: strange problem w/new Image/ImageInit



Jay:



I have been experimenting quite a bit and I've come up with some "new old" information.



I say "new old" because, after spending the time to read some of the comments in the original code (before we modified it), I think I now have a better idea of what the designers intended and why I had/have a problem.



If you read carefully, the xres/yres fields in Image.Raw are supposed to represent the resolution at which the pixmap was originally DEVELOPED, not the resolution of the current screen.  It seems the designers went to great lengths to represent everything as screen-independent until it is actually rendered.



The Image interface gives 3 ways of dealing with pixmaps:  (1) unscaled, (2) scaled, and (3) scaled to "most appropriate".  The change you and I conspired actually changes this behavior to make #2 (scaled) work as #1 (unscaled).  (It probably also changes #3.)  This is the behavior I want for my current program, but it changes the intent of the original interface, so I'm afraid we are going to have to revert all those changes.



Digging deeper into Image.m3, I've discovered that it is smart-enough already to deduce the screen resolution.  If you look into the ApplyScaled1 procedure, you see that it converts the current screen resolution in millimeters to pixels in order to scale the pixmap.  The change we introduced, namely making Raw.xres/yres equal to the current screen resolution, effectively caused the Scaled procedure to do nothing since (ScreenDPI / ImageDPI) = 1.



The problem that brought all this on in the first place is that my GUI was looking bad on the 1920x1200 screen.  The reason I have discovered *now* is that FormsVBT apparently uses the #2 (scaled) version for pixmaps.  In the old code, the interface defaulted the developed resolution of the pixmaps to be 75 dpi.  At my 147+ dpi screen, the scaled implementation would effectively double the size of the pixmap when rendered on the screen in an effort to make the pixmap look the same size on the 147dpi screen that it appeared on a 75 dpi screen.



All of this to say that the changes to Image.i3/m3 need to be undone in order to get back the original intent of the developers.



Of course, once these changes are undone, my problem returns with the GUI looking bad on 1920x1200 at 147+ dpi.  So, how to solve it properly now requires more thought.



I need to do some more reading of the code I guess to see if there is a way already to cause FormsVBT to use unscaled for all pixmaps.  Otherwise, a quick fix would be to add a new procedure to the interface that would force use of the unscaled implementation.



Now, back to the problem of not being able to drag the subwindows, I'm still puzzled.  To test my "understanding" as related above, I went back to the original Image.i3/m3, but this time changed the Scaled procedure to effectively do the same thing as Unscaled.  The pixmaps render fine on the 1920x1200 monitor, but the subwindows still can't be dragged.  If I back out my change to Scaled (effectively, revert to the original Image.m3), the subwindows drag with ease on the 1920x1200 monitor, but of course the pixmaps look bad.  I can't explain this behavior yet.  Any ideas?



Regards,

Randy

>>> Jay  8/11/2008 2:41 PM>>>

MemoryBarrier ensures that all the reads and writes before it finish before any reads and writes after it.
Look at winnt.h or MSDN, as well the comment I put in explains it.
It probably has no effect, since our compiler is not aggressive.
What is confusing in these cases is the compiler and processor both need to be informed.
There is a concurrency issue and the barrier should make extra certain to solve it.

Multiple monitors are not considered.
Do you have them?

Randy, please experiment.
Change the code to return hard coded numbers -- like the old 75.
   Either without the globals, or initialize the globals.
And then add in the the various calls one at a time, ignoring their return values.

Furthermore, I guess you could just say:

    IF xres = 0 THEN Init() END;

and

    IF yres = 0 THEN Init() END;

and maybe change the globals to INTEGER.
Though REAL should be 32 bits and be written atomatically.

The idea is, even if the code does run multiple times concurrently, it should always return the same information.

Anyway, like I said, try various or every combination between the two and find
out which part triggers the difference, then we can think more about just that.

I might be able to get an expert friend to give me some help, later.

- Jay


________________________________

Date: Mon, 11 Aug 2008 12:15:40 -0400
From: rcoleburn at scires.com 
To: jay.krell at cornell.edu 
CC: wagner at elegosoft.com 
Subject: RE: strange problem w/new Image/ImageInit



Jay:



I tested your change, but it has no effect on the problem I am having.  I also tried having the accessor functions just return a hardcoded number, but again, no effect on the problem.  This is real strange to me, because if I remove ImageInit and revert Image.i3/m3 back to the way it was before, the problem disappears.



Questions,

1.  What does the WinNT.MemoryBarrier() call do?

2.  What would happen if this code was run by multiple threads?  Are there any concurrency issues that need to be guarded?

3.  What would happen in the case of multiple monitors at different resolutions?



Regards,

Randy

>>> Jay  8/11/2008 6:46 AM>>>

Also try the change I just commited with ReleaseDC.

- Jay


> From: jayk123 at hotmail.com 
> To: rcoleburn at scires.com 
> CC: wagner at elegosoft.com 
> Subject: RE: strange problem w/new Image/ImageInit
> Date: Mon, 11 Aug 2008 07:51:52 +0000
>
>
> Randy, this makes no sense to me.
> What happens if you just hardcode the numbers instead of computing them?
>
>
> - Jay
>
>
>
>
>
>
> ________________________________
>
>
>
> Date: Mon, 11 Aug 2008 02:55:56 -0400
> From: rcoleburn at scires.com 
> To: jayk123 at hotmail.com 
> CC: Olaf Wagner



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080812/e2ceef31/attachment-0001.html>

From jay.krell at cornell.edu  Tue Aug 12 12:49:18 2008
From: jay.krell at cornell.edu (Jay)
Date: Tue, 12 Aug 2008 10:49:18 +0000
Subject: [M3devel] strange problem w/new Image/ImageInit
In-Reply-To: <48A110A3.1E75.00D7.1@scires.com>
References: <489FAA38.1E75.00D7.1@scires.com>
	<COL101-W158F68823847D036260F0FE6710@phx.gbl>
	<48A02D67.1E75.00D7.1@scires.com>
	<COL101-W13606B4823978F6670D3C9E6710@phx.gbl>
	<48A05960.1E75.00D7.1@scires.com>
	<COL101-W65ECE9C2B48E275288EAF0E6710@phx.gbl> 
	<48A110A3.1E75.00D7.1@scires.com>
Message-ID: <COL101-W48D58C2FBDE5BCD3163650E6700@phx.gbl>


Randy I don't think you need to add a way to use the unscaled data.
I think the fix is
a) go back to Image hardcoding 75
b) Have WinScreenType hardcode 96 or use GetDeviceCaps(LOGPIXELSX Y) -- same thing really.
And then see what happens.

Basically, the scale of pixmaps and the scale of screens has always been close to 1:1.
75:96, close enough.
Therefore, unscaled has been the norm.

Most GUI code uses GetDeviceCaps(LOGPIXELSX Y) I believe.
However, most code is not prepared to get back anything other than 96 from it.

Modula-3, at least for the pixmap code, was computing LOGPIXELSX and Y via a seemingly redundant equivalent way.
However, my believe is that LOGPIXELSX and Y is forced to lie, but the other route is not.
It seems an arbitrary discprecancy, but not beyond imagination.

By switching to the lying method, we will get back the nearly unscaled 75:96 behavior.

Vista adds a way for an application to declare that it is "high dpi aware", which then makes GetDeviceCaps(LOGPIXELX and Y) report the truth presumably. You can see, by the very existance of this ability to declare that you are high dpi aware -- to declare that your code is merely correct -- that most code is not correct.

What remains to be determined is why Modula-3 pixmaps behave "differently" than Modula-3 buttons, text, etc.

I also think there is a likely disconnect between painting and hit testing, but this is gross speculation.
I should fiddle with the numbers myself.

I will go ahead with a+b fairly soon.
I will verify the numbers computed in #b before and after.
I don't have any high dpi systems, so I expect the numbers to be roughly the same either way.
I think the only systems that will see a change are high dpi, and they will see an improvement.

Sorry for the back and forth regarding ImageInit -- a medium size change is going to be completely undone.

 - Jay

________________________________

Date: Tue, 12 Aug 2008 04:25:11 -0400
From: rcoleburn at scires.com
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] strange problem w/new Image/ImageInit



Jay:



For LOGPIXELS X & Y, I get 96 on the hi-res Dell M4300 system and also on my ThinkPad T60.



I've put together revised versions of Image.i3/m3 and my ScrollerVBTClass.m3.  The good news is that I've managed to get the scroll bar to look correct in both scaled and unscaled modes.



I've added a new procedure to Image.i3/m3 that will force subsequent calls to Scaled() to behave like Unscaled().  Using this, I can get the appearance I need on the hi-res monitor without resorting to changes in the original intent of the Image interface.  The advantage of this procedure is that it does not change the Image interface (except for addition of the procedure) and it therefore won't have any affect on pickles or anyone else's code.  Plus, it lets the programmer override use of Scaled() in all library modules without having to modify any source code.



Before I commit any of these changes, I want to do some more testing and to fix the problem with subwindows (ZChassisVBT) not being able to move.



Alas, my problem of the ZChassisVBTs not being able to move on the hi-res monitor persists with these changes, even though I left the xres/yres at 75.  Of course, these numbers are ignored for Unscaled images anyway.



I'm at a loss to explain this behavior.  Here is what I know based on testing:

1.  Using Scaled images and Image.Raw.xres/yres = 75.0, ZChassisVBT movement works on the hi-res monitor.

2.  Using Scaled images and Image.Raw.xres/yres set to 86.xxx or to 147.xxx, ZChassisVBT movement does not work on the hi-res 147.xxx dpi monitor, but it still works on my 86.xxx dpi monitor

3.  Using Unscaled images, ZChassisVBT movement does not work on the hi-res 147.xxx dpi monitor, but it still works on my 86.xxx dpi monitor



So, there seems to be something in the implementation somewhere of ZChassisVBT, or maybe ZMoveVBT, that doesn't like 147.xxx dpi monitors unless you scale all images assuming they were designed at 75 dpi.  At the 147 dpi, the 75 dpi pixmaps will be scaled by a factor of 2, which corresponds to what I am seeing on the screen.



I'm too sleepy to make any more progress for now.  If anyone has an idea on what to do next, please let me know.  I'm stumped at this point.



Regards,

Randy

>>> Jay  8/11/2008 3:52 PM>>>

Hm. Ok then, where does it get the screen resolution from?

Probably here?

WinScreenType.m3:

PROCEDURE InnerNew ((* IN-OUT *) res: T) =
  BEGIN
    WITH pix_hor = WinUser.GetSystemMetrics(WinUser.SM_CXSCREEN),
         pix_ver = WinUser.GetSystemMetrics(WinUser.SM_CYSCREEN),
         mm_hor  = GetDeviceCaps (WinGDI.HORZSIZE),
         mm_ver  = GetDeviceCaps (WinGDI.VERTSIZE) DO
      res.rootDom := Rect.FromSize(pix_hor, pix_ver);
      res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
      res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);

ok.

Perhaps we should accept the numbers that Windows makes up instead?

GetDeviceCaps(LOGPIXELSX)
and GetDeviceCaps(LOGPIXELSY)

Please try that, in the WinScreenType.m3 code.
With removing ImageInit (or just have it hardcoded at 75).

This will most likely be 96 even on your high dpi system, unless you are on Vista
and tell the system you are high dpi aware.

I think there is disagreement in drawing vs. hit test as to where you are clicking.
Try making ImageInit always 75.
Try making the above convert from a hardcoded 96.
And then try GetDeviceCaps(LOGPIXELSX and Y) -- which I expect always returns 96 for you.
You can plug that into my dpi.c to see what it prints.

I think part of what is happening is that Modula-3 was very rare in doing the right thing for high dpi
monitors. But so much code is wrong that Windows has to counteract the wrongness,
which means Modula-3 needs to go along and do things wrong in order for the counteraction
to leave it doing the right thing also.
I'm not sure.
Oh, and presumably other places in Modula-3 are wrong, and the counteraction works for them.
That's a bit of a mystery -- drawing of pixmaps vs. drawing of everything else.

- Jay


________________________________

Date: Mon, 11 Aug 2008 15:23:17 -0400
From: rcoleburn at scires.com
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com; wagner at elegosoft.com
Subject: RE: strange problem w/new Image/ImageInit



Jay:



I have been experimenting quite a bit and I've come up with some "new old" information.



I say "new old" because, after spending the time to read some of the comments in the original code (before we modified it), I think I now have a better idea of what the designers intended and why I had/have a problem.



If you read carefully, the xres/yres fields in Image.Raw are supposed to represent the resolution at which the pixmap was originally DEVELOPED, not the resolution of the current screen.  It seems the designers went to great lengths to represent everything as screen-independent until it is actually rendered.



The Image interface gives 3 ways of dealing with pixmaps:  (1) unscaled, (2) scaled, and (3) scaled to "most appropriate".  The change you and I conspired actually changes this behavior to make #2 (scaled) work as #1 (unscaled).  (It probably also changes #3.)  This is the behavior I want for my current program, but it changes the intent of the original interface, so I'm afraid we are going to have to revert all those changes.



Digging deeper into Image.m3, I've discovered that it is smart-enough already to deduce the screen resolution.  If you look into the ApplyScaled1 procedure, you see that it converts the current screen resolution in millimeters to pixels in order to scale the pixmap.  The change we introduced, namely making Raw.xres/yres equal to the current screen resolution, effectively caused the Scaled procedure to do nothing since (ScreenDPI / ImageDPI) = 1.



The problem that brought all this on in the first place is that my GUI was looking bad on the 1920x1200 screen.  The reason I have discovered *now* is that FormsVBT apparently uses the #2 (scaled) version for pixmaps.  In the old code, the interface defaulted the developed resolution of the pixmaps to be 75 dpi.  At my 147+ dpi screen, the scaled implementation would effectively double the size of the pixmap when rendered on the screen in an effort to make the pixmap look the same size on the 147dpi screen that it appeared on a 75 dpi screen.



All of this to say that the changes to Image.i3/m3 need to be undone in order to get back the original intent of the developers.



Of course, once these changes are undone, my problem returns with the GUI looking bad on 1920x1200 at 147+ dpi.  So, how to solve it properly now requires more thought.



I need to do some more reading of the code I guess to see if there is a way already to cause FormsVBT to use unscaled for all pixmaps.  Otherwise, a quick fix would be to add a new procedure to the interface that would force use of the unscaled implementation.



Now, back to the problem of not being able to drag the subwindows, I'm still puzzled.  To test my "understanding" as related above, I went back to the original Image.i3/m3, but this time changed the Scaled procedure to effectively do the same thing as Unscaled.  The pixmaps render fine on the 1920x1200 monitor, but the subwindows still can't be dragged.  If I back out my change to Scaled (effectively, revert to the original Image.m3), the subwindows drag with ease on the 1920x1200 monitor, but of course the pixmaps look bad.  I can't explain this behavior yet.  Any ideas?



Regards,

Randy

>>> Jay  8/11/2008 2:41 PM>>>

MemoryBarrier ensures that all the reads and writes before it finish before any reads and writes after it.
Look at winnt.h or MSDN, as well the comment I put in explains it.
It probably has no effect, since our compiler is not aggressive.
What is confusing in these cases is the compiler and processor both need to be informed.
There is a concurrency issue and the barrier should make extra certain to solve it.

Multiple monitors are not considered.
Do you have them?

Randy, please experiment.
Change the code to return hard coded numbers -- like the old 75.
   Either without the globals, or initialize the globals.
And then add in the the various calls one at a time, ignoring their return values.

Furthermore, I guess you could just say:

    IF xres = 0 THEN Init() END;

and

    IF yres = 0 THEN Init() END;

and maybe change the globals to INTEGER.
Though REAL should be 32 bits and be written atomatically.

The idea is, even if the code does run multiple times concurrently, it should always return the same information.

Anyway, like I said, try various or every combination between the two and find
out which part triggers the difference, then we can think more about just that.

I might be able to get an expert friend to give me some help, later.

- Jay


________________________________

Date: Mon, 11 Aug 2008 12:15:40 -0400
From: rcoleburn at scires.com
To: jay.krell at cornell.edu
CC: wagner at elegosoft.com
Subject: RE: strange problem w/new Image/ImageInit



Jay:



I tested your change, but it has no effect on the problem I am having.  I also tried having the accessor functions just return a hardcoded number, but again, no effect on the problem.  This is real strange to me, because if I remove ImageInit and revert Image.i3/m3 back to the way it was before, the problem disappears.



Questions,

1.  What does the WinNT.MemoryBarrier() call do?

2.  What would happen if this code was run by multiple threads?  Are there any concurrency issues that need to be guarded?

3.  What would happen in the case of multiple monitors at different resolutions?



Regards,

Randy

>>> Jay  8/11/2008 6:46 AM>>>

Also try the change I just commited with ReleaseDC.

- Jay


> From: jayk123 at hotmail.com
> To: rcoleburn at scires.com
> CC: wagner at elegosoft.com
> Subject: RE: strange problem w/new Image/ImageInit
> Date: Mon, 11 Aug 2008 07:51:52 +0000
>
>
> Randy, this makes no sense to me.
> What happens if you just hardcode the numbers instead of computing them?
>
>
> - Jay
>
>
>
>
>
>
> ________________________________
>
>
>
> Date: Mon, 11 Aug 2008 02:55:56 -0400
> From: rcoleburn at scires.com
> To: jayk123 at hotmail.com
> CC: Olaf Wagner





From jay.krell at cornell.edu  Tue Aug 12 12:54:27 2008
From: jay.krell at cornell.edu (Jay)
Date: Tue, 12 Aug 2008 10:54:27 +0000
Subject: [M3devel] strange problem w/new Image/ImageInit
In-Reply-To: <48A110A3.1E75.00D7.1@scires.com>
References: <489FAA38.1E75.00D7.1@scires.com>
	<COL101-W158F68823847D036260F0FE6710@phx.gbl>
	<48A02D67.1E75.00D7.1@scires.com>
	<COL101-W13606B4823978F6670D3C9E6710@phx.gbl>
	<48A05960.1E75.00D7.1@scires.com>
	<COL101-W65ECE9C2B48E275288EAF0E6710@phx.gbl> 
	<48A110A3.1E75.00D7.1@scires.com> 
Message-ID: <COL101-W731093036BEC825D730370E6700@phx.gbl>


ps: Randy, does the high dpi system run XP or Vista?
I suppose I should try to acquire a high dpi system but I'd rather not waste the money.

(I'd rather waste on getting HP-UX/IA64/AIX/VMS systems to bring Modula-3 back up on them
and put out current releases. : )) (I have an Irix system, haven't powered it up yet.)

On Vista there is a way to get the "real" dpi via this same api.
You have to declare you are high dpi "aware".

 - Jay


From rcoleburn at scires.com  Tue Aug 12 17:01:23 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Tue, 12 Aug 2008 11:01:23 -0400
Subject: [M3devel] strange problem w/new Image/ImageInit
In-Reply-To: <COL101-W731093036BEC825D730370E6700@phx.gbl>
References: <489FAA38.1E75.00D7.1@scires.com>
	<COL101-W158F68823847D036260F0FE6710@phx.gbl>
	<48A02D67.1E75.00D7.1@scires.com>
	<COL101-W13606B4823978F6670D3C9E6710@phx.gbl>
	<48A05960.1E75.00D7.1@scires.com>
	<COL101-W65ECE9C2B48E275288EAF0E6710@phx.gbl>
	<48A110A3.1E75.00D7.1@scires.com>
	<COL101-W731093036BEC825D730370E6700@phx.gbl>
Message-ID: <48A16D7B.1E75.00D7.1@scires.com>

Jay:
 
I am running XP, not Vista.
 
Regards,
Randy

>>> Jay <jay.krell at cornell.edu> 8/12/2008 6:54 AM >>>

ps: Randy, does the high dpi system run XP or Vista?
I suppose I should try to acquire a high dpi system but I'd rather not waste the money.

(I'd rather waste on getting HP-UX/IA64/AIX/VMS systems to bring Modula-3 back up on them
and put out current releases. : )) (I have an Irix system, haven't powered it up yet.)

On Vista there is a way to get the "real" dpi via this same api.
You have to declare you are high dpi "aware".

- Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080812/d17ec5bd/attachment-0001.html>

From rcoleburn at scires.com  Tue Aug 12 17:51:25 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Tue, 12 Aug 2008 11:51:25 -0400
Subject: [M3devel] strange problem w/new Image/ImageInit
In-Reply-To: <COL101-W48D58C2FBDE5BCD3163650E6700@phx.gbl>
References: <489FAA38.1E75.00D7.1@scires.com>
	<COL101-W158F68823847D036260F0FE6710@phx.gbl>
	<48A02D67.1E75.00D7.1@scires.com>
	<COL101-W13606B4823978F6670D3C9E6710@phx.gbl>
	<48A05960.1E75.00D7.1@scires.com>
	<COL101-W65ECE9C2B48E275288EAF0E6710@phx.gbl>
	<48A110A3.1E75.00D7.1@scires.com>
	<COL101-W48D58C2FBDE5BCD3163650E6700@phx.gbl>
Message-ID: <48A17936.1E75.00D7.1@scires.com>

Jay:
 
Thanks for your insights here.  I'll try some more tests and see what I come up with.  I've attached my current Image.i3/Image.m3 and Win32/ScrollerVBTClass.m3 for your reference.  I've removed use of ImageInit from all of these.  And yes, I have reverted to the 75.0 hardcoded value.
 
Based on my limited understanding of the code, I still think I will get scaled behavior even if Modula-3 thinks the dpi is 96, because 147 / 96 =  1.53125, which rounds to 2.  So my pixmaps will still appear double-size.
 
In actuality, I think Modula-3 is trying to do the right thing with the scaling.  At some point on a high-enough dpi monitor, the pixmaps will be so tiny that you can't really see them if they are unscaled.  I've already observed this with some of my boolean and choice indicators--I had to reduce the shadowsize in order to tell whether the boolean/choice was TRUE or FALSE.  From the way Trestle/FormsVBT are set up, it appears that the designers wanted to get approximately the same size rendering on different dpi screens.  That's why you see millimeters everywhere in the code being converted to pixels.  Indeed, VBT has a procedure MMToPixels that is dependent on getting the screen type of the underlying VBT.T so it can get the ppm setting for this screen and do the computation.  Provided that the underlying implementation gives correct ppm info to Modula-3 for each screen, the current Trestle/FormsVBT should do the right thing even in multiple monitor situations.  I haven't tested this, but I should be able to drag a window from a monitor at one dpi onto a monitor at a different dpi and have everything scale to look correct on the new monitor.
 
The problem in my case with the 1920x1200 monitor is that the scaled pixmaps look huge in proportion to the text and other features of the window.  Maybe this other stuff isn't being scaled the same way pixmaps are scaled.
 
Does LOGPIXELSX stand for Logical Pixels X-Axis ?  I know that Windows has a dpi setting for fonts.  If set to normal, fonts are supposed to render at 96 dpi, but you can switch to large mode and have them rendered at 120 dpi, or you can make up a custom number.  This Windows setting applies only to fonts, not graphical elements.
 
You say that Modula-3 is computing LOGPIXELS via a "seemingly redundant equivalent way."  In my reading of the code in WinScreenType, it appears that Modula-3 is requesting from Windows the actual number of pixels in both axes and also the number of millimeters in both axes.  It uses these to compute the resolution in pixels per millimeter (ppm).  The ppm is what is stored and used internally when scaling pixmaps.  When necessary, ppm is converted to dpi using the formula (dpi = ppm x 25.4).
 
On my 4:3 aspect ratio IBM T60 at 1280x1024, the ppm is 3.41333 in both axes yielding a dpi of 86.698667.
 
On the widescreen (16:10 aspect ratio) Dell 4300 at 1920x1200 the ppm is slightly different in each axis, but is close to 5.8xxx yielding at dpi of 147.xxx  (again, the fractional part is different in each axis).
 
I don't mind running a test program for you on the hi-res system here--just send it to me via email.  I have the VC++ 2008 redistributables installed.
 
I think you are on the west coast and I'm on the east coast, so we have a time difference of 3 hours, but lately I've been working round the clock seemingly, so I'll try to respond with test results as soon as I can.
 
Regards,
Randy

>>> Jay <jay.krell at cornell.edu> 8/12/2008 6:49 AM >>>

Randy I don't think you need to add a way to use the unscaled data.
I think the fix is
a) go back to Image hardcoding 75
b) Have WinScreenType hardcode 96 or use GetDeviceCaps(LOGPIXELSX Y) -- same thing really.
And then see what happens.

Basically, the scale of pixmaps and the scale of screens has always been close to 1:1.
75:96, close enough.
Therefore, unscaled has been the norm.

Most GUI code uses GetDeviceCaps(LOGPIXELSX Y) I believe.
However, most code is not prepared to get back anything other than 96 from it.

Modula-3, at least for the pixmap code, was computing LOGPIXELSX and Y via a seemingly redundant equivalent way.
However, my believe is that LOGPIXELSX and Y is forced to lie, but the other route is not.
It seems an arbitrary discprecancy, but not beyond imagination.

By switching to the lying method, we will get back the nearly unscaled 75:96 behavior.

Vista adds a way for an application to declare that it is "high dpi aware", which then makes GetDeviceCaps(LOGPIXELX and Y) report the truth presumably. You can see, by the very existance of this ability to declare that you are high dpi aware -- to declare that your code is merely correct -- that most code is not correct.

What remains to be determined is why Modula-3 pixmaps behave "differently" than Modula-3 buttons, text, etc.

I also think there is a likely disconnect between painting and hit testing, but this is gross speculation.
I should fiddle with the numbers myself.

I will go ahead with a+b fairly soon.
I will verify the numbers computed in #b before and after.
I don't have any high dpi systems, so I expect the numbers to be roughly the same either way.
I think the only systems that will see a change are high dpi, and they will see an improvement.

Sorry for the back and forth regarding ImageInit -- a medium size change is going to be completely undone.

- Jay

________________________________

Date: Tue, 12 Aug 2008 04:25:11 -0400
From: rcoleburn at scires.com 
To: jay.krell at cornell.edu 
CC: m3devel at elegosoft.com 
Subject: Re: [M3devel] strange problem w/new Image/ImageInit



Jay:



For LOGPIXELS X & Y, I get 96 on the hi-res Dell M4300 system and also on my ThinkPad T60.



I've put together revised versions of Image.i3/m3 and my ScrollerVBTClass.m3.  The good news is that I've managed to get the scroll bar to look correct in both scaled and unscaled modes.



I've added a new procedure to Image.i3/m3 that will force subsequent calls to Scaled() to behave like Unscaled().  Using this, I can get the appearance I need on the hi-res monitor without resorting to changes in the original intent of the Image interface.  The advantage of this procedure is that it does not change the Image interface (except for addition of the procedure) and it therefore won't have any affect on pickles or anyone else's code.  Plus, it lets the programmer override use of Scaled() in all library modules without having to modify any source code.



Before I commit any of these changes, I want to do some more testing and to fix the problem with subwindows (ZChassisVBT) not being able to move.



Alas, my problem of the ZChassisVBTs not being able to move on the hi-res monitor persists with these changes, even though I left the xres/yres at 75.  Of course, these numbers are ignored for Unscaled images anyway.



I'm at a loss to explain this behavior.  Here is what I know based on testing:

1.  Using Scaled images and Image.Raw.xres/yres = 75.0, ZChassisVBT movement works on the hi-res monitor.

2.  Using Scaled images and Image.Raw.xres/yres set to 86.xxx or to 147.xxx, ZChassisVBT movement does not work on the hi-res 147.xxx dpi monitor, but it still works on my 86.xxx dpi monitor

3.  Using Unscaled images, ZChassisVBT movement does not work on the hi-res 147.xxx dpi monitor, but it still works on my 86.xxx dpi monitor



So, there seems to be something in the implementation somewhere of ZChassisVBT, or maybe ZMoveVBT, that doesn't like 147.xxx dpi monitors unless you scale all images assuming they were designed at 75 dpi.  At the 147 dpi, the 75 dpi pixmaps will be scaled by a factor of 2, which corresponds to what I am seeing on the screen.



I'm too sleepy to make any more progress for now.  If anyone has an idea on what to do next, please let me know.  I'm stumped at this point.



Regards,

Randy

>>> Jay  8/11/2008 3:52 PM>>>

Hm. Ok then, where does it get the screen resolution from?

Probably here?

WinScreenType.m3:

PROCEDURE InnerNew ((* IN-OUT *) res: T) =
  BEGIN
    WITH pix_hor = WinUser.GetSystemMetrics(WinUser.SM_CXSCREEN),
         pix_ver = WinUser.GetSystemMetrics(WinUser.SM_CYSCREEN),
         mm_hor  = GetDeviceCaps (WinGDI.HORZSIZE),
         mm_ver  = GetDeviceCaps (WinGDI.VERTSIZE) DO
      res.rootDom := Rect.FromSize(pix_hor, pix_ver);
      res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
      res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);

ok.

Perhaps we should accept the numbers that Windows makes up instead?

GetDeviceCaps(LOGPIXELSX)
and GetDeviceCaps(LOGPIXELSY)

Please try that, in the WinScreenType.m3 code.
With removing ImageInit (or just have it hardcoded at 75).

This will most likely be 96 even on your high dpi system, unless you are on Vista
and tell the system you are high dpi aware.

I think there is disagreement in drawing vs. hit test as to where you are clicking.
Try making ImageInit always 75.
Try making the above convert from a hardcoded 96.
And then try GetDeviceCaps(LOGPIXELSX and Y) -- which I expect always returns 96 for you.
You can plug that into my dpi.c to see what it prints.

I think part of what is happening is that Modula-3 was very rare in doing the right thing for high dpi
monitors. But so much code is wrong that Windows has to counteract the wrongness,
which means Modula-3 needs to go along and do things wrong in order for the counteraction
to leave it doing the right thing also.
I'm not sure.
Oh, and presumably other places in Modula-3 are wrong, and the counteraction works for them.
That's a bit of a mystery -- drawing of pixmaps vs. drawing of everything else.

- Jay


________________________________

Date: Mon, 11 Aug 2008 15:23:17 -0400
From: rcoleburn at scires.com 
To: jay.krell at cornell.edu 
CC: m3devel at elegosoft.com; wagner at elegosoft.com 
Subject: RE: strange problem w/new Image/ImageInit



Jay:



I have been experimenting quite a bit and I've come up with some "new old" information.



I say "new old" because, after spending the time to read some of the comments in the original code (before we modified it), I think I now have a better idea of what the designers intended and why I had/have a problem.



If you read carefully, the xres/yres fields in Image.Raw are supposed to represent the resolution at which the pixmap was originally DEVELOPED, not the resolution of the current screen.  It seems the designers went to great lengths to represent everything as screen-independent until it is actually rendered.



The Image interface gives 3 ways of dealing with pixmaps:  (1) unscaled, (2) scaled, and (3) scaled to "most appropriate".  The change you and I conspired actually changes this behavior to make #2 (scaled) work as #1 (unscaled).  (It probably also changes #3.)  This is the behavior I want for my current program, but it changes the intent of the original interface, so I'm afraid we are going to have to revert all those changes.



Digging deeper into Image.m3, I've discovered that it is smart-enough already to deduce the screen resolution.  If you look into the ApplyScaled1 procedure, you see that it converts the current screen resolution in millimeters to pixels in order to scale the pixmap.  The change we introduced, namely making Raw.xres/yres equal to the current screen resolution, effectively caused the Scaled procedure to do nothing since (ScreenDPI / ImageDPI) = 1.



The problem that brought all this on in the first place is that my GUI was looking bad on the 1920x1200 screen.  The reason I have discovered *now* is that FormsVBT apparently uses the #2 (scaled) version for pixmaps.  In the old code, the interface defaulted the developed resolution of the pixmaps to be 75 dpi.  At my 147+ dpi screen, the scaled implementation would effectively double the size of the pixmap when rendered on the screen in an effort to make the pixmap look the same size on the 147dpi screen that it appeared on a 75 dpi screen.



All of this to say that the changes to Image.i3/m3 need to be undone in order to get back the original intent of the developers.



Of course, once these changes are undone, my problem returns with the GUI looking bad on 1920x1200 at 147+ dpi.  So, how to solve it properly now requires more thought.



I need to do some more reading of the code I guess to see if there is a way already to cause FormsVBT to use unscaled for all pixmaps.  Otherwise, a quick fix would be to add a new procedure to the interface that would force use of the unscaled implementation.



Now, back to the problem of not being able to drag the subwindows, I'm still puzzled.  To test my "understanding" as related above, I went back to the original Image.i3/m3, but this time changed the Scaled procedure to effectively do the same thing as Unscaled.  The pixmaps render fine on the 1920x1200 monitor, but the subwindows still can't be dragged.  If I back out my change to Scaled (effectively, revert to the original Image.m3), the subwindows drag with ease on the 1920x1200 monitor, but of course the pixmaps look bad.  I can't explain this behavior yet.  Any ideas?



Regards,

Randy

>>> Jay  8/11/2008 2:41 PM>>>

MemoryBarrier ensures that all the reads and writes before it finish before any reads and writes after it.
Look at winnt.h or MSDN, as well the comment I put in explains it.
It probably has no effect, since our compiler is not aggressive.
What is confusing in these cases is the compiler and processor both need to be informed.
There is a concurrency issue and the barrier should make extra certain to solve it.

Multiple monitors are not considered.
Do you have them?

Randy, please experiment.
Change the code to return hard coded numbers -- like the old 75.
   Either without the globals, or initialize the globals.
And then add in the the various calls one at a time, ignoring their return values.

Furthermore, I guess you could just say:

    IF xres = 0 THEN Init() END;

and

    IF yres = 0 THEN Init() END;

and maybe change the globals to INTEGER.
Though REAL should be 32 bits and be written atomatically.

The idea is, even if the code does run multiple times concurrently, it should always return the same information.

Anyway, like I said, try various or every combination between the two and find
out which part triggers the difference, then we can think more about just that.

I might be able to get an expert friend to give me some help, later.

- Jay


________________________________

Date: Mon, 11 Aug 2008 12:15:40 -0400
From: rcoleburn at scires.com 
To: jay.krell at cornell.edu 
CC: wagner at elegosoft.com 
Subject: RE: strange problem w/new Image/ImageInit



Jay:



I tested your change, but it has no effect on the problem I am having.  I also tried having the accessor functions just return a hardcoded number, but again, no effect on the problem.  This is real strange to me, because if I remove ImageInit and revert Image.i3/m3 back to the way it was before, the problem disappears.



Questions,

1.  What does the WinNT.MemoryBarrier() call do?

2.  What would happen if this code was run by multiple threads?  Are there any concurrency issues that need to be guarded?

3.  What would happen in the case of multiple monitors at different resolutions?



Regards,

Randy

>>> Jay  8/11/2008 6:46 AM>>>

Also try the change I just commited with ReleaseDC.

- Jay


> From: jayk123 at hotmail.com 
> To: rcoleburn at scires.com 
> CC: wagner at elegosoft.com 
> Subject: RE: strange problem w/new Image/ImageInit
> Date: Mon, 11 Aug 2008 07:51:52 +0000
>
>
> Randy, this makes no sense to me.
> What happens if you just hardcode the numbers instead of computing them?
>
>
> - Jay
>
>
>
>
>
>
> ________________________________
>
>
>
> Date: Mon, 11 Aug 2008 02:55:56 -0400
> From: rcoleburn at scires.com 
> To: jayk123 at hotmail.com 
> CC: Olaf Wagner




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080812/607eed9b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ScrollerVBTClass.m3
Type: application/octet-stream
Size: 26638 bytes
Desc: not available
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080812/607eed9b/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Image.m3
Type: application/octet-stream
Size: 29271 bytes
Desc: not available
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080812/607eed9b/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Image.i3
Type: application/octet-stream
Size: 13111 bytes
Desc: not available
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080812/607eed9b/attachment-0005.obj>

From jay.krell at cornell.edu  Tue Aug 12 21:58:42 2008
From: jay.krell at cornell.edu (Jay)
Date: Tue, 12 Aug 2008 19:58:42 +0000
Subject: [M3devel] strange problem w/new Image/ImageInit
In-Reply-To: <48A17936.1E75.00D7.1@scires.com>
References: <489FAA38.1E75.00D7.1@scires.com>
	<COL101-W158F68823847D036260F0FE6710@phx.gbl>
	<48A02D67.1E75.00D7.1@scires.com>
	<COL101-W13606B4823978F6670D3C9E6710@phx.gbl>
	<48A05960.1E75.00D7.1@scires.com>
	<COL101-W65ECE9C2B48E275288EAF0E6710@phx.gbl>
	<48A110A3.1E75.00D7.1@scires.com>
	<COL101-W48D58C2FBDE5BCD3163650E6700@phx.gbl> 
	<48A17936.1E75.00D7.1@scires.com>
Message-ID: <COL101-W7934CC09223B996946776EE6700@phx.gbl>


Twice I've lost my message here, darnit.
LOGPIXELSX (look it up on MSDN/Google/LiveSearch) is pixels per inch on the x axis. It is stuck at 96 for compatibility. And the docs say it has just one value in a multimon situation.
So you can ask Windows for pixels per inch and get 96.
Or you can ask for pixels and millimeters and do the division and get the truth.
Or you can tell it you are "high dpi aware" on Vista and get the truth either way.
I understand the attempt to do the right thing, but it clearly doesn't work out -- the rest of the gui doesn't scale/move correctly with it.
What makes sense and is ideal is often at odds with the bulk of existing code. The bulk of existing code wins, and sometimes nobody can do the right thing in contradiction do it.
 
 - Jay



Date: Tue, 12 Aug 2008 11:51:25 -0400From: rcoleburn at scires.comTo: jay.krell at cornell.eduCC: m3devel at elegosoft.comSubject: Re: [M3devel] strange problem w/new Image/ImageInit

Jay:
 
Thanks for your insights here.  I'll try some more tests and see what I come up with.  I've attached my current Image.i3/Image.m3 and Win32/ScrollerVBTClass.m3 for your reference.  I've removed use of ImageInit from all of these.  And yes, I have reverted to the 75.0 hardcoded value.
 
Based on my limited understanding of the code, I still think I will get scaled behavior even if Modula-3 thinks the dpi is 96, because 147 / 96 =  1.53125, which rounds to 2.  So my pixmaps will still appear double-size.
 
In actuality, I think Modula-3 is trying to do the right thing with the scaling.  At some point on a high-enough dpi monitor, the pixmaps will be so tiny that you can't really see them if they are unscaled.  I've already observed this with some of my boolean and choice indicators--I had to reduce the shadowsize in order to tell whether the boolean/choice was TRUE or FALSE.  From the way Trestle/FormsVBT are set up, it appears that the designers wanted to get approximately the same size rendering on different dpi screens.  That's why you see millimeters everywhere in the code being converted to pixels.  Indeed, VBT has a procedure MMToPixels that is dependent on getting the screen type of the underlying VBT.T so it can get the ppm setting for this screen and do the computation.  Provided that the underlying implementation gives correct ppm info to Modula-3 for each screen, the current Trestle/FormsVBT should do the right thing even in multiple monitor situations.  I haven't tested this, but I should be able to drag a window from a monitor at one dpi onto a monitor at a different dpi and have everything scale to look correct on the new monitor.
 
The problem in my case with the 1920x1200 monitor is that the scaled pixmaps look huge in proportion to the text and other features of the window.  Maybe this other stuff isn't being scaled the same way pixmaps are scaled.
 
Does LOGPIXELSX stand for Logical Pixels X-Axis ?  I know that Windows has a dpi setting for fonts.  If set to normal, fonts are supposed to render at 96 dpi, but you can switch to large mode and have them rendered at 120 dpi, or you can make up a custom number.  This Windows setting applies only to fonts, not graphical elements.
 
You say that Modula-3 is computing LOGPIXELS via a "seemingly redundant equivalent way."  In my reading of the code in WinScreenType, it appears that Modula-3 is requesting from Windows the actual number of pixels in both axes and also the number of millimeters in both axes.  It uses these to compute the resolution in pixels per millimeter (ppm).  The ppm is what is stored and used internally when scaling pixmaps.  When necessary, ppm is converted to dpi using the formula (dpi = ppm x 25.4).
 
On my 4:3 aspect ratio IBM T60 at 1280x1024, the ppm is 3.41333 in both axes yielding a dpi of 86.698667.
 
On the widescreen (16:10 aspect ratio) Dell 4300 at 1920x1200 the ppm is slightly different in each axis, but is close to 5.8xxx yielding at dpi of 147.xxx  (again, the fractional part is different in each axis).
 
I don't mind running a test program for you on the hi-res system here--just send it to me via email.  I have the VC++ 2008 redistributables installed.
 
I think you are on the west coast and I'm on the east coast, so we have a time difference of 3 hours, but lately I've been working round the clock seemingly, so I'll try to respond with test results as soon as I can.
 
Regards,
Randy>>> Jay <jay.krell at cornell.edu> 8/12/2008 6:49 AM >>>Randy I don't think you need to add a way to use the unscaled data.I think the fix isa) go back to Image hardcoding 75b) Have WinScreenType hardcode 96 or use GetDeviceCaps(LOGPIXELSX Y) -- same thing really.And then see what happens.Basically, the scale of pixmaps and the scale of screens has always been close to 1:1.75:96, close enough.Therefore, unscaled has been the norm.Most GUI code uses GetDeviceCaps(LOGPIXELSX Y) I believe.However, most code is not prepared to get back anything other than 96 from it.Modula-3, at least for the pixmap code, was computing LOGPIXELSX and Y via a seemingly redundant equivalent way.However, my believe is that LOGPIXELSX and Y is forced to lie, but the other route is not.It seems an arbitrary discprecancy, but not beyond imagination.By switching to the lying method, we will get back the nearly unscaled 75:96 behavior.Vista adds a way for an application to declare that it is "high dpi aware", which then makes GetDeviceCaps(LOGPIXELX and Y) report the truth presumably. You can see, by the very existance of this ability to declare that you are high dpi aware -- to declare that your code is merely correct -- that most code is not correct.What remains to be determined is why Modula-3 pixmaps behave "differently" than Modula-3 buttons, text, etc.I also think there is a likely disconnect between painting and hit testing, but this is gross speculation.I should fiddle with the numbers myself.I will go ahead with a+b fairly soon.I will verify the numbers computed in #b before and after.I don't have any high dpi systems, so I expect the numbers to be roughly the same either way.I think the only systems that will see a change are high dpi, and they will see an improvement.Sorry for the back and forth regarding ImageInit -- a medium size change is going to be completely undone.- Jay________________________________Date: Tue, 12 Aug 2008 04:25:11 -0400From: rcoleburn at scires.comTo: jay.krell at cornell.eduCC: m3devel at elegosoft.comSubject: Re: [M3devel] strange problem w/new Image/ImageInitJay:For LOGPIXELS X & Y, I get 96 on the hi-res Dell M4300 system and also on my ThinkPad T60.I've put together revised versions of Image.i3/m3 and my ScrollerVBTClass.m3.  The good news is that I've managed to get the scroll bar to look correct in both scaled and unscaled modes.I've added a new procedure to Image.i3/m3 that will force subsequent calls to Scaled() to behave like Unscaled().  Using this, I can get the appearance I need on the hi-res monitor without resorting to changes in the original intent of the Image interface.  The advantage of this procedure is that it does not change the Image interface (except for addition of the procedure) and it therefore won't have any affect on pickles or anyone else's code.  Plus, it lets the programmer override use of Scaled() in all library modules without having to modify any source code.Before I commit any of these changes, I want to do some more testing and to fix the problem with subwindows (ZChassisVBT) not being able to move.Alas, my problem of the ZChassisVBTs not being able to move on the hi-res monitor persists with these changes, even though I left the xres/yres at 75.  Of course, these numbers are ignored for Unscaled images anyway.I'm at a loss to explain this behavior.  Here is what I know based on testing:1.  Using Scaled images and Image.Raw.xres/yres = 75.0, ZChassisVBT movement works on the hi-res monitor.2.  Using Scaled images and Image.Raw.xres/yres set to 86.xxx or to 147.xxx, ZChassisVBT movement does not work on the hi-res 147.xxx dpi monitor, but it still works on my 86.xxx dpi monitor3.  Using Unscaled images, ZChassisVBT movement does not work on the hi-res 147.xxx dpi monitor, but it still works on my 86.xxx dpi monitorSo, there seems to be something in the implementation somewhere of ZChassisVBT, or maybe ZMoveVBT, that doesn't like 147.xxx dpi monitors unless you scale all images assuming they were designed at 75 dpi.  At the 147 dpi, the 75 dpi pixmaps will be scaled by a factor of 2, which corresponds to what I am seeing on the screen.I'm too sleepy to make any more progress for now.  If anyone has an idea on what to do next, please let me know.  I'm stumped at this point.Regards,Randy>>> Jay  8/11/2008 3:52 PM>>>Hm. Ok then, where does it get the screen resolution from?Probably here?WinScreenType.m3:PROCEDURE InnerNew ((* IN-OUT *) res: T) =  BEGIN    WITH pix_hor = WinUser.GetSystemMetrics(WinUser.SM_CXSCREEN),         pix_ver = WinUser.GetSystemMetrics(WinUser.SM_CYSCREEN),         mm_hor  = GetDeviceCaps (WinGDI.HORZSIZE),         mm_ver  = GetDeviceCaps (WinGDI.VERTSIZE) DO      res.rootDom := Rect.FromSize(pix_hor, pix_ver);      res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);      res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);ok.Perhaps we should accept the numbers that Windows makes up instead?GetDeviceCaps(LOGPIXELSX)and GetDeviceCaps(LOGPIXELSY)Please try that, in the WinScreenType.m3 code.With removing ImageInit (or just have it hardcoded at 75).This will most likely be 96 even on your high dpi system, unless you are on Vistaand tell the system you are high dpi aware.I think there is disagreement in drawing vs. hit test as to where you are clicking.Try making ImageInit always 75.Try making the above convert from a hardcoded 96.And then try GetDeviceCaps(LOGPIXELSX and Y) -- which I expect always returns 96 for you.You can plug that into my dpi.c to see what it prints.I think part of what is happening is that Modula-3 was very rare in doing the right thing for high dpimonitors. But so much code is wrong that Windows has to counteract the wrongness,which means Modula-3 needs to go along and do things wrong in order for the counteractionto leave it doing the right thing also.I'm not sure.Oh, and presumably other places in Modula-3 are wrong, and the counteraction works for them.That's a bit of a mystery -- drawing of pixmaps vs. drawing of everything else.- Jay________________________________Date: Mon, 11 Aug 2008 15:23:17 -0400From: rcoleburn at scires.comTo: jay.krell at cornell.eduCC: m3devel at elegosoft.com; wagner at elegosoft.comSubject: RE: strange problem w/new Image/ImageInitJay:I have been experimenting quite a bit and I've come up with some "new old" information.I say "new old" because, after spending the time to read some of the comments in the original code (before we modified it), I think I now have a better idea of what the designers intended and why I had/have a problem.If you read carefully, the xres/yres fields in Image.Raw are supposed to represent the resolution at which the pixmap was originally DEVELOPED, not the resolution of the current screen.  It seems the designers went to great lengths to represent everything as screen-independent until it is actually rendered.The Image interface gives 3 ways of dealing with pixmaps:  (1) unscaled, (2) scaled, and (3) scaled to "most appropriate".  The change you and I conspired actually changes this behavior to make #2 (scaled) work as #1 (unscaled).  (It probably also changes #3.)  This is the behavior I want for my current program, but it changes the intent of the original interface, so I'm afraid we are going to have to revert all those changes.Digging deeper into Image.m3, I've discovered that it is smart-enough already to deduce the screen resolution.  If you look into the ApplyScaled1 procedure, you see that it converts the current screen resolution in millimeters to pixels in order to scale the pixmap.  The change we introduced, namely making Raw.xres/yres equal to the current screen resolution, effectively caused the Scaled procedure to do nothing since (ScreenDPI / ImageDPI) = 1.The problem that brought all this on in the first place is that my GUI was looking bad on the 1920x1200 screen.  The reason I have discovered *now* is that FormsVBT apparently uses the #2 (scaled) version for pixmaps.  In the old code, the interface defaulted the developed resolution of the pixmaps to be 75 dpi.  At my 147+ dpi screen, the scaled implementation would effectively double the size of the pixmap when rendered on the screen in an effort to make the pixmap look the same size on the 147dpi screen that it appeared on a 75 dpi screen.All of this to say that the changes to Image.i3/m3 need to be undone in order to get back the original intent of the developers.Of course, once these changes are undone, my problem returns with the GUI looking bad on 1920x1200 at 147+ dpi.  So, how to solve it properly now requires more thought.I need to do some more reading of the code I guess to see if there is a way already to cause FormsVBT to use unscaled for all pixmaps.  Otherwise, a quick fix would be to add a new procedure to the interface that would force use of the unscaled implementation.Now, back to the problem of not being able to drag the subwindows, I'm still puzzled.  To test my "understanding" as related above, I went back to the original Image.i3/m3, but this time changed the Scaled procedure to effectively do the same thing as Unscaled.  The pixmaps render fine on the 1920x1200 monitor, but the subwindows still can't be dragged.  If I back out my change to Scaled (effectively, revert to the original Image.m3), the subwindows drag with ease on the 1920x1200 monitor, but of course the pixmaps look bad.  I can't explain this behavior yet.  Any ideas?Regards,Randy>>> Jay  8/11/2008 2:41 PM>>>MemoryBarrier ensures that all the reads and writes before it finish before any reads and writes after it.Look at winnt.h or MSDN, as well the comment I put in explains it.It probably has no effect, since our compiler is not aggressive.What is confusing in these cases is the compiler and processor both need to be informed.There is a concurrency issue and the barrier should make extra certain to solve it.Multiple monitors are not considered.Do you have them?Randy, please experiment.Change the code to return hard coded numbers -- like the old 75.   Either without the globals, or initialize the globals.And then add in the the various calls one at a time, ignoring their return values.Furthermore, I guess you could just say:    IF xres = 0 THEN Init() END;and    IF yres = 0 THEN Init() END;and maybe change the globals to INTEGER.Though REAL should be 32 bits and be written atomatically.The idea is, even if the code does run multiple times concurrently, it should always return the same information.Anyway, like I said, try various or every combination between the two and findout which part triggers the difference, then we can think more about just that.I might be able to get an expert friend to give me some help, later.- Jay________________________________Date: Mon, 11 Aug 2008 12:15:40 -0400From: rcoleburn at scires.comTo: jay.krell at cornell.eduCC: wagner at elegosoft.comSubject: RE: strange problem w/new Image/ImageInitJay:I tested your change, but it has no effect on the problem I am having.  I also tried having the accessor functions just return a hardcoded number, but again, no effect on the problem.  This is real strange to me, because if I remove ImageInit and revert Image.i3/m3 back to the way it was before, the problem disappears.Questions,1.  What does the WinNT.MemoryBarrier() call do?2.  What would happen if this code was run by multiple threads?  Are there any concurrency issues that need to be guarded?3.  What would happen in the case of multiple monitors at different resolutions?Regards,Randy>>> Jay  8/11/2008 6:46 AM>>>Also try the change I just commited with ReleaseDC.- Jay> From: jayk123 at hotmail.com> To: rcoleburn at scires.com> CC: wagner at elegosoft.com> Subject: RE: strange problem w/new Image/ImageInit> Date: Mon, 11 Aug 2008 07:51:52 +0000>>> Randy, this makes no sense to me.> What happens if you just hardcode the numbers instead of computing them?>>> - Jay>>>>>>> ________________________________>>>> Date: Mon, 11 Aug 2008 02:55:56 -0400> From: rcoleburn at scires.com> To: jayk123 at hotmail.com> CC: Olaf Wagner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080812/41806d4a/attachment-0001.html>

From rcoleburn at scires.com  Wed Aug 13 03:04:58 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Tue, 12 Aug 2008 21:04:58 -0400
Subject: [M3devel] strange problem w/new Image/ImageInit
In-Reply-To: <COL101-W7934CC09223B996946776EE6700@phx.gbl>
References: <489FAA38.1E75.00D7.1@scires.com>
	<COL101-W158F68823847D036260F0FE6710@phx.gbl>
	<48A02D67.1E75.00D7.1@scires.com>
	<COL101-W13606B4823978F6670D3C9E6710@phx.gbl>
	<48A05960.1E75.00D7.1@scires.com>
	<COL101-W65ECE9C2B48E275288EAF0E6710@phx.gbl>
	<48A110A3.1E75.00D7.1@scires.com>
	<COL101-W48D58C2FBDE5BCD3163650E6700@phx.gbl>
	<48A17936.1E75.00D7.1@scires.com>
	<COL101-W7934CC09223B996946776EE6700@phx.gbl>
Message-ID: <48A1FAF3.1E75.00D7.1@scires.com>

Jay:
 
So, let me make sure I understand what you are suggesting.
1.  Change WinScreenType to use LOGPIXELS and therefore it will yield 96 dpi.
2.  Test with Image.Raw.res at 75.0, if it doesn't work out, try changing to 96.0.
 
I'll try the above and let you know how it fares.  Or, if I've misunderstood, please correct me.
 
I find it interesting that if you leave Image.Raw.res at 75.0 and use scaled pixmaps, the ZChassisVBT's ZMoveVBT works as expected regardless of what dpi setting Windows reports to Trestle, but if you switch to unscaled pixmaps or if you change the Image.Raw.res to 86 or 147 the ZMoveVBT stops working on the 1920x1200 system yet it continues to work on all other systems I've tested.
 
Regards,
Randy

>>> Jay <jay.krell at cornell.edu> 8/12/2008 3:58 PM >>>
Twice I've lost my message here, darnit.
LOGPIXELSX (look it up on MSDN/Google/LiveSearch) is pixels per inch on the x axis. It is stuck at 96 for compatibility. And the docs say it has just one value in a multimon situation.
So you can ask Windows for pixels per inch and get 96.
Or you can ask for pixels and millimeters and do the division and get the truth.
Or you can tell it you are "high dpi aware" on Vista and get the truth either way.
I understand the attempt to do the right thing, but it clearly doesn't work out -- the rest of the gui doesn't scale/move correctly with it.
What makes sense and is ideal is often at odds with the bulk of existing code. The bulk of existing code wins, and sometimes nobody can do the right thing in contradiction do it.
 
 - Jay



Date: Tue, 12 Aug 2008 11:51:25 -0400
From: rcoleburn at scires.com 
To: jay.krell at cornell.edu 
CC: m3devel at elegosoft.com 
Subject: Re: [M3devel] strange problem w/new Image/ImageInit


Jay:
 
Thanks for your insights here.  I'll try some more tests and see what I come up with.  I've attached my current Image.i3/Image.m3 and Win32/ScrollerVBTClass.m3 for your reference.  I've removed use of ImageInit from all of these.  And yes, I have reverted to the 75.0 hardcoded value.
 
Based on my limited understanding of the code, I still think I will get scaled behavior even if Modula-3 thinks the dpi is 96, because 147 / 96 =  1.53125, which rounds to 2.  So my pixmaps will still appear double-size.
 
In actuality, I think Modula-3 is trying to do the right thing with the scaling.  At some point on a high-enough dpi monitor, the pixmaps will be so tiny that you can't really see them if they are unscaled.  I've already observed this with some of my boolean and choice indicators--I had to reduce the shadowsize in order to tell whether the boolean/choice was TRUE or FALSE.  From the way Trestle/FormsVBT are set up, it appears that the designers wanted to get approximately the same size rendering on different dpi screens.  That's why you see millimeters everywhere in the code being converted to pixels.  Indeed, VBT has a procedure MMToPixels that is dependent on getting the screen type of the underlying VBT.T so it can get the ppm setting for this screen and do the computation.  Provided that the underlying implementation gives correct ppm info to Modula-3 for each screen, the current Trestle/FormsVBT should do the right thing even in multiple monitor situations.  I haven't tested this, but I should be able to drag a window from a monitor at one dpi onto a monitor at a different dpi and have everything scale to look correct on the new monitor.
 
The problem in my case with the 1920x1200 monitor is that the scaled pixmaps look huge in proportion to the text and other features of the window.  Maybe this other stuff isn't being scaled the same way pixmaps are scaled.
 
Does LOGPIXELSX stand for Logical Pixels X-Axis ?  I know that Windows has a dpi setting for fonts.  If set to normal, fonts are supposed to render at 96 dpi, but you can switch to large mode and have them rendered at 120 dpi, or you can make up a custom number.  This Windows setting applies only to fonts, not graphical elements.
 
You say that Modula-3 is computing LOGPIXELS via a "seemingly redundant equivalent way."  In my reading of the code in WinScreenType, it appears that Modula-3 is requesting from Windows the actual number of pixels in both axes and also the number of millimeters in both axes.  It uses these to compute the resolution in pixels per millimeter (ppm).  The ppm is what is stored and used internally when scaling pixmaps.  When necessary, ppm is converted to dpi using the formula (dpi = ppm x 25.4).
 
On my 4:3 aspect ratio IBM T60 at 1280x1024, the ppm is 3.41333 in both axes yielding a dpi of 86.698667.
 
On the widescreen (16:10 aspect ratio) Dell 4300 at 1920x1200 the ppm is slightly different in each axis, but is close to 5.8xxx yielding at dpi of 147.xxx  (again, the fractional part is different in each axis).
 
I don't mind running a test program for you on the hi-res system here--just send it to me via email.  I have the VC++ 2008 redistributables installed.
 
I think you are on the west coast and I'm on the east coast, so we have a time difference of 3 hours, but lately I've been working round the clock seemingly, so I'll try to respond with test results as soon as I can.
 
Regards,
Randy

>>> Jay <jay.krell at cornell.edu> 8/12/2008 6:49 AM >>>

Randy I don't think you need to add a way to use the unscaled data.
I think the fix is
a) go back to Image hardcoding 75
b) Have WinScreenType hardcode 96 or use GetDeviceCaps(LOGPIXELSX Y) -- same thing really.
And then see what happens.

Basically, the scale of pixmaps and the scale of screens has always been close to 1:1.
75:96, close enough.
Therefore, unscaled has been the norm.

Most GUI code uses GetDeviceCaps(LOGPIXELSX Y) I believe.
However, most code is not prepared to get back anything other than 96 from it.

Modula-3, at least for the pixmap code, was computing LOGPIXELSX and Y via a seemingly redundant equivalent way.
However, my believe is that LOGPIXELSX and Y is forced to lie, but the other route is not.
It seems an arbitrary discprecancy, but not beyond imagination.

By switching to the lying method, we will get back the nearly unscaled 75:96 behavior.

Vista adds a way for an application to declare that it is "high dpi aware", which then makes GetDeviceCaps(LOGPIXELX and Y) report the truth presumably. You can see, by the very existance of this ability to declare that you are high dpi aware -- to declare that your code is merely correct -- that most code is not correct.

What remains to be determined is why Modula-3 pixmaps behave "differently" than Modula-3 buttons, text, etc.

I also think there is a likely disconnect between painting and hit testing, but this is gross speculation.
I should fiddle with the numbers myself.

I will go ahead with a+b fairly soon.
I will verify the numbers computed in #b before and after.
I don't have any high dpi systems, so I expect the numbers to be roughly the same either way.
I think the only systems that will see a change are high dpi, and they will see an improvement.

Sorry for the back and forth regarding ImageInit -- a medium size change is going to be completely undone.

- Jay

________________________________

Date: Tue, 12 Aug 2008 04:25:11 -0400
From: rcoleburn at scires.com 
To: jay.krell at cornell.edu 
CC: m3devel at elegosoft.com 
Subject: Re: [M3devel] strange problem w/new Image/ImageInit



Jay:



For LOGPIXELS X & Y, I get 96 on the hi-res Dell M4300 system and also on my ThinkPad T60.



I've put together revised versions of Image.i3/m3 and my ScrollerVBTClass.m3.  The good news is that I've managed to get the scroll bar to look correct in both scaled and unscaled modes.



I've added a new procedure to Image.i3/m3 that will force subsequent calls to Scaled() to behave like Unscaled().  Using this, I can get the appearance I need on the hi-res monitor without resorting to changes in the original intent of the Image interface.  The advantage of this procedure is that it does not change the Image interface (except for addition of the procedure) and it therefore won't have any affect on pickles or anyone else's code.  Plus, it lets the programmer override use of Scaled() in all library modules without having to modify any source code.



Before I commit any of these changes, I want to do some more testing and to fix the problem with subwindows (ZChassisVBT) not being able to move.



Alas, my problem of the ZChassisVBTs not being able to move on the hi-res monitor persists with these changes, even though I left the xres/yres at 75.  Of course, these numbers are ignored for Unscaled images anyway.



I'm at a loss to explain this behavior.  Here is what I know based on testing:

1.  Using Scaled images and Image.Raw.xres/yres = 75.0, ZChassisVBT movement works on the hi-res monitor.

2.  Using Scaled images and Image.Raw.xres/yres set to 86.xxx or to 147.xxx, ZChassisVBT movement does not work on the hi-res 147.xxx dpi monitor, but it still works on my 86.xxx dpi monitor

3.  Using Unscaled images, ZChassisVBT movement does not work on the hi-res 147.xxx dpi monitor, but it still works on my 86.xxx dpi monitor



So, there seems to be something in the implementation somewhere of ZChassisVBT, or maybe ZMoveVBT, that doesn't like 147.xxx dpi monitors unless you scale all images assuming they were designed at 75 dpi.  At the 147 dpi, the 75 dpi pixmaps will be scaled by a factor of 2, which corresponds to what I am seeing on the screen.



I'm too sleepy to make any more progress for now.  If anyone has an idea on what to do next, please let me know.  I'm stumped at this point.



Regards,

Randy

>>> Jay  8/11/2008 3:52 PM>>>

Hm. Ok then, where does it get the screen resolution from?

Probably here?

WinScreenType.m3:

PROCEDURE InnerNew ((* IN-OUT *) res: T) =
  BEGIN
    WITH pix_hor = WinUser.GetSystemMetrics(WinUser.SM_CXSCREEN),
         pix_ver = WinUser.GetSystemMetrics(WinUser.SM_CYSCREEN),
         mm_hor  = GetDeviceCaps (WinGDI.HORZSIZE),
         mm_ver  = GetDeviceCaps (WinGDI.VERTSIZE) DO
      res.rootDom := Rect.FromSize(pix_hor, pix_ver);
      res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
      res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);

ok.

Perhaps we should accept the numbers that Windows makes up instead?

GetDeviceCaps(LOGPIXELSX)
and GetDeviceCaps(LOGPIXELSY)

Please try that, in the WinScreenType.m3 code.
With removing ImageInit (or just have it hardcoded at 75).

This will most likely be 96 even on your high dpi system, unless you are on Vista
and tell the system you are high dpi aware.

I think there is disagreement in drawing vs. hit test as to where you are clicking.
Try making ImageInit always 75.
Try making the above convert from a hardcoded 96.
And then try GetDeviceCaps(LOGPIXELSX and Y) -- which I expect always returns 96 for you.
You can plug that into my dpi.c to see what it prints.

I think part of what is happening is that Modula-3 was very rare in doing the right thing for high dpi
monitors. But so much code is wrong that Windows has to counteract the wrongness,
which means Modula-3 needs to go along and do things wrong in order for the counteraction
to leave it doing the right thing also.
I'm not sure.
Oh, and presumably other places in Modula-3 are wrong, and the counteraction works for them.
That's a bit of a mystery -- drawing of pixmaps vs. drawing of everything else.

- Jay


________________________________

Date: Mon, 11 Aug 2008 15:23:17 -0400
From: rcoleburn at scires.com 
To: jay.krell at cornell.edu 
CC: m3devel at elegosoft.com; wagner at elegosoft.com 
Subject: RE: strange problem w/new Image/ImageInit



Jay:



I have been experimenting quite a bit and I've come up with some "new old" information.



I say "new old" because, after spending the time to read some of the comments in the original code (before we modified it), I think I now have a better idea of what the designers intended and why I had/have a problem.



If you read carefully, the xres/yres fields in Image.Raw are supposed to represent the resolution at which the pixmap was originally DEVELOPED, not the resolution of the current screen.  It seems the designers went to great lengths to represent everything as screen-independent until it is actually rendered.



The Image interface gives 3 ways of dealing with pixmaps:  (1) unscaled, (2) scaled, and (3) scaled to "most appropriate".  The change you and I conspired actually changes this behavior to make #2 (scaled) work as #1 (unscaled).  (It probably also changes #3.)  This is the behavior I want for my current program, but it changes the intent of the original interface, so I'm afraid we are going to have to revert all those changes.



Digging deeper into Image.m3, I've discovered that it is smart-enough already to deduce the screen resolution.  If you look into the ApplyScaled1 procedure, you see that it converts the current screen resolution in millimeters to pixels in order to scale the pixmap.  The change we introduced, namely making Raw.xres/yres equal to the current screen resolution, effectively caused the Scaled procedure to do nothing since (ScreenDPI / ImageDPI) = 1.



The problem that brought all this on in the first place is that my GUI was looking bad on the 1920x1200 screen.  The reason I have discovered *now* is that FormsVBT apparently uses the #2 (scaled) version for pixmaps.  In the old code, the interface defaulted the developed resolution of the pixmaps to be 75 dpi.  At my 147+ dpi screen, the scaled implementation would effectively double the size of the pixmap when rendered on the screen in an effort to make the pixmap look the same size on the 147dpi screen that it appeared on a 75 dpi screen.



All of this to say that the changes to Image.i3/m3 need to be undone in order to get back the original intent of the developers.



Of course, once these changes are undone, my problem returns with the GUI looking bad on 1920x1200 at 147+ dpi.  So, how to solve it properly now requires more thought.



I need to do some more reading of the code I guess to see if there is a way already to cause FormsVBT to use unscaled for all pixmaps.  Otherwise, a quick fix would be to add a new procedure to the interface that would force use of the unscaled implementation.



Now, back to the problem of not being able to drag the subwindows, I'm still puzzled.  To test my "understanding" as related above, I went back to the original Image.i3/m3, but this time changed the Scaled procedure to effectively do the same thing as Unscaled.  The pixmaps render fine on the 1920x1200 monitor, but the subwindows still can't be dragged.  If I back out my change to Scaled (effectively, revert to the original Image.m3), the subwindows drag with ease on the 1920x1200 monitor, but of course the pixmaps look bad.  I can't explain this behavior yet.  Any ideas?



Regards,

Randy

>>> Jay  8/11/2008 2:41 PM>>>

MemoryBarrier ensures that all the reads and writes before it finish before any reads and writes after it.
Look at winnt.h or MSDN, as well the comment I put in explains it.
It probably has no effect, since our compiler is not aggressive.
What is confusing in these cases is the compiler and processor both need to be informed.
There is a concurrency issue and the barrier should make extra certain to solve it.

Multiple monitors are not considered.
Do you have them?

Randy, please experiment.
Change the code to return hard coded numbers -- like the old 75.
   Either without the globals, or initialize the globals.
And then add in the the various calls one at a time, ignoring their return values.

Furthermore, I guess you could just say:

    IF xres = 0 THEN Init() END;

and

    IF yres = 0 THEN Init() END;

and maybe change the globals to INTEGER.
Though REAL should be 32 bits and be written atomatically.

The idea is, even if the code does run multiple times concurrently, it should always return the same information.

Anyway, like I said, try various or every combination between the two and find
out which part triggers the difference, then we can think more about just that.

I might be able to get an expert friend to give me some help, later.

- Jay


________________________________

Date: Mon, 11 Aug 2008 12:15:40 -0400
From: rcoleburn at scires.com 
To: jay.krell at cornell.edu 
CC: wagner at elegosoft.com 
Subject: RE: strange problem w/new Image/ImageInit



Jay:



I tested your change, but it has no effect on the problem I am having.  I also tried having the accessor functions just return a hardcoded number, but again, no effect on the problem.  This is real strange to me, because if I remove ImageInit and revert Image.i3/m3 back to the way it was before, the problem disappears.



Questions,

1.  What does the WinNT.MemoryBarrier() call do?

2.  What would happen if this code was run by multiple threads?  Are there any concurrency issues that need to be guarded?

3.  What would happen in the case of multiple monitors at different resolutions?



Regards,

Randy

>>> Jay  8/11/2008 6:46 AM>>>

Also try the change I just commited with ReleaseDC.

- Jay


> From: jayk123 at hotmail.com 
> To: rcoleburn at scires.com 
> CC: wagner at elegosoft.com 
> Subject: RE: strange problem w/new Image/ImageInit
> Date: Mon, 11 Aug 2008 07:51:52 +0000
>
>
> Randy, this makes no sense to me.
> What happens if you just hardcode the numbers instead of computing them?
>
>
> - Jay
>
>
>
>
>
>
> ________________________________
>
>
>
> Date: Mon, 11 Aug 2008 02:55:56 -0400
> From: rcoleburn at scires.com 
> To: jayk123 at hotmail.com 
> CC: Olaf Wagner




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080812/feddefb6/attachment-0001.html>

From jay.krell at cornell.edu  Wed Aug 13 05:17:22 2008
From: jay.krell at cornell.edu (Jay)
Date: Wed, 13 Aug 2008 03:17:22 +0000
Subject: [M3devel] strange problem w/new Image/ImageInit
In-Reply-To: <48A1FAF3.1E75.00D7.1@scires.com>
References: <489FAA38.1E75.00D7.1@scires.com>
	<COL101-W158F68823847D036260F0FE6710@phx.gbl>
	<48A02D67.1E75.00D7.1@scires.com>
	<COL101-W13606B4823978F6670D3C9E6710@phx.gbl>
	<48A05960.1E75.00D7.1@scires.com>
	<COL101-W65ECE9C2B48E275288EAF0E6710@phx.gbl>
	<48A110A3.1E75.00D7.1@scires.com>
	<COL101-W48D58C2FBDE5BCD3163650E6700@phx.gbl>
	<48A17936.1E75.00D7.1@scires.com>
	<COL101-W7934CC09223B996946776EE6700@phx.gbl> 
	<48A1FAF3.1E75.00D7.1@scires.com>
Message-ID: <COL101-W56F9FEE075B5A2C956F192E6730@phx.gbl>


1 and 2 correct. I expect 75 will do for #2.#1 you can verify and not just run blind. Print it, or use the C code, or maybe you already did.
The ratio of these numbers is the "problem". You asked for "unscaled", I suggest 75/96 or 96/75, close to unscalled, and should be about the same as it has been doing on most machines all along -- most machines having close to 96 actual dpi. (We should probably do a quick survey of that.)
 
Is there a way to fiddle with the numbers that breaks movement on all machines?I should try and look for that.
 
 - Jay



Date: Tue, 12 Aug 2008 21:04:58 -0400From: rcoleburn at scires.comTo: jay.krell at cornell.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] strange problem w/new Image/ImageInit



Jay:
 
So, let me make sure I understand what you are suggesting.
1.  Change WinScreenType to use LOGPIXELS and therefore it will yield 96 dpi.
2.  Test with Image.Raw.res at 75.0, if it doesn't work out, try changing to 96.0.
 
I'll try the above and let you know how it fares.  Or, if I've misunderstood, please correct me.
 
I find it interesting that if you leave Image.Raw.res at 75.0 and use scaled pixmaps, the ZChassisVBT's ZMoveVBT works as expected regardless of what dpi setting Windows reports to Trestle, but if you switch to unscaled pixmaps or if you change the Image.Raw.res to 86 or 147 the ZMoveVBT stops working on the 1920x1200 system yet it continues to work on all other systems I've tested.
 
Regards,
Randy>>> Jay <jay.krell at cornell.edu> 8/12/2008 3:58 PM >>>Twice I've lost my message here, darnit.LOGPIXELSX (look it up on MSDN/Google/LiveSearch) is pixels per inch on the x axis. It is stuck at 96 for compatibility. And the docs say it has just one value in a multimon situation.So you can ask Windows for pixels per inch and get 96.Or you can ask for pixels and millimeters and do the division and get the truth.Or you can tell it you are "high dpi aware" on Vista and get the truth either way.I understand the attempt to do the right thing, but it clearly doesn't work out -- the rest of the gui doesn't scale/move correctly with it.What makes sense and is ideal is often at odds with the bulk of existing code. The bulk of existing code wins, and sometimes nobody can do the right thing in contradiction do it.  - Jay



Date: Tue, 12 Aug 2008 11:51:25 -0400From: rcoleburn at scires.comTo: jay.krell at cornell.eduCC: m3devel at elegosoft.comSubject: Re: [M3devel] strange problem w/new Image/ImageInit
Jay:
 
Thanks for your insights here.  I'll try some more tests and see what I come up with.  I've attached my current Image.i3/Image.m3 and Win32/ScrollerVBTClass.m3 for your reference.  I've removed use of ImageInit from all of these.  And yes, I have reverted to the 75.0 hardcoded value.
 
Based on my limited understanding of the code, I still think I will get scaled behavior even if Modula-3 thinks the dpi is 96, because 147 / 96 =  1.53125, which rounds to 2.  So my pixmaps will still appear double-size.
 
In actuality, I think Modula-3 is trying to do the right thing with the scaling.  At some point on a high-enough dpi monitor, the pixmaps will be so tiny that you can't really see them if they are unscaled.  I've already observed this with some of my boolean and choice indicators--I had to reduce the shadowsize in order to tell whether the boolean/choice was TRUE or FALSE.  From the way Trestle/FormsVBT are set up, it appears that the designers wanted to get approximately the same size rendering on different dpi screens.  That's why you see millimeters everywhere in the code being converted to pixels.  Indeed, VBT has a procedure MMToPixels that is dependent on getting the screen type of the underlying VBT.T so it can get the ppm setting for this screen and do the computation.  Provided that the underlying implementation gives correct ppm info to Modula-3 for each screen, the current Trestle/FormsVBT should do the right thing even in multiple monitor situations.  I haven't tested this, but I should be able to drag a window from a monitor at one dpi onto a monitor at a different dpi and have everything scale to look correct on the new monitor.
 
The problem in my case with the 1920x1200 monitor is that the scaled pixmaps look huge in proportion to the text and other features of the window.  Maybe this other stuff isn't being scaled the same way pixmaps are scaled.
 
Does LOGPIXELSX stand for Logical Pixels X-Axis ?  I know that Windows has a dpi setting for fonts.  If set to normal, fonts are supposed to render at 96 dpi, but you can switch to large mode and have them rendered at 120 dpi, or you can make up a custom number.  This Windows setting applies only to fonts, not graphical elements.
 
You say that Modula-3 is computing LOGPIXELS via a "seemingly redundant equivalent way."  In my reading of the code in WinScreenType, it appears that Modula-3 is requesting from Windows the actual number of pixels in both axes and also the number of millimeters in both axes.  It uses these to compute the resolution in pixels per millimeter (ppm).  The ppm is what is stored and used internally when scaling pixmaps.  When necessary, ppm is converted to dpi using the formula (dpi = ppm x 25.4).
 
On my 4:3 aspect ratio IBM T60 at 1280x1024, the ppm is 3.41333 in both axes yielding a dpi of 86.698667.
 
On the widescreen (16:10 aspect ratio) Dell 4300 at 1920x1200 the ppm is slightly different in each axis, but is close to 5.8xxx yielding at dpi of 147.xxx  (again, the fractional part is different in each axis).
 
I don't mind running a test program for you on the hi-res system here--just send it to me via email.  I have the VC++ 2008 redistributables installed.
 
I think you are on the west coast and I'm on the east coast, so we have a time difference of 3 hours, but lately I've been working round the clock seemingly, so I'll try to respond with test results as soon as I can.
 
Regards,
Randy>>> Jay <jay.krell at cornell.edu> 8/12/2008 6:49 AM >>>Randy I don't think you need to add a way to use the unscaled data.I think the fix isa) go back to Image hardcoding 75b) Have WinScreenType hardcode 96 or use GetDeviceCaps(LOGPIXELSX Y) -- same thing really.And then see what happens.Basically, the scale of pixmaps and the scale of screens has always been close to 1:1.75:96, close enough.Therefore, unscaled has been the norm.Most GUI code uses GetDeviceCaps(LOGPIXELSX Y) I believe.However, most code is not prepared to get back anything other than 96 from it.Modula-3, at least for the pixmap code, was computing LOGPIXELSX and Y via a seemingly redundant equivalent way.However, my believe is that LOGPIXELSX and Y is forced to lie, but the other route is not.It seems an arbitrary discprecancy, but not beyond imagination.By switching to the lying method, we will get back the nearly unscaled 75:96 behavior.Vista adds a way for an application to declare that it is "high dpi aware", which then makes GetDeviceCaps(LOGPIXELX and Y) report the truth presumably. You can see, by the very existance of this ability to declare that you are high dpi aware -- to declare that your code is merely correct -- that most code is not correct.What remains to be determined is why Modula-3 pixmaps behave "differently" than Modula-3 buttons, text, etc.I also think there is a likely disconnect between painting and hit testing, but this is gross speculation.I should fiddle with the numbers myself.I will go ahead with a+b fairly soon.I will verify the numbers computed in #b before and after.I don't have any high dpi systems, so I expect the numbers to be roughly the same either way.I think the only systems that will see a change are high dpi, and they will see an improvement.Sorry for the back and forth regarding ImageInit -- a medium size change is going to be completely undone.- Jay________________________________Date: Tue, 12 Aug 2008 04:25:11 -0400From: rcoleburn at scires.comTo: jay.krell at cornell.eduCC: m3devel at elegosoft.comSubject: Re: [M3devel] strange problem w/new Image/ImageInitJay:For LOGPIXELS X & Y, I get 96 on the hi-res Dell M4300 system and also on my ThinkPad T60.I've put together revised versions of Image.i3/m3 and my ScrollerVBTClass.m3.  The good news is that I've managed to get the scroll bar to look correct in both scaled and unscaled modes.I've added a new procedure to Image.i3/m3 that will force subsequent calls to Scaled() to behave like Unscaled().  Using this, I can get the appearance I need on the hi-res monitor without resorting to changes in the original intent of the Image interface.  The advantage of this procedure is that it does not change the Image interface (except for addition of the procedure) and it therefore won't have any affect on pickles or anyone else's code.  Plus, it lets the programmer override use of Scaled() in all library modules without having to modify any source code.Before I commit any of these changes, I want to do some more testing and to fix the problem with subwindows (ZChassisVBT) not being able to move.Alas, my problem of the ZChassisVBTs not being able to move on the hi-res monitor persists with these changes, even though I left the xres/yres at 75.  Of course, these numbers are ignored for Unscaled images anyway.I'm at a loss to explain this behavior.  Here is what I know based on testing:1.  Using Scaled images and Image.Raw.xres/yres = 75.0, ZChassisVBT movement works on the hi-res monitor.2.  Using Scaled images and Image.Raw.xres/yres set to 86.xxx or to 147.xxx, ZChassisVBT movement does not work on the hi-res 147.xxx dpi monitor, but it still works on my 86.xxx dpi monitor3.  Using Unscaled images, ZChassisVBT movement does not work on the hi-res 147.xxx dpi monitor, but it still works on my 86.xxx dpi monitorSo, there seems to be something in the implementation somewhere of ZChassisVBT, or maybe ZMoveVBT, that doesn't like 147.xxx dpi monitors unless you scale all images assuming they were designed at 75 dpi.  At the 147 dpi, the 75 dpi pixmaps will be scaled by a factor of 2, which corresponds to what I am seeing on the screen.I'm too sleepy to make any more progress for now.  If anyone has an idea on what to do next, please let me know.  I'm stumped at this point.Regards,Randy>>> Jay  8/11/2008 3:52 PM>>>Hm. Ok then, where does it get the screen resolution from?Probably here?WinScreenType.m3:PROCEDURE InnerNew ((* IN-OUT *) res: T) =  BEGIN    WITH pix_hor = WinUser.GetSystemMetrics(WinUser.SM_CXSCREEN),         pix_ver = WinUser.GetSystemMetrics(WinUser.SM_CYSCREEN),         mm_hor  = GetDeviceCaps (WinGDI.HORZSIZE),         mm_ver  = GetDeviceCaps (WinGDI.VERTSIZE) DO      res.rootDom := Rect.FromSize(pix_hor, pix_ver);      res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);      res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);ok.Perhaps we should accept the numbers that Windows makes up instead?GetDeviceCaps(LOGPIXELSX)and GetDeviceCaps(LOGPIXELSY)Please try that, in the WinScreenType.m3 code.With removing ImageInit (or just have it hardcoded at 75).This will most likely be 96 even on your high dpi system, unless you are on Vistaand tell the system you are high dpi aware.I think there is disagreement in drawing vs. hit test as to where you are clicking.Try making ImageInit always 75.Try making the above convert from a hardcoded 96.And then try GetDeviceCaps(LOGPIXELSX and Y) -- which I expect always returns 96 for you.You can plug that into my dpi.c to see what it prints.I think part of what is happening is that Modula-3 was very rare in doing the right thing for high dpimonitors. But so much code is wrong that Windows has to counteract the wrongness,which means Modula-3 needs to go along and do things wrong in order for the counteractionto leave it doing the right thing also.I'm not sure.Oh, and presumably other places in Modula-3 are wrong, and the counteraction works for them.That's a bit of a mystery -- drawing of pixmaps vs. drawing of everything else.- Jay________________________________Date: Mon, 11 Aug 2008 15:23:17 -0400From: rcoleburn at scires.comTo: jay.krell at cornell.eduCC: m3devel at elegosoft.com; wagner at elegosoft.comSubject: RE: strange problem w/new Image/ImageInitJay:I have been experimenting quite a bit and I've come up with some "new old" information.I say "new old" because, after spending the time to read some of the comments in the original code (before we modified it), I think I now have a better idea of what the designers intended and why I had/have a problem.If you read carefully, the xres/yres fields in Image.Raw are supposed to represent the resolution at which the pixmap was originally DEVELOPED, not the resolution of the current screen.  It seems the designers went to great lengths to represent everything as screen-independent until it is actually rendered.The Image interface gives 3 ways of dealing with pixmaps:  (1) unscaled, (2) scaled, and (3) scaled to "most appropriate".  The change you and I conspired actually changes this behavior to make #2 (scaled) work as #1 (unscaled).  (It probably also changes #3.)  This is the behavior I want for my current program, but it changes the intent of the original interface, so I'm afraid we are going to have to revert all those changes.Digging deeper into Image.m3, I've discovered that it is smart-enough already to deduce the screen resolution.  If you look into the ApplyScaled1 procedure, you see that it converts the current screen resolution in millimeters to pixels in order to scale the pixmap.  The change we introduced, namely making Raw.xres/yres equal to the current screen resolution, effectively caused the Scaled procedure to do nothing since (ScreenDPI / ImageDPI) = 1.The problem that brought all this on in the first place is that my GUI was looking bad on the 1920x1200 screen.  The reason I have discovered *now* is that FormsVBT apparently uses the #2 (scaled) version for pixmaps.  In the old code, the interface defaulted the developed resolution of the pixmaps to be 75 dpi.  At my 147+ dpi screen, the scaled implementation would effectively double the size of the pixmap when rendered on the screen in an effort to make the pixmap look the same size on the 147dpi screen that it appeared on a 75 dpi screen.All of this to say that the changes to Image.i3/m3 need to be undone in order to get back the original intent of the developers.Of course, once these changes are undone, my problem returns with the GUI looking bad on 1920x1200 at 147+ dpi.  So, how to solve it properly now requires more thought.I need to do some more reading of the code I guess to see if there is a way already to cause FormsVBT to use unscaled for all pixmaps.  Otherwise, a quick fix would be to add a new procedure to the interface that would force use of the unscaled implementation.Now, back to the problem of not being able to drag the subwindows, I'm still puzzled.  To test my "understanding" as related above, I went back to the original Image.i3/m3, but this time changed the Scaled procedure to effectively do the same thing as Unscaled.  The pixmaps render fine on the 1920x1200 monitor, but the subwindows still can't be dragged.  If I back out my change to Scaled (effectively, revert to the original Image.m3), the subwindows drag with ease on the 1920x1200 monitor, but of course the pixmaps look bad.  I can't explain this behavior yet.  Any ideas?Regards,Randy>>> Jay  8/11/2008 2:41 PM>>>MemoryBarrier ensures that all the reads and writes before it finish before any reads and writes after it.Look at winnt.h or MSDN, as well the comment I put in explains it.It probably has no effect, since our compiler is not aggressive.What is confusing in these cases is the compiler and processor both need to be informed.There is a concurrency issue and the barrier should make extra certain to solve it.Multiple monitors are not considered.Do you have them?Randy, please experiment.Change the code to return hard coded numbers -- like the old 75.   Either without the globals, or initialize the globals.And then add in the the various calls one at a time, ignoring their return values.Furthermore, I guess you could just say:    IF xres = 0 THEN Init() END;and    IF yres = 0 THEN Init() END;and maybe change the globals to INTEGER.Though REAL should be 32 bits and be written atomatically.The idea is, even if the code does run multiple times concurrently, it should always return the same information.Anyway, like I said, try various or every combination between the two and findout which part triggers the difference, then we can think more about just that.I might be able to get an expert friend to give me some help, later.- Jay________________________________Date: Mon, 11 Aug 2008 12:15:40 -0400From: rcoleburn at scires.comTo: jay.krell at cornell.eduCC: wagner at elegosoft.comSubject: RE: strange problem w/new Image/ImageInitJay:I tested your change, but it has no effect on the problem I am having.  I also tried having the accessor functions just return a hardcoded number, but again, no effect on the problem.  This is real strange to me, because if I remove ImageInit and revert Image.i3/m3 back to the way it was before, the problem disappears.Questions,1.  What does the WinNT.MemoryBarrier() call do?2.  What would happen if this code was run by multiple threads?  Are there any concurrency issues that need to be guarded?3.  What would happen in the case of multiple monitors at different resolutions?Regards,Randy>>> Jay  8/11/2008 6:46 AM>>>Also try the change I just commited with ReleaseDC.- Jay> From: jayk123 at hotmail.com> To: rcoleburn at scires.com> CC: wagner at elegosoft.com> Subject: RE: strange problem w/new Image/ImageInit> Date: Mon, 11 Aug 2008 07:51:52 +0000>>> Randy, this makes no sense to me.> What happens if you just hardcode the numbers instead of computing them?>>> - Jay>>>>>>> ________________________________>>>> Date: Mon, 11 Aug 2008 02:55:56 -0400> From: rcoleburn at scires.com> To: jayk123 at hotmail.com> CC: Olaf Wagner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080813/0d8a70e0/attachment-0001.html>

From jay.krell at cornell.edu  Wed Aug 13 13:31:05 2008
From: jay.krell at cornell.edu (Jay)
Date: Wed, 13 Aug 2008 11:31:05 +0000
Subject: [M3devel] FW: [M3commit] CVS Update: cm3
In-Reply-To: <20080813111059.33D8010D4DFE@birch.elegosoft.com>
References: <20080813111059.33D8010D4DFE@birch.elegosoft.com>
Message-ID: <COL101-W464DEDAFAE6F8583491CF0E6730@phx.gbl>


Randy, sorry
1) I didn't realize the functions were in use.
2) I couldn't figure out what each number means. I did try varying them and seeing the affect.
I think maybe I need to learn the X Windows terms? I know in Mac/Windows the part you can drag is the "thumb".

I think I preserved your intent. Feel free to reinstate your intent.
I brought up formsedit and only could easily see a vertical scrollbar.
It doesn't look right to me, but I suspect it is.
If the layers of Trestle could be understand and plowed through, DrawFrameControl would be good.
I've misplaced my Nelson. I'll get another and see if I can understand this..
I'm also curious to see if Tk and Qt draw scrollbars themselves or not.
I'll probably check soon (or by end of month, will be gone next week, out of touch).

 - Jay




----------------------------------------
[big mess made by the ever non-working email systems..]
> Date: Wed, 13 Aug 2008 13:10:59 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT:	/usr/cvs
> Changes by:	jkrell at birch.	08/08/13 13:10:59
> 
> Modified files:
> 	cm3/m3-ui/vbtkit/src/lego/WIN32/: ScrollerVBTClass.m3 
> 
> Log message:
> 	fix it to compile, at least
> 	and eliminate common subexpressions
> 	will see if we can get Windows to draw much more of this
> 	using DrawFrameControl
> 


From martinbishop at bellsouth.net  Thu Aug 14 01:22:28 2008
From: martinbishop at bellsouth.net (Martin Bishop)
Date: Wed, 13 Aug 2008 18:22:28 -0500
Subject: [M3devel] CM3IDE
Message-ID: <48A36CB4.3050005@bellsouth.net>

I asked this on the mailing list, but I'll ask here too.

I compiled CM3, and all went well, but when I try to run "cm3ide" it
asks me for browser and editor to use, which I tell it, and then it just
hangs.

I tried going to http://localhost:3800, but it doesn't appear any
service is running (browser just gives an error)


From martinbishop at bellsouth.net  Thu Aug 14 01:57:42 2008
From: martinbishop at bellsouth.net (Martin Bishop)
Date: Wed, 13 Aug 2008 18:57:42 -0500
Subject: [M3devel] CM3IDE
In-Reply-To: <48A36CB4.3050005@bellsouth.net>
References: <48A36CB4.3050005@bellsouth.net>
Message-ID: <48A374F6.4090409@bellsouth.net>

Martin Bishop wrote:
> I asked this on the mailing list, but I'll ask here too.
> 
> I compiled CM3, and all went well, but when I try to run "cm3ide" it
> asks me for browser and editor to use, which I tell it, and then it just
> hangs.
> 
> I tried going to http://localhost:3800, but it doesn't appear any
> service is running (browser just gives an error)
> 

Of course I meant on the usenet group, as this IS the mailing list :P


From rcoleburn at scires.com  Thu Aug 14 05:30:23 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Wed, 13 Aug 2008 23:30:23 -0400
Subject: [M3devel] FW: [M3commit] CVS Update: cm3
Message-ID: <48A36E8F020000D7000461EC@SRCMAIL.scires.com>

Jay:

I have a "working" version of the Win32 version of the ScrollerVBTClass.m3.  I put "working" in quotes because some of the behavior is a bit awkward.  Actually, I've been working on an improved version, but wasn't ready to release it yet.

This Win32 version came from an effort where my company paid Critical Mass to make some modifications to Trestle/FormsVBT to make it appear more like Microsoft Windows.  Unfortunately, the CMass effort on the scroll bar didn't turn out as well as some of their other efforts.  

I've made some improvements in it recently, and I think the version I emailed to you contained some of those improvements.

One of the big issues is that the platform-independent interface for the scroll bar defines things very differently from Windows.  For example, you use the left button to scroll forward and the right button to scroll backward, and then there is the whole issue of scrolling in proportion to the distance from the thumb to the mouse click.  CMass tried to hack the POSIX form of the module to come up with something that worked under Windows, but it doesn't quite get it right.  One of the changes I made recently at least fixed the appearance of the scroll bar, especially when scaled pixmaps are in use.  My change forces the trough to occupy the same width/height of the arrow buttons.  I was working on other improvements when I got sidetracked with the resolution problem on the customer's Dell M4300 computer.

At this point, my most pressing issue is indeed how to make the ZMoveVBT/ZChassisVBT work properly for subwindow movement on the M4300 hi-res computer.  At this point, I can give the customer two versions of the software:  (1) everything "works", but the appearance is bad because pixmaps are doubled in size, or (2) everything looks great, but you can't move the subwindows around.  Both of these versions are unacceptable to the customer, so I've got to come up with a fix.  Once I've done that, I can resume my effort with the scroll bar.

Regards,
Randy

>>> Jay <jay.krell at cornell.edu> 08/13/08 7:31 AM >>>

Randy, sorry
1) I didn't realize the functions were in use.
2) I couldn't figure out what each number means. I did try varying them and seeing the affect.
I think maybe I need to learn the X Windows terms? I know in Mac/Windows the part you can drag is the "thumb".

I think I preserved your intent. Feel free to reinstate your intent.
I brought up formsedit and only could easily see a vertical scrollbar.
It doesn't look right to me, but I suspect it is.
If the layers of Trestle could be understand and plowed through, DrawFrameControl would be good.
I've misplaced my Nelson. I'll get another and see if I can understand this..
I'm also curious to see if Tk and Qt draw scrollbars themselves or not.
I'll probably check soon (or by end of month, will be gone next week, out of touch).

 - Jay




----------------------------------------
[big mess made by the ever non-working email systems..]
> Date: Wed, 13 Aug 2008 13:10:59 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT:	/usr/cvs
> Changes by:	jkrell at birch.	08/08/13 13:10:59
> 
> Modified files:
> 	cm3/m3-ui/vbtkit/src/lego/WIN32/: ScrollerVBTClass.m3 
> 
> Log message:
> 	fix it to compile, at least
> 	and eliminate common subexpressions
> 	will see if we can get Windows to draw much more of this
> 	using DrawFrameControl
> 




From rcoleburn at scires.com  Thu Aug 14 05:38:59 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Wed, 13 Aug 2008 23:38:59 -0400
Subject: [M3devel] FW: [M3commit] CVS Update: cm3
Message-ID: <48A37093020000D7000461F1@SRCMAIL.scires.com>

Jay:

After reading your message again, it seems that you may not have received the versions of Image.i3/m3 and ScrollerVBTClass that I sent you.  I had already done the work to remove ImageInit from ScrollerVBTClass and Image.  I just didn't commit it to the repository because everything is still in a state of flux.  The versions I sent also included my new procedure for forcing use of Unscaled pixmaps.

If you like, I can resend these, or commit the versions I have to the repository.  The latter would at least put things right for anyone else using the software right now while we work on a better solution.  Let me know.

BTW, I wasn't able to work on any Modula-3 today because I had to travel for business.  Unfortunately, I'm going to lose a bit more time in the next couple of days because of a tragic death (auto accident) in my extended family.

I'm due at the customer facility on Monday morning, so unfortunately I'm also quickly running out of time for a solution.

Regards,
Randy

Randy C. Coleburn
Senior Systems Engineer, Communications, Networks, & Electronics Division (CNE)
Corporate & Atlanta Information Systems Security Manager (ISSM)
Scientific Research Corporation
2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339
voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) 989-9497

Quality Policy:  "SRC CNE Division is committed to delivering continually improving research & engineering excellence that meets or exceeds customer requirements."
>>> Jay <jay.krell at cornell.edu> 08/13/08 7:31 AM >>>

Randy, sorry
1) I didn't realize the functions were in use.
2) I couldn't figure out what each number means. I did try varying them and seeing the affect.
I think maybe I need to learn the X Windows terms? I know in Mac/Windows the part you can drag is the "thumb".

I think I preserved your intent. Feel free to reinstate your intent.
I brought up formsedit and only could easily see a vertical scrollbar.
It doesn't look right to me, but I suspect it is.
If the layers of Trestle could be understand and plowed through, DrawFrameControl would be good.
I've misplaced my Nelson. I'll get another and see if I can understand this..
I'm also curious to see if Tk and Qt draw scrollbars themselves or not.
I'll probably check soon (or by end of month, will be gone next week, out of touch).

 - Jay




----------------------------------------
[big mess made by the ever non-working email systems..]
> Date: Wed, 13 Aug 2008 13:10:59 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT:	/usr/cvs
> Changes by:	jkrell at birch.	08/08/13 13:10:59
> 
> Modified files:
> 	cm3/m3-ui/vbtkit/src/lego/WIN32/: ScrollerVBTClass.m3 
> 
> Log message:
> 	fix it to compile, at least
> 	and eliminate common subexpressions
> 	will see if we can get Windows to draw much more of this
> 	using DrawFrameControl
> 




From rcoleburn at scires.com  Thu Aug 14 05:57:32 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Wed, 13 Aug 2008 23:57:32 -0400
Subject: [M3devel] CM3IDE
Message-ID: <48A374ED020000D7000461FC@SRCMAIL.scires.com>

Martin:

Thanks for your question.

Please let me know what operating system platform you are using.

The first time you run CM3IDE, it asks about which editor and which browser you want to use.  These questions can be avoided by putting the information in your CM3.CFG file.

If you are using Microsoft IE and Windows, the required format of the response to the console dialog questions is not obvious.  

I will be glad to try and help you resolve this problem.  Please understand that CM3IDE is a new addition to the cm3 codebase and we are still working out some kinks.

Regards,
Randy

>>> Martin Bishop <martinbishop at bellsouth.net> 08/13/08 7:57 PM >>>
Martin Bishop wrote:
> I asked this on the mailing list, but I'll ask here too.
> 
> I compiled CM3, and all went well, but when I try to run "cm3ide" it
> asks me for browser and editor to use, which I tell it, and then it just
> hangs.
> 
> I tried going to http://localhost:3800, but it doesn't appear any
> service is running (browser just gives an error)
> 

Of course I meant on the usenet group, as this IS the mailing list :P




From rcoleburn at scires.com  Thu Aug 14 06:43:07 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Thu, 14 Aug 2008 00:43:07 -0400
Subject: [M3devel] CM3IDE
In-Reply-To: <48A374ED020000D7000461FC@SRCMAIL.scires.com>
References: <48A374ED020000D7000461FC@SRCMAIL.scires.com>
Message-ID: <48A37F94.1E75.00D7.1@scires.com>

Martin:
 
Sorry, I reread my post and realized I forgot to tell you the variables that can go into cm3\bin\cm3.cfg
 
INITIAL_CM3_IDE_BROWSER
INITIAL_CM3_IDE_EDITOR
 
If you are on Windows, you will need to escape the backslash character, e.g.
INITIAL_CM3_IDE_BROWSER="C:\\Program Files\\Internet Explorer\\iexplore.exe"
 
You should set the following environment variable to point to the location where your "private" Modula-3 projects are stored:  CM3_IDE_HOME
 
For example, CM3_IDE_HOME=C:\MyM3Projects
 
If you are using Microsoft Windows and you want to use paths with spaces, you should use the Microsoft short name equivalents, e.g., CM3_IDE_HOME=C:\DOCUME~1\mbishop\MYDOCU~1\CM3Home
 
Regards,
Randy

>>> "Randy Coleburn" <rcoleburn at scires.com> 8/13/2008 11:57 PM >>>
Martin:

Thanks for your question.

Please let me know what operating system platform you are using.

The first time you run CM3IDE, it asks about which editor and which browser you want to use.  These questions can be avoided by putting the information in your CM3.CFG file.

If you are using Microsoft IE and Windows, the required format of the response to the console dialog questions is not obvious.  

I will be glad to try and help you resolve this problem.  Please understand that CM3IDE is a new addition to the cm3 codebase and we are still working out some kinks.

Regards,
Randy

>>> Martin Bishop <martinbishop at bellsouth.net> 08/13/08 7:57 PM >>>
Martin Bishop wrote:
> I asked this on the mailing list, but I'll ask here too.
> 
> I compiled CM3, and all went well, but when I try to run "cm3ide" it
> asks me for browser and editor to use, which I tell it, and then it just
> hangs.
> 
> I tried going to http://localhost:3800, but it doesn't appear any
> service is running (browser just gives an error)
> 

Of course I meant on the usenet group, as this IS the mailing list :P



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080814/ca4f1365/attachment-0001.html>

From mika at async.caltech.edu  Thu Aug 14 10:08:54 2008
From: mika at async.caltech.edu (Mika Nystrom)
Date: Thu, 14 Aug 2008 01:08:54 -0700
Subject: [M3devel] FW: [M3commit] CVS Update: cm3
In-Reply-To: Your message of "Wed, 13 Aug 2008 23:30:23 EDT."
	<48A36E8F020000D7000461EC@SRCMAIL.scires.com> 
Message-ID: <200808140808.m7E88shk081883@camembert.async.caltech.edu>

...
>I've misplaced my Nelson. I'll get another and see if I can understand this..

You may want to just google for "SRC Research Report 68" and "...69"

    Mika

>I'm also curious to see if Tk and Qt draw scrollbars themselves or not.
>I'll probably check soon (or by end of month, will be gone next week, out of t
>ouch).
>
> - Jay


From jay.krell at cornell.edu  Thu Aug 14 14:17:29 2008
From: jay.krell at cornell.edu (Jay)
Date: Thu, 14 Aug 2008 12:17:29 +0000
Subject: [M3devel] FW: [M3commit] CVS Update: cm3
In-Reply-To: <200808140808.m7E88shk081883@camembert.async.caltech.edu>
References: Your message of 
	<200808140808.m7E88shk081883@camembert.async.caltech.edu>
Message-ID: <COL101-W2370AECE37D9828B834395E6720@phx.gbl>


Awesome, thanks.

 - Jay


> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] FW: [M3commit] CVS Update: cm3
> Date: Thu, 14 Aug 2008 01:08:54 -0700
> From: mika at async.caltech.edu
>
> ...
>>I've misplaced my Nelson. I'll get another and see if I can understand this..
>
> You may want to just google for "SRC Research Report 68" and "...69"
>
> Mika
>
>>I'm also curious to see if Tk and Qt draw scrollbars themselves or not.
>>I'll probably check soon (or by end of month, will be gone next week, out of t
>>ouch).
>>
>> - Jay


From jay.krell at cornell.edu  Thu Aug 14 14:46:06 2008
From: jay.krell at cornell.edu (Jay)
Date: Thu, 14 Aug 2008 12:46:06 +0000
Subject: [M3devel] windows move/scroller
Message-ID: <COL101-W123B5E9D268CE608107D40E6720@phx.gbl>


Randy, your scrollervbclass.m3 looks ok or better.

I went to try other gui apps, see if I could see the failure-to-move bug.
It seems that most gui apps now crash.
formsvbtedit is ok.


***
*** runtime error:
***     failed.
***    file "..\src\winvbt\WinContext.m3", line 171
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0x6e1f80c  0x1011cf9  PushPixmap + 0x49b in ..\src\winvbt\WinContext.m3
0x6e1f8d4  0x101fd0c  PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3
0x6e1fd30  0x101dc35  PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3
0x6e1fd98  0x10184ee  PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3
0x6e1fde0  0x1016ded  WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3
0x6e1fe0c  0x7d9472d8  
0x6e1fe84  0x7d947568  
0x6e1fefc  0x7d94778d  
0x6e1ff0c  0x7d94ab86  
0x6e1ff54  0x101bbc9  MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3
.........  .........  ... more frames ...
(a3c.aec): Break instruction exception - code 80000003 (first chance)
eax=00000001 ebx=000000ab ecx=0000ff27 edx=0000001c esi=06e1f5b0 edi=006358eb
eip=7d61002d esp=06e1f598 ebp=06e1f5b0 iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202
ntdll32!DbgBreakPoint:
7d61002d cc              int     3


The "funny" thing is that when this occurs, lots of scrollbar arrows have been drawn
at the wrong place -- filling up Juno's canvas.

This happens with current ScrollerVBClass.m3, or copying the Posix one over Win32,
or your current one.

I changed PushPixMap to print GetLastError, but it is 0. :(

I'll dig a bit.

Not great.
 - Jay


From jay.krell at cornell.edu  Thu Aug 14 15:07:09 2008
From: jay.krell at cornell.edu (Jay)
Date: Thu, 14 Aug 2008 13:07:09 +0000
Subject: [M3devel] another trestle bug..
Message-ID: <COL101-W3271758E974746EF2E7BEBE6720@phx.gbl>


Sigh..in FormsVBTEdit, control-a to select all, control-c to copy, control-c to copy again:



***
*** runtime error:
***    Thread client error: Attempt to lock mutex already locked by self
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 155
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0x6a0f1d0   0x57ba8c  Die + 0x2d in ..\src\thread\WIN32\ThreadWin32.m3
0x6a0f204   0x578d22  LockMutex + 0x13a in ..\src\thread\WIN32\ThreadWin32.m3
0x6a0f24c   0xec9f01  LostClipboard + 0x7f in ..\src\winvbt\WinTrestle.m3
0x6a0f288   0xec702c  WindowProc + 0x8c8 in ..\src\winvbt\WinTrestle.m3
0x6a0f2b4  0x7d9472d8  
0x6a0f32c  0x7d947568  
0x6a0f388  0x7d947d93  
0x6a0f3c8  0x7d969cb2  
0x6a0f43c  0x7d61ea0e  
0x6a0f46c   0xec4506  Acquire + 0x2f in ..\src\winvbt\WinTrestle.m3
.........  .........  ... more frames ...

full stack is:


ChildEBP RetAddr
06a0f144 00575937 ntdll32!DbgBreakPoint
06a0f160 0056c42e m3core!RTOS__Crash+0x4c
06a0f178 0056a19e m3core!RTProcess__Crash+0x68
06a0f190 00569e1d m3core!RTError__EndError+0x37
06a0f1a8 0057ba8c m3core!RTError__Msg+0x8d
06a0f1d0 00578d22 m3core!ThreadWin32__Die+0x2d
06a0f204 00ec9f01 m3core!ThreadWin32__LockMutex+0x13a
06a0f24c 00ec702c m3ui!WinTrestle__LostClipboard+0x7f
06a0f288 7d9472d8 m3ui!WinTrestle__WindowProc+0x8c8
06a0f2b4 7d947568 user32!InternalCallWinProc+0x28
06a0f32c 7d947d93 user32!UserCallWinProcCheckWow+0x114
06a0f388 7d969cb2 user32!DispatchClientMessage+0xdf
06a0f3c8 7d61ea0e user32!__fnINDESTROYCLIPBRD+0x2c
06a0f3fc 00ec46bf ntdll32!KiUserCallbackDispatcher+0x2e
06a0f43c 00ec4506 m3ui!WinTrestle__Acquire__AcquireClipboard+0xf5
06a0f46c 00f327d8 m3ui!WinTrestle__Acquire+0x2f
06a0f4bc 00eedf1a m3ui!ETAgent__Acquire+0x21e
06a0f4f8 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
06a0f534 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
06a0f570 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
06a0f5ac 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
06a0f5e8 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
06a0f624 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
06a0f660 00f327d8 m3ui!VBTClass__AcquireDefault+0x110
06a0f6b0 00e06f96 m3ui!ETAgent__Acquire+0x21e
06a0f6e8 00eedf1a m3vbtkit!ReactivityVBT__Acquire+0x46
06a0f724 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
06a0f760 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
06a0f79c 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
06a0f7d8 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
06a0f814 00eed0e7 m3ui!VBTClass__AcquireDefault+0x110
06a0f848 00ee191b m3ui!VBTClass__Acquire+0xe1
06a0f874 00e3c80d m3ui!VBT__Acquire+0x56
06a0f918 00e3c737 m3vbtkit!TextPortClass__TakeSelection__take+0x7e
06a0f944 00e49ace m3vbtkit!TextPortClass__TakeSelection+0xbe
06a0f97c 00e49109 m3vbtkit!MacModel__Copy+0x87
06a0f9a4 00e3407d m3vbtkit!MacModel__ControlChord+0xd9
06a0fa1c 10026730 m3vbtkit!TextPort__Filter+0x243
06a0fa58 00405eaa m3formsvbt!FVRuntime__PortFilter+0xc3
06a0fb18 00e33e32 formsedit!FormsEditVBT__EPortFilter+0x3ac
06a0fb48 00e48c0e m3vbtkit!TextPort__ApplyStandardKeyFilter+0x89
06a0fb98 00e33da1 m3vbtkit!MacModel__ApplyMacFilter+0xcf
06a0fbf8 00eeae96 m3vbtkit!TextPort__Key+0x1a4
06a0fc30 00f33cd5 m3ui!VBTClass__Key+0xa5
06a0fc74 00e06f48 m3ui!ETAgent__KeyCode+0x19b
06a0fc94 00eeae96 m3vbtkit!ReactivityVBT__Key+0x42
06a0fccc 00f33cd5 m3ui!VBTClass__Key+0xa5
06a0fd10 00eeae96 m3ui!ETAgent__KeyCode+0x19b
06a0fd48 00ec8fbf m3ui!VBTClass__Key+0xa5
06a0fd9c 00ec6ef0 m3ui!WinTrestle__VBTKeyPress+0xfd
06a0fde0 7d9472d8 m3ui!WinTrestle__WindowProc+0x78c
06a0fe0c 7d947568 user32!InternalCallWinProc+0x28
06a0fe84 7d94778d user32!UserCallWinProcCheckWow+0x114
06a0fefc 7d94ab86 user32!DispatchMessageWorker+0x37b
06a0ff0c 00ecbbd9 user32!DispatchMessageA+0xf
06a0ff54 0057a69a m3ui!WinTrestle__MessengerApply+0x21f
06a0ff8c 0057a433 m3core!ThreadWin32__RunThread+0x1f6
06a0ffb8 7d4dfe21 m3core!ThreadWin32__ThreadBase+0x3a
06a0ffec 00000000 kernel32!BaseThreadStart+0x34


From wagner at elegosoft.com  Thu Aug 14 15:16:38 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Thu, 14 Aug 2008 15:16:38 +0200
Subject: [M3devel] another trestle bug..
In-Reply-To: <COL101-W3271758E974746EF2E7BEBE6720@phx.gbl>
References: <COL101-W3271758E974746EF2E7BEBE6720@phx.gbl>
Message-ID: <20080814151638.enfxv3axvok0g8wc@mail.elegosoft.com>

Quoting Jay <jay.krell at cornell.edu>:

>
> Sigh..in FormsVBTEdit, control-a to select all, control-c to copy,   
> control-c to copy again:
>
>
>
> ***
> *** runtime error:
> ***    Thread client error: Attempt to lock mutex already locked by self
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 155
> ***

This may well be a side-effect of my changes, though I didn't notice
it. You may want to check the old code of the MacModel :-/
If it is, we have to review the mutex use.

Olaf

> Stack trace:
>    FP         PC      Procedure
> ---------  ---------  -------------------------------
> 0x6a0f1d0   0x57ba8c  Die + 0x2d in ..\src\thread\WIN32\ThreadWin32.m3
> 0x6a0f204   0x578d22  LockMutex + 0x13a in ..\src\thread\WIN32\ThreadWin32.m3
> 0x6a0f24c   0xec9f01  LostClipboard + 0x7f in ..\src\winvbt\WinTrestle.m3
> 0x6a0f288   0xec702c  WindowProc + 0x8c8 in ..\src\winvbt\WinTrestle.m3
> 0x6a0f2b4  0x7d9472d8
> 0x6a0f32c  0x7d947568
> 0x6a0f388  0x7d947d93
> 0x6a0f3c8  0x7d969cb2
> 0x6a0f43c  0x7d61ea0e
> 0x6a0f46c   0xec4506  Acquire + 0x2f in ..\src\winvbt\WinTrestle.m3
> .........  .........  ... more frames ...
>
> full stack is:
>
>
> ChildEBP RetAddr
> 06a0f144 00575937 ntdll32!DbgBreakPoint
> 06a0f160 0056c42e m3core!RTOS__Crash+0x4c
> 06a0f178 0056a19e m3core!RTProcess__Crash+0x68
> 06a0f190 00569e1d m3core!RTError__EndError+0x37
> 06a0f1a8 0057ba8c m3core!RTError__Msg+0x8d
> 06a0f1d0 00578d22 m3core!ThreadWin32__Die+0x2d
> 06a0f204 00ec9f01 m3core!ThreadWin32__LockMutex+0x13a
> 06a0f24c 00ec702c m3ui!WinTrestle__LostClipboard+0x7f
> 06a0f288 7d9472d8 m3ui!WinTrestle__WindowProc+0x8c8
> 06a0f2b4 7d947568 user32!InternalCallWinProc+0x28
> 06a0f32c 7d947d93 user32!UserCallWinProcCheckWow+0x114
> 06a0f388 7d969cb2 user32!DispatchClientMessage+0xdf
> 06a0f3c8 7d61ea0e user32!__fnINDESTROYCLIPBRD+0x2c
> 06a0f3fc 00ec46bf ntdll32!KiUserCallbackDispatcher+0x2e
> 06a0f43c 00ec4506 m3ui!WinTrestle__Acquire__AcquireClipboard+0xf5
> 06a0f46c 00f327d8 m3ui!WinTrestle__Acquire+0x2f
> 06a0f4bc 00eedf1a m3ui!ETAgent__Acquire+0x21e
> 06a0f4f8 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
> 06a0f534 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
> 06a0f570 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
> 06a0f5ac 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
> 06a0f5e8 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
> 06a0f624 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
> 06a0f660 00f327d8 m3ui!VBTClass__AcquireDefault+0x110
> 06a0f6b0 00e06f96 m3ui!ETAgent__Acquire+0x21e
> 06a0f6e8 00eedf1a m3vbtkit!ReactivityVBT__Acquire+0x46
> 06a0f724 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
> 06a0f760 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
> 06a0f79c 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
> 06a0f7d8 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
> 06a0f814 00eed0e7 m3ui!VBTClass__AcquireDefault+0x110
> 06a0f848 00ee191b m3ui!VBTClass__Acquire+0xe1
> 06a0f874 00e3c80d m3ui!VBT__Acquire+0x56
> 06a0f918 00e3c737 m3vbtkit!TextPortClass__TakeSelection__take+0x7e
> 06a0f944 00e49ace m3vbtkit!TextPortClass__TakeSelection+0xbe
> 06a0f97c 00e49109 m3vbtkit!MacModel__Copy+0x87
> 06a0f9a4 00e3407d m3vbtkit!MacModel__ControlChord+0xd9
> 06a0fa1c 10026730 m3vbtkit!TextPort__Filter+0x243
> 06a0fa58 00405eaa m3formsvbt!FVRuntime__PortFilter+0xc3
> 06a0fb18 00e33e32 formsedit!FormsEditVBT__EPortFilter+0x3ac
> 06a0fb48 00e48c0e m3vbtkit!TextPort__ApplyStandardKeyFilter+0x89
> 06a0fb98 00e33da1 m3vbtkit!MacModel__ApplyMacFilter+0xcf
> 06a0fbf8 00eeae96 m3vbtkit!TextPort__Key+0x1a4
> 06a0fc30 00f33cd5 m3ui!VBTClass__Key+0xa5
> 06a0fc74 00e06f48 m3ui!ETAgent__KeyCode+0x19b
> 06a0fc94 00eeae96 m3vbtkit!ReactivityVBT__Key+0x42
> 06a0fccc 00f33cd5 m3ui!VBTClass__Key+0xa5
> 06a0fd10 00eeae96 m3ui!ETAgent__KeyCode+0x19b
> 06a0fd48 00ec8fbf m3ui!VBTClass__Key+0xa5
> 06a0fd9c 00ec6ef0 m3ui!WinTrestle__VBTKeyPress+0xfd
> 06a0fde0 7d9472d8 m3ui!WinTrestle__WindowProc+0x78c
> 06a0fe0c 7d947568 user32!InternalCallWinProc+0x28
> 06a0fe84 7d94778d user32!UserCallWinProcCheckWow+0x114
> 06a0fefc 7d94ab86 user32!DispatchMessageWorker+0x37b
> 06a0ff0c 00ecbbd9 user32!DispatchMessageA+0xf
> 06a0ff54 0057a69a m3ui!WinTrestle__MessengerApply+0x21f
> 06a0ff8c 0057a433 m3core!ThreadWin32__RunThread+0x1f6
> 06a0ffb8 7d4dfe21 m3core!ThreadWin32__ThreadBase+0x3a
> 06a0ffec 00000000 kernel32!BaseThreadStart+0x34
>



-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From jay.krell at cornell.edu  Thu Aug 14 15:11:19 2008
From: jay.krell at cornell.edu (Jay)
Date: Thu, 14 Aug 2008 13:11:19 +0000
Subject: [M3devel] another trestle bug..
In-Reply-To: <COL101-W3271758E974746EF2E7BEBE6720@phx.gbl>
References: <COL101-W3271758E974746EF2E7BEBE6720@phx.gbl>
Message-ID: <COL101-W57222A54717D1E92781042E6720@phx.gbl>


Better yet, with file/line:


ChildEBP RetAddr
06a0f144 00575937 ntdll32!DbgBreakPoint
06a0f160 0056c42e m3core!RTOS__Crash+0x4c [..\src\runtime\WIN32\RTOS.m3 @ 29]
06a0f178 0056a19e m3core!RTProcess__Crash+0x68 [..\src\runtime\common\RTProcess.m3 @ 66]
06a0f190 00569e1d m3core!RTError__EndError+0x37 [..\src\runtime\common\RTError.m3 @ 118]
06a0f1a8 0057ba8c m3core!RTError__Msg+0x8d [..\src\runtime\common\RTError.m3 @ 23]
06a0f1d0 00578d22 m3core!ThreadWin32__Die+0x2d [..\src\thread\WIN32\ThreadWin32.m3 @ 982]
06a0f204 00ec9f01 m3core!ThreadWin32__LockMutex+0x13a [..\src\thread\WIN32\ThreadWin32.m3 @ 155]
06a0f24c 00ec702c m3ui!WinTrestle__LostClipboard+0x7f [..\src\winvbt\WinTrestle.m3 @ 2044]
06a0f288 7d9472d8 m3ui!WinTrestle__WindowProc+0x8c8 [..\src\winvbt\WinTrestle.m3 @ 1211]
06a0f2b4 7d947568 user32!InternalCallWinProc+0x28
06a0f32c 7d947d93 user32!UserCallWinProcCheckWow+0x114
06a0f388 7d969cb2 user32!DispatchClientMessage+0xdf
06a0f3c8 7d61ea0e user32!__fnINDESTROYCLIPBRD+0x2c
06a0f3fc 00ec46bf ntdll32!KiUserCallbackDispatcher+0x2e
06a0f43c 00ec4506 m3ui!WinTrestle__Acquire__AcquireClipboard+0xf5 [..\src\winvbt\WinTrestle.m3 @ 431]
06a0f46c 00f327d8 m3ui!WinTrestle__Acquire+0x2f [..\src\winvbt\WinTrestle.m3 @ 445]
06a0f4bc 00eedf1a m3ui!ETAgent__Acquire+0x21e [..\src\split\ETAgent.m3 @ 120]
06a0f4f8 00eedf1a m3ui!VBTClass__AcquireDefault+0x110 [..\src\vbt\VBTClass.m3 @834]
06a0f534 00eedf1a m3ui!VBTClass__AcquireDefault+0x110 [..\src\vbt\VBTClass.m3 @834]
06a0f570 00eedf1a m3ui!VBTClass__AcquireDefault+0x110 [..\src\vbt\VBTClass.m3 @834]
06a0f5ac 00eedf1a m3ui!VBTClass__AcquireDefault+0x110 [..\src\vbt\VBTClass.m3 @834]
06a0f5e8 00eedf1a m3ui!VBTClass__AcquireDefault+0x110 [..\src\vbt\VBTClass.m3 @834]
06a0f624 00eedf1a m3ui!VBTClass__AcquireDefault+0x110 [..\src\vbt\VBTClass.m3 @834]
06a0f660 00f327d8 m3ui!VBTClass__AcquireDefault+0x110 [..\src\vbt\VBTClass.m3 @834]
06a0f6b0 00e06f96 m3ui!ETAgent__Acquire+0x21e [..\src\split\ETAgent.m3 @ 120]
06a0f6e8 00eedf1a m3vbtkit!ReactivityVBT__Acquire+0x46 [..\src\lego\ReactivityVBT.m3 @ 222]
06a0f724 00eedf1a m3ui!VBTClass__AcquireDefault+0x110 [..\src\vbt\VBTClass.m3 @834]
06a0f760 00eedf1a m3ui!VBTClass__AcquireDefault+0x110 [..\src\vbt\VBTClass.m3 @834]
06a0f79c 00eedf1a m3ui!VBTClass__AcquireDefault+0x110 [..\src\vbt\VBTClass.m3 @834]
06a0f7d8 00eedf1a m3ui!VBTClass__AcquireDefault+0x110 [..\src\vbt\VBTClass.m3 @834]
06a0f814 00eed0e7 m3ui!VBTClass__AcquireDefault+0x110 [..\src\vbt\VBTClass.m3 @834]
06a0f848 00ee191b m3ui!VBTClass__Acquire+0xe1 [..\src\vbt\VBTClass.m3 @ 612]
06a0f874 00e3c80d m3ui!VBT__Acquire+0x56 [..\src\vbt\VBT.m3 @ 156]
06a0f918 00e3c737 m3vbtkit!TextPortClass__TakeSelection__take+0x7e [..\src\etext\TextPortClass.m3 @ 833]
06a0f944 00e49ace m3vbtkit!TextPortClass__TakeSelection+0xbe [..\src\etext\TextPortClass.m3 @ 852]
06a0f97c 00e49109 m3vbtkit!MacModel__Copy+0x87 [..\src\etext\MacModel.m3 @ 371]
06a0f9a4 00e3407d m3vbtkit!MacModel__ControlChord+0xd9 [..\src\etext\MacModel.m3 @ 269]
06a0fa1c 10026730 m3vbtkit!TextPort__Filter+0x243 [..\src\etext\TextPort.m3 @ 768]
06a0fa58 00405eaa m3formsvbt!FVRuntime__PortFilter+0xc3 [..\src\FVRuntime.m3 @ 819]
06a0fb18 00e33e32 formsedit!FormsEditVBT__EPortFilter+0x3ac [..\src\FormsEditVBT.m3 @ 711]
06a0fb48 00e48c0e m3vbtkit!TextPort__ApplyStandardKeyFilter+0x89 [..\src\etext\TextPort.m3 @ 740]
06a0fb98 00e33da1 m3vbtkit!MacModel__ApplyMacFilter+0xcf [..\src\etext\MacModel.m3 @ 91]
06a0fbf8 00eeae96 m3vbtkit!TextPort__Key+0x1a4 [..\src\etext\TextPort.m3 @ 732]
06a0fc30 00f33cd5 m3ui!VBTClass__Key+0xa5 [..\src\vbt\VBTClass.m3 @ 250]
06a0fc74 00e06f48 m3ui!ETAgent__KeyCode+0x19b [..\src\split\ETAgent.m3 @ 295]
06a0fc94 00eeae96 m3vbtkit!ReactivityVBT__Key+0x42 [..\src\lego\ReactivityVBT.m3 @ 215]
06a0fccc 00f33cd5 m3ui!VBTClass__Key+0xa5 [..\src\vbt\VBTClass.m3 @ 250]
06a0fd10 00eeae96 m3ui!ETAgent__KeyCode+0x19b [..\src\split\ETAgent.m3 @ 295]
06a0fd48 00ec8fbf m3ui!VBTClass__Key+0xa5 [..\src\vbt\VBTClass.m3 @ 250]
06a0fd9c 00ec6ef0 m3ui!WinTrestle__VBTKeyPress+0xfd [..\src\winvbt\WinTrestle.m3 @ 1734]
06a0fde0 7d9472d8 m3ui!WinTrestle__WindowProc+0x78c [..\src\winvbt\WinTrestle.m3 @ 1178]
06a0fe0c 7d947568 user32!InternalCallWinProc+0x28
06a0fe84 7d94778d user32!UserCallWinProcCheckWow+0x114
06a0fefc 7d94ab86 user32!DispatchMessageWorker+0x37b
06a0ff0c 00ecbbd9 user32!DispatchMessageA+0xf
06a0ff54 0057a69a m3ui!WinTrestle__MessengerApply+0x21f [..\src\winvbt\WinTrestle.m3 @ 2436]
06a0ff8c 0057a433 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread\WIN32\ThreadWin32.m3 @ 579]
06a0ffb8 7d4dfe21 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread\WIN32\ThreadWin32.m3 @ 548]
06a0ffec 00000000 kernel32!BaseThreadStart+0x34


 - Jay

> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Date: Thu, 14 Aug 2008 13:07:09 +0000
> Subject: [M3devel] another trestle bug..
>
>
> Sigh..in FormsVBTEdit, control-a to select all, control-c to copy, control-c to copy again:
>
>
>
> ***
> *** runtime error:
> *** Thread client error: Attempt to lock mutex already locked by self
> *** file "..\src\thread\WIN32\ThreadWin32.m3", line 155
> ***
>
> Stack trace:
> FP PC Procedure
> --------- --------- -------------------------------
> 0x6a0f1d0 0x57ba8c Die + 0x2d in ..\src\thread\WIN32\ThreadWin32.m3
> 0x6a0f204 0x578d22 LockMutex + 0x13a in ..\src\thread\WIN32\ThreadWin32.m3
> 0x6a0f24c 0xec9f01 LostClipboard + 0x7f in ..\src\winvbt\WinTrestle.m3
> 0x6a0f288 0xec702c WindowProc + 0x8c8 in ..\src\winvbt\WinTrestle.m3
> 0x6a0f2b4 0x7d9472d8
> 0x6a0f32c 0x7d947568
> 0x6a0f388 0x7d947d93
> 0x6a0f3c8 0x7d969cb2
> 0x6a0f43c 0x7d61ea0e
> 0x6a0f46c 0xec4506 Acquire + 0x2f in ..\src\winvbt\WinTrestle.m3
> ......... ......... ... more frames ...
>
> full stack is:
>
>
> ChildEBP RetAddr
> 06a0f144 00575937 ntdll32!DbgBreakPoint
> 06a0f160 0056c42e m3core!RTOS__Crash+0x4c
...

From wagner at elegosoft.com  Thu Aug 14 15:20:40 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Thu, 14 Aug 2008 15:20:40 +0200
Subject: [M3devel] windows move/scroller
In-Reply-To: <COL101-W123B5E9D268CE608107D40E6720@phx.gbl>
References: <COL101-W123B5E9D268CE608107D40E6720@phx.gbl>
Message-ID: <20080814152040.tu00bh7jqckg0w8w@mail.elegosoft.com>

Quoting Jay <jay.krell at cornell.edu>:

>
> Randy, your scrollervbclass.m3 looks ok or better.
>
> I went to try other gui apps, see if I could see the failure-to-move bug.
> It seems that most gui apps now crash.
> formsvbtedit is ok.
>
>
> ***
> *** runtime error:
> ***     failed.
> ***    file "..\src\winvbt\WinContext.m3", line 171
> ***
>
> Stack trace:
>    FP         PC      Procedure
> ---------  ---------  -------------------------------
> 0x6e1f80c  0x1011cf9  PushPixmap + 0x49b in ..\src\winvbt\WinContext.m3
> 0x6e1f8d4  0x101fd0c  PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3
> 0x6e1fd30  0x101dc35  PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3
> 0x6e1fd98  0x10184ee  PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3
> 0x6e1fde0  0x1016ded  WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3
> 0x6e1fe0c  0x7d9472d8
> 0x6e1fe84  0x7d947568
> 0x6e1fefc  0x7d94778d
> 0x6e1ff0c  0x7d94ab86
> 0x6e1ff54  0x101bbc9  MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3
> .........  .........  ... more frames ...
> (a3c.aec): Break instruction exception - code 80000003 (first chance)
> eax=00000001 ebx=000000ab ecx=0000ff27 edx=0000001c esi=06e1f5b0 edi=006358eb
> eip=7d61002d esp=06e1f598 ebp=06e1f5b0 iopl=0         nv up ei pl nz na po nc
> cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202
> ntdll32!DbgBreakPoint:
> 7d61002d cc              int     3
>
>
> The "funny" thing is that when this occurs, lots of scrollbar arrows  
>  have been drawn
> at the wrong place -- filling up Juno's canvas.

Did Juno ever work on Windows' Trestle? I seem to remember that
the Windows implementation was not sufficient for this rather
sophisticated application, too many things were missing.

Olaf

>
> This happens with current ScrollerVBClass.m3, or copying the Posix   
> one over Win32,
> or your current one.
>
> I changed PushPixMap to print GetLastError, but it is 0. :(
>
> I'll dig a bit.
>
> Not great.
>  - Jay
>



-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From rcoleburn at scires.com  Thu Aug 14 16:38:22 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Thu, 14 Aug 2008 10:38:22 -0400
Subject: [M3devel] windows move/scroller
In-Reply-To: <20080814152040.tu00bh7jqckg0w8w@mail.elegosoft.com>
References: <COL101-W123B5E9D268CE608107D40E6720@phx.gbl>
	<20080814152040.tu00bh7jqckg0w8w@mail.elegosoft.com>
Message-ID: <48A40B18.1E75.00D7.1@scires.com>

Sorry, but I haven't used Juno, so I don't know if it worked on
Windows.
Regards,
Randy

>>> Olaf Wagner <wagner at elegosoft.com> 8/14/2008 9:20 AM >>>
Quoting Jay <jay.krell at cornell.edu>:

>
> Randy, your scrollervbclass.m3 looks ok or better.
>
> I went to try other gui apps, see if I could see the failure-to-move
bug.
> It seems that most gui apps now crash.
> formsvbtedit is ok.
>
>
> ***
> *** runtime error:
> ***     failed.
> ***    file "..\src\winvbt\WinContext.m3", line 171
> ***
>
> Stack trace:
>    FP         PC      Procedure
> ---------  ---------  -------------------------------
> 0x6e1f80c  0x1011cf9  PushPixmap + 0x49b in
..\src\winvbt\WinContext.m3
> 0x6e1f8d4  0x101fd0c  PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3
> 0x6e1fd30  0x101dc35  PaintBatch + 0x225 in
..\src\winvbt\WinPaint.m3
> 0x6e1fd98  0x10184ee  PaintBatchVBT + 0x12d in
..\src\winvbt\WinTrestle.m3
> 0x6e1fde0  0x1016ded  WindowProc + 0x699 in
..\src\winvbt\WinTrestle.m3
> 0x6e1fe0c  0x7d9472d8
> 0x6e1fe84  0x7d947568
> 0x6e1fefc  0x7d94778d
> 0x6e1ff0c  0x7d94ab86
> 0x6e1ff54  0x101bbc9  MessengerApply + 0x21f in
..\src\winvbt\WinTrestle.m3
> .........  .........  ... more frames ...
> (a3c.aec): Break instruction exception - code 80000003 (first
chance)
> eax=00000001 ebx=000000ab ecx=0000ff27 edx=0000001c esi=06e1f5b0
edi=006358eb
> eip=7d61002d esp=06e1f598 ebp=06e1f5b0 iopl=0         nv up ei pl nz
na po nc
> cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b            
efl=00000202
> ntdll32!DbgBreakPoint:
> 7d61002d cc              int     3
>
>
> The "funny" thing is that when this occurs, lots of scrollbar arrows 

>  have been drawn
> at the wrong place -- filling up Juno's canvas.

Did Juno ever work on Windows' Trestle? I seem to remember that
the Windows implementation was not sufficient for this rather
sophisticated application, too many things were missing.

Olaf

>
> This happens with current ScrollerVBClass.m3, or copying the Posix  

> one over Win32,
> or your current one.
>
> I changed PushPixMap to print GetLastError, but it is 0. :(
>
> I'll dig a bit.
>
> Not great.
>  - Jay
>



-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin,
Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45
86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz:
Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:
DE163214194


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080814/6256aebf/attachment-0001.html>

From jay.krell at cornell.edu  Thu Aug 14 16:38:33 2008
From: jay.krell at cornell.edu (Jay)
Date: Thu, 14 Aug 2008 14:38:33 +0000
Subject: [M3devel] windows move/scroller
In-Reply-To: <20080814152040.tu00bh7jqckg0w8w@mail.elegosoft.com>
References: <COL101-W123B5E9D268CE608107D40E6720@phx.gbl>
	<20080814152040.tu00bh7jqckg0w8w@mail.elegosoft.com>
Message-ID: <COL101-W298075CF2F20ED878F16C1E6720@phx.gbl>


I admit I can't remember between NT386GNU and NT386.
At least one of them Juno works on, at least better than I'm seeing on NT386 today.
Juno gets pretty far on NT386. The splash screen comes up, the loading progress,
most of the initial gui comes up, except the "canvas" is full of scrollbar arrows.
 
I'll have to try with 3.6/4.1..
 
A few seconds with mentor and I got:
 
D:\dev2\cm3.2\m3-ui\ui\src\winvbt>\cm3\bin\mentor.exeCreatePatternBrush failed with  0
****** runtime error:***    A runtime error occurred.***    pc = 0x7d61002d***
Stack trace:   FP         PC      Procedure---------  ---------  -------------------------------0x72af77c   0x9266ae  SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.m30x72af80c  0x7d61002d  <???>0x72af8d4  0x147fe8c  PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m30x72afd30  0x147ddb5  PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m30x72afd98  0x147867e  PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m30x72afde0  0x1476f7d  WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m30x72afe0c  0x7d9472d8  <???>0x72afe84  0x7d947568  <???>0x72afefc  0x7d94778d  <???>0x72aff0c  0x7d94ab86  <???>.........  .........  ... more frames ...
 
Maybe a divide by zero since I don't know how to setup mentor usefully..
Looks different than Juno.
 
Calculator works.
 
 - Jay
> Date: Thu, 14 Aug 2008 15:20:40 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] windows move/scroller> > Quoting Jay <jay.krell at cornell.edu>:> > >> > Randy, your scrollervbclass.m3 looks ok or better.> >> > I went to try other gui apps, see if I could see the failure-to-move bug.> > It seems that most gui apps now crash.> > formsvbtedit is ok.> >> >> > ***> > *** runtime error:> > *** failed.> > *** file "..\src\winvbt\WinContext.m3", line 171> > ***> >> > Stack trace:> > FP PC Procedure> > --------- --------- -------------------------------> > 0x6e1f80c 0x1011cf9 PushPixmap + 0x49b in ..\src\winvbt\WinContext.m3> > 0x6e1f8d4 0x101fd0c PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3> > 0x6e1fd30 0x101dc35 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3> > 0x6e1fd98 0x10184ee PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3> > 0x6e1fde0 0x1016ded WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3> > 0x6e1fe0c 0x7d9472d8> > 0x6e1fe84 0x7d947568> > 0x6e1fefc 0x7d94778d> > 0x6e1ff0c 0x7d94ab86> > 0x6e1ff54 0x101bbc9 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3> > ......... ......... ... more frames ...> > (a3c.aec): Break instruction exception - code 80000003 (first chance)> > eax=00000001 ebx=000000ab ecx=0000ff27 edx=0000001c esi=06e1f5b0 edi=006358eb> > eip=7d61002d esp=06e1f598 ebp=06e1f5b0 iopl=0 nv up ei pl nz na po nc> > cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202> > ntdll32!DbgBreakPoint:> > 7d61002d cc int 3> >> >> > The "funny" thing is that when this occurs, lots of scrollbar arrows > > have been drawn> > at the wrong place -- filling up Juno's canvas.> > Did Juno ever work on Windows' Trestle? I seem to remember that> the Windows implementation was not sufficient for this rather> sophisticated application, too many things were missing.> > Olaf> > >> > This happens with current ScrollerVBClass.m3, or copying the Posix > > one over Win32,> > or your current one.> >> > I changed PushPixMap to print GetLastError, but it is 0. :(> >> > I'll dig a bit.> >> > Not great.> > - Jay> >> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080814/28a08669/attachment-0001.html>

From jay.krell at cornell.edu  Thu Aug 14 17:01:51 2008
From: jay.krell at cornell.edu (Jay)
Date: Thu, 14 Aug 2008 15:01:51 +0000
Subject: [M3devel] windows move/scroller
In-Reply-To: <20080814152040.tu00bh7jqckg0w8w@mail.elegosoft.com>
References: <COL101-W123B5E9D268CE608107D40E6720@phx.gbl>
	<20080814152040.tu00bh7jqckg0w8w@mail.elegosoft.com> 
Message-ID: <COL101-W37231C33F530CED8ACFD67E6720@phx.gbl>


Juno was not in 3.6 and 4.1.

 - Jay


________________________________

From: jay.krell at cornell.edu
To: wagner at elegosoft.com; m3devel at elegosoft.com
Subject: RE: [M3devel] windows move/scroller
Date: Thu, 14 Aug 2008 14:38:33 +0000




I admit I can't remember between NT386GNU and NT386.
At least one of them Juno works on, at least better than I'm seeing on NT386 today.
Juno gets pretty far on NT386. The splash screen comes up, the loading progress,
most of the initial gui comes up, except the "canvas" is full of scrollbar arrows.

I'll have to try with 3.6/4.1..

A few seconds with mentor and I got:

D:\dev2\cm3.2\m3-ui\ui\src\winvbt>\cm3\bin\mentor.exe
CreatePatternBrush failed with  0

***
*** runtime error:
***    A runtime error occurred.
***    pc = 0x7d61002d
***
Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0x72af77c   0x9266ae  SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.m3
0x72af80c  0x7d61002d  
0x72af8d4  0x147fe8c  PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3
0x72afd30  0x147ddb5  PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3
0x72afd98  0x147867e  PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3
0x72afde0  0x1476f7d  WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3
0x72afe0c  0x7d9472d8  
0x72afe84  0x7d947568  
0x72afefc  0x7d94778d  
0x72aff0c  0x7d94ab86  
.........  .........  ... more frames ...

Maybe a divide by zero since I don't know how to setup mentor usefully..
Looks different than Juno.

Calculator works.

 - Jay

> Date: Thu, 14 Aug 2008 15:20:40 +0200
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] windows move/scroller
>
> Quoting Jay :
>
>>
>> Randy, your scrollervbclass.m3 looks ok or better.
>>
>> I went to try other gui apps, see if I could see the failure-to-move bug.
>> It seems that most gui apps now crash.
>> formsvbtedit is ok.
>>
>>
>> ***
>> *** runtime error:
>> *** failed.
>> *** file "..\src\winvbt\WinContext.m3", line 171
>> ***
>>
>> Stack trace:
>> FP PC Procedure
>> --------- --------- -------------------------------
>> 0x6e1f80c 0x1011cf9 PushPixmap + 0x49b in ..\src\winvbt\WinContext.m3
>> 0x6e1f8d4 0x101fd0c PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3
>> 0x6e1fd30 0x101dc35 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3
>> 0x6e1fd98 0x10184ee PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3
>> 0x6e1fde0 0x1016ded WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3
>> 0x6e1fe0c 0x7d9472d8
>> 0x6e1fe84 0x7d947568
>> 0x6e1fefc 0x7d94778d
>> 0x6e1ff0c 0x7d94ab86
>> 0x6e1ff54 0x101bbc9 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3
>> ......... ......... ... more frames ...
>> (a3c.aec): Break instruction exception - code 80000003 (first chance)
>> eax=00000001 ebx=000000ab ecx=0000ff27 edx=0000001c esi=06e1f5b0 edi=006358eb
>> eip=7d61002d esp=06e1f598 ebp=06e1f5b0 iopl=0 nv up ei pl nz na po nc
>> cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
>> ntdll32!DbgBreakPoint:
>> 7d61002d cc int 3
>>
>>
>> The "funny" thing is that when this occurs, lots of scrollbar arrows
>> have been drawn
>> at the wrong place -- filling up Juno's canvas.
>
> Did Juno ever work on Windows' Trestle? I seem to remember that
> the Windows implementation was not sufficient for this rather
> sophisticated application, too many things were missing.
>
> Olaf
>
>>
>> This happens with current ScrollerVBClass.m3, or copying the Posix
>> one over Win32,
>> or your current one.
>>
>> I changed PushPixMap to print GetLastError, but it is 0. :(
>>
>> I'll dig a bit.
>>
>> Not great.
>> - Jay
>>
>
>
>
> --
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>



From jay.krell at cornell.edu  Thu Aug 14 17:08:26 2008
From: jay.krell at cornell.edu (Jay)
Date: Thu, 14 Aug 2008 15:08:26 +0000
Subject: [M3devel] windows move/scroller
In-Reply-To: <20080814152040.tu00bh7jqckg0w8w@mail.elegosoft.com>
References: <COL101-W123B5E9D268CE608107D40E6720@phx.gbl>
	<20080814152040.tu00bh7jqckg0w8w@mail.elegosoft.com>  
Message-ID: <COL101-W18E9D5B3112D5CFE53692BE6720@phx.gbl>


Could be that I had:


        brush := WinGDI.CreatePatternBrush (pst.pmtable[pm].hbmp);
        IF brush = NIL THEN
          win32error := WinBase.GetLastError ();
          IO.Put("CreatePatternBrush failed with " (* & Fmt.Address(brush) *) & " " & Fmt.Int(win32error) & "\n");
>>>          WinBase.DebugBreak ();
        END;
        


will remove that and see.
Fisheye sees this too ("RTSignal", we'll see if it was the breakpoint...)

 - Jay

> From: jay.krell at cornell.edu
> To: wagner at elegosoft.com; m3devel at elegosoft.com
> Subject: RE: [M3devel] windows move/scroller
> Date: Thu, 14 Aug 2008 15:01:51 +0000
>
>
> Juno was not in 3.6 and 4.1.
>
> - Jay
>
>
> ________________________________
>
> From: jay.krell at cornell.edu
> To: wagner at elegosoft.com; m3devel at elegosoft.com
> Subject: RE: [M3devel] windows move/scroller
> Date: Thu, 14 Aug 2008 14:38:33 +0000
>
>
>
>
> I admit I can't remember between NT386GNU and NT386.
> At least one of them Juno works on, at least better than I'm seeing on NT386 today.
> Juno gets pretty far on NT386. The splash screen comes up, the loading progress,
> most of the initial gui comes up, except the "canvas" is full of scrollbar arrows.
>
> I'll have to try with 3.6/4.1..
>
> A few seconds with mentor and I got:
>
> D:\dev2\cm3.2\m3-ui\ui\src\winvbt>\cm3\bin\mentor.exe
> CreatePatternBrush failed with 0
>
> ***
> *** runtime error:
> *** A runtime error occurred.
> *** pc = 0x7d61002d
> ***
> Stack trace:
> FP PC Procedure
> --------- --------- -------------------------------
> 0x72af77c 0x9266ae SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.m3
> 0x72af80c 0x7d61002d
> 0x72af8d4 0x147fe8c PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3
> 0x72afd30 0x147ddb5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3
> 0x72afd98 0x147867e PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3
> 0x72afde0 0x1476f7d WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3
> 0x72afe0c 0x7d9472d8
> 0x72afe84 0x7d947568
> 0x72afefc 0x7d94778d
> 0x72aff0c 0x7d94ab86
> ......... ......... ... more frames ...
>
> Maybe a divide by zero since I don't know how to setup mentor usefully..
> Looks different than Juno.
>
> Calculator works.
>
> - Jay
>
>> Date: Thu, 14 Aug 2008 15:20:40 +0200
>> From: wagner at elegosoft.com
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] windows move/scroller
>>
>> Quoting Jay :
>>
>>>
>>> Randy, your scrollervbclass.m3 looks ok or better.
>>>
>>> I went to try other gui apps, see if I could see the failure-to-move bug.
>>> It seems that most gui apps now crash.
>>> formsvbtedit is ok.
>>>
>>>
>>> ***
>>> *** runtime error:
>>> *** failed.
>>> *** file "..\src\winvbt\WinContext.m3", line 171
>>> ***
>>>
>>> Stack trace:
>>> FP PC Procedure
>>> --------- --------- -------------------------------
>>> 0x6e1f80c 0x1011cf9 PushPixmap + 0x49b in ..\src\winvbt\WinContext.m3
>>> 0x6e1f8d4 0x101fd0c PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3
>>> 0x6e1fd30 0x101dc35 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3
>>> 0x6e1fd98 0x10184ee PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3
>>> 0x6e1fde0 0x1016ded WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3
>>> 0x6e1fe0c 0x7d9472d8
>>> 0x6e1fe84 0x7d947568
>>> 0x6e1fefc 0x7d94778d
>>> 0x6e1ff0c 0x7d94ab86
>>> 0x6e1ff54 0x101bbc9 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3
>>> ......... ......... ... more frames ...
>>> (a3c.aec): Break instruction exception - code 80000003 (first chance)
>>> eax=00000001 ebx=000000ab ecx=0000ff27 edx=0000001c esi=06e1f5b0 edi=006358eb
>>> eip=7d61002d esp=06e1f598 ebp=06e1f5b0 iopl=0 nv up ei pl nz na po nc
>>> cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
>>> ntdll32!DbgBreakPoint:
>>> 7d61002d cc int 3
>>>
>>>
>>> The "funny" thing is that when this occurs, lots of scrollbar arrows
>>> have been drawn
>>> at the wrong place -- filling up Juno's canvas.
>>
>> Did Juno ever work on Windows' Trestle? I seem to remember that
>> the Windows implementation was not sufficient for this rather
>> sophisticated application, too many things were missing.
>>
>> Olaf
>>
>>>
>>> This happens with current ScrollerVBClass.m3, or copying the Posix
>>> one over Win32,
>>> or your current one.
>>>
>>> I changed PushPixMap to print GetLastError, but it is 0. :(
>>>
>>> I'll dig a bit.
>>>
>>> Not great.
>>> - Jay
>>>
>>
>>
>>
>> --
>> Olaf Wagner -- elego Software Solutions GmbH
>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>>
>


From wagner at elegosoft.com  Thu Aug 14 19:45:09 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Thu, 14 Aug 2008 19:45:09 +0200
Subject: [M3devel] another trestle bug..
In-Reply-To: <20080814151638.enfxv3axvok0g8wc@mail.elegosoft.com>
References: <COL101-W3271758E974746EF2E7BEBE6720@phx.gbl>
	<20080814151638.enfxv3axvok0g8wc@mail.elegosoft.com>
Message-ID: <20080814194509.6pl53v9csg04occ8@mail.elegosoft.com>

Quoting Olaf Wagner <wagner at elegosoft.com>:

> Quoting Jay <jay.krell at cornell.edu>:
>
>>
>> Sigh..in FormsVBTEdit, control-a to select all, control-c to copy,   
>>  control-c to copy again:
>>
>>
>>
>> ***
>> *** runtime error:
>> ***    Thread client error: Attempt to lock mutex already locked by self
>> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 155
>> ***
>
> This may well be a side-effect of my changes, though I didn't notice
> it. You may want to check the old code of the MacModel :-/
> If it is, we have to review the mutex use.

It's not related to the TextPort changes, but to WinTrestle.
I just tried on FreeBSD, and it works without a problem there.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From rodney.bates at wichita.edu  Fri Aug 15 03:20:07 2008
From: rodney.bates at wichita.edu (Rodney M. Bates)
Date: Thu, 14 Aug 2008 20:20:07 -0500
Subject: [M3devel] Recursive locks
In-Reply-To: <48A49161.1E75.00D7.1@scires.com>
References: <20080814142659.91A4A10D4F35@birch.elegosoft.com>
	<48A4134F.1E75.00D7.1@scires.com>
	<COL101-W30EE57E79AD843F646E8B4E6720@phx.gbl>
	<COL101-W22A7E87C9A16373E9679D9E6720@phx.gbl>
	<48A49161.1E75.00D7.1@scires.com>
Message-ID: <48A4D9C7.8030209@wichita.edu>

Randy Coleburn wrote:
> Jay:
>  
> There is the abstraction of multiple concurrent "readers" but only one 
> "writer".  I actually have such a module that I use sometimes in my 
> programs.  The idea is one of acquiring/releasing read locks and write 
> locks.  The difficulty here is in preventing starvation and usually 
> requires adherence to some rules (again rigor).  By starvation I mean 
> that writers must wait for all readers to finish before they get access, 
> so if there is always at least one reader, the writer will "starve" and 
> never gain access.
>  
> As for recursive locks, again that is usually indicative of a design 
> flaw.  I did once implement a system that permitted the same thread to 
> acquire a lock multiple times, provided that it eventually released the 
> lock the same number of times that it acquired it.  In other words, 
> after the first lock, subsequent locks by the same thread just increment 
> a counter.  Then, unlocks decrement the counter until it is zero with 
> the final unlock actually releasing the mutex.
>  
> In the code you modified, you could implement such a scheme to handle 
> the recursive locks, provided that at some point the thread releases for 
> each lock.  The Thread interface has the ability to note the current 
> thread (i.e., Thread.Self()).  So you could make a stack of locks by 
> same thread.  Other threads would have to block until the first thread's 
> lock stack was empty.
>  
> For example:
>  
> ACQUIRE:  If resource available, lock resource mutex and put current 
> thread on granted stack.  Otherwise, if current thread already on 
> granted stack, push it on stack again and let it proceed.  Otherwise 
> (this is a new thread wanting access), so push this thread onto a 
> waiting stack and wait.
>  
> RELEASE:  Pop granted stack and check to ensure the popped stack entry 
> represents the current thread.  If not, must crash due to a programming 
> error.  If granted stack is now empty, check to see if the waiting stack 
> is empty.  If the waiting stack is empty, release the resource mutex.  
> Otherwise (there is at least one thread waiting), pop waiting stack and 
> push onto granted stack.  Repeat pop/push for each occurrence of current 
> thread at top of waiting stack.  Allow waiting thread to proceed.
>  
> I can check into providing my read-write locks modules if needed.
>  
> Regards,
> Randy
> 


I have forgotten just where, but there are places in Trestle where it is
documented that, when your <whatever>-procedure is called, it is possible
that a certain MUTEX will sometimes already be held by the executing thread,
sometimes not.  If you need to access the data protected by that MUTEX,
you are just out of luck.  No matter what you do, it will be sometimes
wrong, sometimes not.  I don't remember the details, but I gave up trying
to find a way to do what I wanted to do.  I think it was very difficult,
even allowing modifications to Trestle.  This kind of lock scheme would
probably have solved this problem.


>  >>> Jay <jay.krell at cornell.edu> 8/14/2008 6:08 PM >>>
> 
> Maybe we should have another lock type that allows recursive acquires?
> To be used sparingly, but used here?
> I know that is often frowned upon -- the need for it implies a design 
> flaw -- but
> maybe it is ok sometimes?
> I don't understand when/why recursive locks are ok or not.
> 
> - Jay
> 
> 
> ________________________________
> 
> From: jay.krell at cornell.edu
> To: rcoleburn at scires.com; jkrell at elego.de; m3commit at elegosoft.com
> Date: Thu, 14 Aug 2008 22:05:13 +0000
> Subject: Re: [M3commit] CVS Update: cm3
> 
> 
> 
> 
> How about this comment in the code:
> 
> (*-------------------------------------------------- raw seething 
> windows ---*)
> (* NOTE: The helper procedures called by WindowProc lock VBT.mu when calling
>    various Trestle procedures.  They do not hold locks while calling Win32
>    because it knows nothing about Modula-3 locks and it can, on a whim, call
>    WindowProc to do something.  The only reason this scheme might work is
>    because we have a single Modula-3 thread that's pulling on the Win32
>    message queue and calling WindowProc.
> 
>    Similarly, we don't bother locking around updates to Child records.
>    They are updated by the single Modula-3/WindowProc thread.
> *)
> 
> ?
> I also need to check if any state has been modified, or cached in 
> locals, with
> the locks held that are being released.
> 
> -Jay
> 
> 
> 
> ________________________________
> 
> 
> Date: Thu, 14 Aug 2008 11:13:25 -0400
> From: rcoleburn at scires.com
> To: jkrell at elego.de; m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
> 
> 
> 
> Jay:
> 
> 
> 
> I haven't studied this code in depth, but on the surface I doubt your 
> change is "correct".
> 
> 
> 
> I think the more telling problem is that if you look at the body of 
> WinTrestle.Release, it is empty, save for a comment that it is not yet 
> implemented.  So, it would seem that if WinTrestle.Acquire is called 
> more than once, you will crash because the locks have not been released.
> 
> 
> 
> Further, I don't think it would make sense to release the locks before 
> calling out to Windows, and then reacquire them upon return.  The locks 
> are known to Modula-3 and not Windows.  Releasing them will allow other 
> competing threads to acquire them while you are in the Windows subsystem 
> and would seem to violate whatever protections were in place per holding 
> the locks.  Upon return from Windows, the thread will be back in 
> competition with others to reacquire the locks it gave up and upon 
> success, there is no guarantee that the other threads didn't disturb the 
> state the original thread depended upon.
> 
> 
> 
> I would suggest reverting these changes and looking to implement the 
> Release procedure.
> 
> 
> 
> Regards,
> 
> Randy
> 
> 
>  >>> Jay Krell  8/14/2008 4:26 PM>>>
> CVSROOT:/usr/cvs
> Changes by:jkrell at birch.08/08/14 16:26:59
> 
> Modified files:
> cm3/m3-ui/ui/src/winvbt/: WinTrestle.m3
> 
> Log message:
> release locks when calling out to Win32 to prevent recursive lock 
> acquisition. correct?
> 
> 
> 

-- 
-------------------------------------------------------------
Rodney M. Bates, retired assistant professor
Dept. of Computer Science, Wichita State University
Wichita, KS 67260-0083
316-978-3922
rodney.bates at wichita.edu


From jay.krell at cornell.edu  Fri Aug 15 08:27:17 2008
From: jay.krell at cornell.edu (Jay)
Date: Fri, 15 Aug 2008 06:27:17 +0000
Subject: [M3devel] Recursive locks
In-Reply-To: <48A4D9C7.8030209@wichita.edu>
References: <20080814142659.91A4A10D4F35@birch.elegosoft.com>
	<48A4134F.1E75.00D7.1@scires.com>
	<COL101-W30EE57E79AD843F646E8B4E6720@phx.gbl>
	<COL101-W22A7E87C9A16373E9679D9E6720@phx.gbl>
	<48A49161.1E75.00D7.1@scires.com>  <48A4D9C7.8030209@wichita.edu>
Message-ID: <COL101-W769E513D93D5D95A0F5D6BE66D0@phx.gbl>


Btw, notice that the comment I quoted is NOT true, prior to my change.
It claims we don't hold locks when we call out to Win32, but we do.
 
I vaguely know that releasing and reacquiring locks is or can be dangerous..
But, it depends, right?
It depends on if the locked data has been used yet, and if it is assumed to be
unchanged from the use before the release to uses after the reacquire, right?
 
I believe:
  Handling messages in Win32 possibly causes reentrance  -- called while already "in the middle" of doing something.
  Trestle, at least in parts, is perhaps not "designed" to handle that.
     That is, it does a lot of long term locking.
 
I tried to consider if the work here can be deferred, but it seems like it is exactly meant to occur in this order. I'll have dig more..sometimes...
 
 - Jay> Date: Thu, 14 Aug 2008 20:20:07 -0500> From: rodney.bates at wichita.edu> To: m3devel at elegosoft.com> Subject: [M3devel] Recursive locks> > Randy Coleburn wrote:> > Jay:> > > > There is the abstraction of multiple concurrent "readers" but only one > > "writer". I actually have such a module that I use sometimes in my > > programs. The idea is one of acquiring/releasing read locks and write > > locks. The difficulty here is in preventing starvation and usually > > requires adherence to some rules (again rigor). By starvation I mean > > that writers must wait for all readers to finish before they get access, > > so if there is always at least one reader, the writer will "starve" and > > never gain access.> > > > As for recursive locks, again that is usually indicative of a design > > flaw. I did once implement a system that permitted the same thread to > > acquire a lock multiple times, provided that it eventually released the > > lock the same number of times that it acquired it. In other words, > > after the first lock, subsequent locks by the same thread just increment > > a counter. Then, unlocks decrement the counter until it is zero with > > the final unlock actually releasing the mutex.> > > > In the code you modified, you could implement such a scheme to handle > > the recursive locks, provided that at some point the thread releases for > > each lock. The Thread interface has the ability to note the current > > thread (i.e., Thread.Self()). So you could make a stack of locks by > > same thread. Other threads would have to block until the first thread's > > lock stack was empty.> > > > For example:> > > > ACQUIRE: If resource available, lock resource mutex and put current > > thread on granted stack. Otherwise, if current thread already on > > granted stack, push it on stack again and let it proceed. Otherwise > > (this is a new thread wanting access), so push this thread onto a > > waiting stack and wait.> > > > RELEASE: Pop granted stack and check to ensure the popped stack entry > > represents the current thread. If not, must crash due to a programming > > error. If granted stack is now empty, check to see if the waiting stack > > is empty. If the waiting stack is empty, release the resource mutex. > > Otherwise (there is at least one thread waiting), pop waiting stack and > > push onto granted stack. Repeat pop/push for each occurrence of current > > thread at top of waiting stack. Allow waiting thread to proceed.> > > > I can check into providing my read-write locks modules if needed.> > > > Regards,> > Randy> > > > > I have forgotten just where, but there are places in Trestle where it is> documented that, when your <whatever>-procedure is called, it is possible> that a certain MUTEX will sometimes already be held by the executing thread,> sometimes not. If you need to access the data protected by that MUTEX,> you are just out of luck. No matter what you do, it will be sometimes> wrong, sometimes not. I don't remember the details, but I gave up trying> to find a way to do what I wanted to do. I think it was very difficult,> even allowing modifications to Trestle. This kind of lock scheme would> probably have solved this problem.> > > > >>> Jay <jay.krell at cornell.edu> 8/14/2008 6:08 PM >>>> > > > Maybe we should have another lock type that allows recursive acquires?> > To be used sparingly, but used here?> > I know that is often frowned upon -- the need for it implies a design > > flaw -- but> > maybe it is ok sometimes?> > I don't understand when/why recursive locks are ok or not.> > > > - Jay> > > > > > ________________________________> > > > From: jay.krell at cornell.edu> > To: rcoleburn at scires.com; jkrell at elego.de; m3commit at elegosoft.com> > Date: Thu, 14 Aug 2008 22:05:13 +0000> > Subject: Re: [M3commit] CVS Update: cm3> > > > > > > > > > How about this comment in the code:> > > > (*-------------------------------------------------- raw seething > > windows ---*)> > (* NOTE: The helper procedures called by WindowProc lock VBT.mu when calling> > various Trestle procedures. They do not hold locks while calling Win32> > because it knows nothing about Modula-3 locks and it can, on a whim, call> > WindowProc to do something. The only reason this scheme might work is> > because we have a single Modula-3 thread that's pulling on the Win32> > message queue and calling WindowProc.> > > > Similarly, we don't bother locking around updates to Child records.> > They are updated by the single Modula-3/WindowProc thread.> > *)> > > > ?> > I also need to check if any state has been modified, or cached in > > locals, with> > the locks held that are being released.> > > > -Jay> > > > > > > > ________________________________> > > > > > Date: Thu, 14 Aug 2008 11:13:25 -0400> > From: rcoleburn at scires.com> > To: jkrell at elego.de; m3commit at elegosoft.com> > Subject: Re: [M3commit] CVS Update: cm3> > > > > > > > Jay:> > > > > > > > I haven't studied this code in depth, but on the surface I doubt your > > change is "correct".> > > > > > > > I think the more telling problem is that if you look at the body of > > WinTrestle.Release, it is empty, save for a comment that it is not yet > > implemented. So, it would seem that if WinTrestle.Acquire is called > > more than once, you will crash because the locks have not been released.> > > > > > > > Further, I don't think it would make sense to release the locks before > > calling out to Windows, and then reacquire them upon return. The locks > > are known to Modula-3 and not Windows. Releasing them will allow other > > competing threads to acquire them while you are in the Windows subsystem > > and would seem to violate whatever protections were in place per holding > > the locks. Upon return from Windows, the thread will be back in > > competition with others to reacquire the locks it gave up and upon > > success, there is no guarantee that the other threads didn't disturb the > > state the original thread depended upon.> > > > > > > > I would suggest reverting these changes and looking to implement the > > Release procedure.> > > > > > > > Regards,> > > > Randy> > > > > > >>> Jay Krell 8/14/2008 4:26 PM>>>> > CVSROOT:/usr/cvs> > Changes by:jkrell at birch.08/08/14 16:26:59> > > > Modified files:> > cm3/m3-ui/ui/src/winvbt/: WinTrestle.m3> > > > Log message:> > release locks when calling out to Win32 to prevent recursive lock > > acquisition. correct?> > > > > > > > -- > -------------------------------------------------------------> Rodney M. Bates, retired assistant professor> Dept. of Computer Science, Wichita State University> Wichita, KS 67260-0083> 316-978-3922> rodney.bates at wichita.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080815/2369c19c/attachment-0001.html>

From rcoleburn at scires.com  Tue Aug 19 22:55:00 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Tue, 19 Aug 2008 16:55:00 -0400
Subject: [M3devel] pixmaps et al on Win32 hi-res monitors
Message-ID: <48AAFADE.1E75.00D7.1@scires.com>

Jay, Sorry for the delay in getting back to you.
 
I ran tests as you suggested, namely, in WinScreenType.InnerNew I changed the x & y resolution to be 96.0 (I did not change the pixels,  just the res field).  I tried running this version with Image.Raw.x/yres set to 75.0 and also set to 96.0.  In both cases, what I got on the screen was horrid.  Everything was extremely large and only a fraction of the window was visible on screen (e.g., shadow size on buttons appeared to be increased by a factor of 7 or more).
 
So, here is where I stand:
 
1.  It seems that for certain high-dpi monitors (Dell M4300 laptop is only one I've tested), if you use unscaled pixmaps in FormsVBT/Trestle, the ZGrowVBT stops working for ZChassisVBT.  You can still grab the title and try to drag.  The system will put an outline around the window, but it won't let you drag it anywhere.
 
2.  I have put an environment variable in my programs that lets you choose between scaled and unscaled pixmaps.  For either case, the program seems to work fine on "normal dpi" monitors, but when run on the Dell M4300 hi-res system, you get the following behavior:  
 
Unscaled=subwindows can't be dragged around (moved), but the GUI looks good; 
 
Scaled=subwindow dragging works as expected, but all pixmaps are double-size resulting in bad appearance (pixmaps are out of proportion with text and cause some subwindows to be too big to fit on screen).  
 
So, the end user gets to decide via environment variable whether he wants a pretty GUI with frozen subwindows, or an ugly GUI with movable subwindows.  Alas, the choices are poor, at best.
 
3.  At this point I don't know of anything else to try as a potential solution to this problem.
 
4.  I am running final tests today & tomorrow at the customer location.  We will meet tomorrow (Wednesday) afternoon to decide if customer will accept the program.
 
If anyone has any other ideas for a solution, please let me know ASAP.
 
I plan to commit my changes to the repository as soon as the final decision on acceptance is rendered.  These changes will not alter the way Trestle/FormsVBT has been working on Windows, except to fix the appearance of scaled scroll bars and to add the capability to force use of unscaled pixmaps.  The latter is not done thru env var, but via a new procedure in Image.i3.  (One could use an env var in one's program, like I did, to provide a control input to the new procedure.)  Unless one calls the new procedure, the default is to use scaled pixmaps so as to maintain compatibility with the way its been done in the past, thus there is no change in operation unless explicitly called for by the programmer.
 
Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080819/8d2b858f/attachment-0001.html>

From jay.krell at cornell.edu  Tue Aug 19 23:23:52 2008
From: jay.krell at cornell.edu (Jay)
Date: Tue, 19 Aug 2008 21:23:52 +0000
Subject: [M3devel] pixmaps et al on Win32 hi-res monitors
In-Reply-To: <48AAFADE.1E75.00D7.1@scires.com>
References: <48AAFADE.1E75.00D7.1@scires.com>
Message-ID: <COL101-W685AD60FBE2EC60E5831C6E6690@phx.gbl>


Randy this is all unfortunate. I really wish I had this configuration locally to try out. :(
If you or your customer can send me one....I make no promises. :)
(It is not a cheap machine. It is a "high end" laptop ("high end" means "arbitrarily inflated price"), starts at $1400, and is not well configured at that price. You can get a much better Dell Vostro or Inspiron for half the price.)
 
"I kinda thunk" 96 and 75 or 96 and 96, would lead to "correcly unscaled pixmaps".
I need to read the code more..these must have had other affects.
 
Be sure your customer knows it works fine on most machines/configurations.
Try to get your customer to believe we might yet fix it. 
  However, granted, confidence in the overall system will still suffer.
And if you can get them to send me one..just to borrow...probably not a good move in a "professional environment", use your judgement.
 
Sorry,
 - Jay



Date: Tue, 19 Aug 2008 16:55:00 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: pixmaps et al on Win32 hi-res monitors

Jay, Sorry for the delay in getting back to you.
 
I ran tests as you suggested, namely, in WinScreenType.InnerNew I changed the x & y resolution to be 96.0 (I did not change the pixels,  just the res field).  I tried running this version with Image.Raw.x/yres set to 75.0 and also set to 96.0.  In both cases, what I got on the screen was horrid.  Everything was extremely large and only a fraction of the window was visible on screen (e.g., shadow size on buttons appeared to be increased by a factor of 7 or more).
 
So, here is where I stand:
 
1.  It seems that for certain high-dpi monitors (Dell M4300 laptop is only one I've tested), if you use unscaled pixmaps in FormsVBT/Trestle, the ZGrowVBT stops working for ZChassisVBT.  You can still grab the title and try to drag.  The system will put an outline around the window, but it won't let you drag it anywhere.
 
2.  I have put an environment variable in my programs that lets you choose between scaled and unscaled pixmaps.  For either case, the program seems to work fine on "normal dpi" monitors, but when run on the Dell M4300 hi-res system, you get the following behavior:  
 
Unscaled=subwindows can't be dragged around (moved), but the GUI looks good; 
 
Scaled=subwindow dragging works as expected, but all pixmaps are double-size resulting in bad appearance (pixmaps are out of proportion with text and cause some subwindows to be too big to fit on screen).  
 
So, the end user gets to decide via environment variable whether he wants a pretty GUI with frozen subwindows, or an ugly GUI with movable subwindows.  Alas, the choices are poor, at best.
 
3.  At this point I don't know of anything else to try as a potential solution to this problem.
 
4.  I am running final tests today & tomorrow at the customer location.  We will meet tomorrow (Wednesday) afternoon to decide if customer will accept the program.
 
If anyone has any other ideas for a solution, please let me know ASAP.
 
I plan to commit my changes to the repository as soon as the final decision on acceptance is rendered.  These changes will not alter the way Trestle/FormsVBT has been working on Windows, except to fix the appearance of scaled scroll bars and to add the capability to force use of unscaled pixmaps.  The latter is not done thru env var, but via a new procedure in Image.i3.  (One could use an env var in one's program, like I did, to provide a control input to the new procedure.)  Unless one calls the new procedure, the default is to use scaled pixmaps so as to maintain compatibility with the way its been done in the past, thus there is no change in operation unless explicitly called for by the programmer.
 
Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080819/9c2d9618/attachment-0001.html>

From rcoleburn at scires.com  Wed Aug 20 01:46:35 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Tue, 19 Aug 2008 19:46:35 -0400
Subject: [M3devel] pixmaps et al on Win32 hi-res monitors
In-Reply-To: <COL101-W685AD60FBE2EC60E5831C6E6690@phx.gbl>
References: <48AAFADE.1E75.00D7.1@scires.com>
	<COL101-W685AD60FBE2EC60E5831C6E6690@phx.gbl>
Message-ID: <48AB2313.1E75.00D7.1@scires.com>

Jay:
 
Thanks.  I probably can't arrange to send you one of these computers, but I might be able to set up a way for you to remotely access it.
 
Regards,
Randy

>>> Jay <jay.krell at cornell.edu> 8/19/2008 5:23 PM >>>
Randy this is all unfortunate. I really wish I had this configuration locally to try out. :(
If you or your customer can send me one....I make no promises. :)
(It is not a cheap machine. It is a "high end" laptop ("high end" means "arbitrarily inflated price"), starts at $1400, and is not well configured at that price. You can get a much better Dell Vostro or Inspiron for half the price.)
 
"I kinda thunk" 96 and 75 or 96 and 96, would lead to "correcly unscaled pixmaps".
I need to read the code more..these must have had other affects.
 
Be sure your customer knows it works fine on most machines/configurations.
Try to get your customer to believe we might yet fix it. 
  However, granted, confidence in the overall system will still suffer.
And if you can get them to send me one..just to borrow...probably not a good move in a "professional environment", use your judgement.
 
Sorry,
 - Jay



Date: Tue, 19 Aug 2008 16:55:00 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com; jayk123 at hotmail.com 
Subject: pixmaps et al on Win32 hi-res monitors


Jay, Sorry for the delay in getting back to you.
 
I ran tests as you suggested, namely, in WinScreenType.InnerNew I changed the x & y resolution to be 96.0 (I did not change the pixels,  just the res field).  I tried running this version with Image.Raw.x/yres set to 75.0 and also set to 96.0.  In both cases, what I got on the screen was horrid.  Everything was extremely large and only a fraction of the window was visible on screen (e.g., shadow size on buttons appeared to be increased by a factor of 7 or more).
 
So, here is where I stand:
 
1.  It seems that for certain high-dpi monitors (Dell M4300 laptop is only one I've tested), if you use unscaled pixmaps in FormsVBT/Trestle, the ZGrowVBT stops working for ZChassisVBT.  You can still grab the title and try to drag.  The system will put an outline around the window, but it won't let you drag it anywhere.
 
2.  I have put an environment variable in my programs that lets you choose between scaled and unscaled pixmaps.  For either case, the program seems to work fine on "normal dpi" monitors, but when run on the Dell M4300 hi-res system, you get the following behavior:  
 
Unscaled=subwindows can't be dragged around (moved), but the GUI looks good; 
 
Scaled=subwindow dragging works as expected, but all pixmaps are double-size resulting in bad appearance (pixmaps are out of proportion with text and cause some subwindows to be too big to fit on screen).  
 
So, the end user gets to decide via environment variable whether he wants a pretty GUI with frozen subwindows, or an ugly GUI with movable subwindows.  Alas, the choices are poor, at best.
 
3.  At this point I don't know of anything else to try as a potential solution to this problem.
 
4.  I am running final tests today & tomorrow at the customer location.  We will meet tomorrow (Wednesday) afternoon to decide if customer will accept the program.
 
If anyone has any other ideas for a solution, please let me know ASAP.
 
I plan to commit my changes to the repository as soon as the final decision on acceptance is rendered.  These changes will not alter the way Trestle/FormsVBT has been working on Windows, except to fix the appearance of scaled scroll bars and to add the capability to force use of unscaled pixmaps.  The latter is not done thru env var, but via a new procedure in Image.i3.  (One could use an env var in one's program, like I did, to provide a control input to the new procedure.)  Unless one calls the new procedure, the default is to use scaled pixmaps so as to maintain compatibility with the way its been done in the past, thus there is no change in operation unless explicitly called for by the programmer.
 
Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080819/02e9be3e/attachment-0001.html>

From jay.krell at cornell.edu  Thu Aug 21 13:00:43 2008
From: jay.krell at cornell.edu (Jay)
Date: Thu, 21 Aug 2008 11:00:43 +0000
Subject: [M3devel] pixmaps et al on Win32 hi-res monitors
In-Reply-To: <48AB2313.1E75.00D7.1@scires.com>
References: <48AAFADE.1E75.00D7.1@scires.com>
	<COL101-W685AD60FBE2EC60E5831C6E6690@phx.gbl> 
	<48AB2313.1E75.00D7.1@scires.com>
Message-ID: <COL101-W44C26F20E9DF8DF3815DAEE66B0@phx.gbl>


Randy, in case anyone splurges on one of these..

Can you go to Dell.com.
Support.
Type in the asset tag. I think they are on small
barcode stickers on the bottom.

Tell us which screen type this as?
  15.4 IN WIDE WUXGA Anti-Glare LCD Panel
  15.4 inch Wide Screen WSXGA+ TrueLife LCD Panel
  15.4 inch Wide Screen WXGA Anti-Glare LCD Panel
(These are the current options when buying this;
could be there were others in the past. Totally unknown.
Should be easy to map the alphabet soup of *GA to resolutions,
but I don't know.)

Could be also you can simulate this with a simple setting.
I'll try when I get home.
You have a small app that demonstrates the problem?

Hm..

http://en.wikipedia.org/wiki/WSXGA
http://www.pcmag.com/encyclopedia_term/0,2542,t=WSXGA&i=54916,00.asp

 - Jay

________________________________
> Date: Tue, 19 Aug 2008 19:46:35 -0400
> From: rcoleburn at scires.com
> To: jay.krell at cornell.edu; m3devel at elegosoft.com
> Subject: Re: [M3devel] pixmaps et al on Win32 hi-res monitors
> 
> Jay:
> 
> Thanks.  I probably can't arrange to send you one of these computers, but I might be able to set up a way for you to remotely access it.
> 
> Regards,
> Randy
> 
>>>> Jay  8/19/2008 5:23 PM>>>
> Randy this is all unfortunate. I really wish I had this configuration locally to try out. :(
> If you or your customer can send me one....I make no promises. :)
> (It is not a cheap machine. It is a "high end" laptop ("high end" means "arbitrarily inflated price"), starts at $1400, and is not well configured at that price. You can get a much better Dell Vostro or Inspiron for half the price.)
> 
> "I kinda thunk" 96 and 75 or 96 and 96, would lead to "correcly unscaled pixmaps".
> I need to read the code more..these must have had other affects.
> 
> Be sure your customer knows it works fine on most machines/configurations.
> Try to get your customer to believe we might yet fix it.
>   However, granted, confidence in the overall system will still suffer.
> And if you can get them to send me one..just to borrow...probably not a good move in a "professional environment", use your judgement.
> 
> Sorry,
>  - Jay
> 
> 
> ________________________________
> 
> Date: Tue, 19 Aug 2008 16:55:00 -0400
> From: rcoleburn at scires.com
> To: m3devel at elegosoft.com; jayk123 at hotmail.com
> Subject: pixmaps et al on Win32 hi-res monitors
> 
> 
> Jay, Sorry for the delay in getting back to you.
> 
> I ran tests as you suggested, namely, in WinScreenType.InnerNew I changed the x & y resolution to be 96.0 (I did not change the pixels,  just the res field).  I tried running this version with Image.Raw.x/yres set to 75.0 and also set to 96.0.  In both cases, what I got on the screen was horrid.  Everything was extremely large and only a fraction of the window was visible on screen (e.g., shadow size on buttons appeared to be increased by a factor of 7 or more).
> 
> So, here is where I stand:
> 
> 1.  It seems that for certain high-dpi monitors (Dell M4300 laptop is only one I've tested), if you use unscaled pixmaps in FormsVBT/Trestle, the ZGrowVBT stops working for ZChassisVBT.  You can still grab the title and try to drag.  The system will put an outline around the window, but it won't let you drag it anywhere.
> 
> 2.  I have put an environment variable in my programs that lets you choose between scaled and unscaled pixmaps.  For either case, the program seems to work fine on "normal dpi" monitors, but when run on the Dell M4300 hi-res system, you get the following behavior:
> 
> Unscaled=subwindows can't be dragged around (moved), but the GUI looks good;
> 
> Scaled=subwindow dragging works as expected, but all pixmaps are double-size resulting in bad appearance (pixmaps are out of proportion with text and cause some subwindows to be too big to fit on screen).
> 
> So, the end user gets to decide via environment variable whether he wants a pretty GUI with frozen subwindows, or an ugly GUI with movable subwindows.  Alas, the choices are poor, at best.
> 
> 3.  At this point I don't know of anything else to try as a potential solution to this problem.
> 
> 4.  I am running final tests today & tomorrow at the customer location.  We will meet tomorrow (Wednesday) afternoon to decide if customer will accept the program.
> 
> If anyone has any other ideas for a solution, please let me know ASAP.
> 
> I plan to commit my changes to the repository as soon as the final decision on acceptance is rendered.  These changes will not alter the way Trestle/FormsVBT has been working on Windows, except to fix the appearance of scaled scroll bars and to add the capability to force use of unscaled pixmaps.  The latter is not done thru env var, but via a new procedure in Image.i3.  (One could use an env var in one's program, like I did, to provide a control input to the new procedure.)  Unless one calls the new procedure, the default is to use scaled pixmaps so as to maintain compatibility with the way its been done in the past, thus there is no change in operation unless explicitly called for by the programmer.
> 
> Regards,
> Randy


From rcoleburn at scires.com  Thu Aug 21 14:20:01 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Thu, 21 Aug 2008 08:20:01 -0400
Subject: [M3devel] pixmaps et al on Win32 hi-res monitors
In-Reply-To: <COL101-W44C26F20E9DF8DF3815DAEE66B0@phx.gbl>
References: <48AAFADE.1E75.00D7.1@scires.com>
	<COL101-W685AD60FBE2EC60E5831C6E6690@phx.gbl>
	<48AB2313.1E75.00D7.1@scires.com>
	<COL101-W44C26F20E9DF8DF3815DAEE66B0@phx.gbl>
Message-ID: <48AD2527.1E75.00D7.1@scires.com>

Jay:
 
I wouldn't "splurge" on this unless someone just wants one of them.
 
Based on the URLs you sent, the Dell M4300 display is a WUXGA, 16:10, 1920x1200.  See http://en.wikipedia.org/wiki/WUXGA 
 
I'm heading to the airport now, so I'll have to get the asset tag for you when I get back to Atlanta.
 
BTW, the customer is impressed with the speed with which I was able to provide the new software.  I owe this credit to Modula-3.  The customer is also impressed with the software, esp. the use of multi-threading and the ability to target multiple platforms simply by recompiling.  Again, credit Modula-3.  Using my env var hack, I was able to show the customer correct appearance of the GUI, at the expense of sub-window movement, so the customer believes I should be able to eventually solve the problem.  Therefore, the customer has agreed to take delivery of the software with the proviso that I continue to work to solve the problem.  So, it looks like I have some more time to work toward a solution.
 
FYI:  My software is used to control and monitor a satellite multi-receiver system.  This system receives and processes tactical data for display and action by the operator and other automated systems.  I can't be more specific because the application is used by the military.  Indeed, the reason for the hard delivery deadline is to meet a deadline for flight testing aboard a new military aircraft.
 
When I get back to Atlanta, I'll try to put together some screen captures of the GUI (minus any tactical info) and provide them in a PDF so you can see some of the windows.  I may be able to put together a small program that demonstrates the problem I'm having.  I won't be able to release the source code, but I should be able to provide a standalone EXE file.
 
Regards,
Randy

>>> Jay <jay.krell at cornell.edu> 8/21/2008 7:00 AM >>>

Randy, in case anyone splurges on one of these..

Can you go to Dell.com.
Support.
Type in the asset tag. I think they are on small
barcode stickers on the bottom.

Tell us which screen type this as?
  15.4 IN WIDE WUXGA Anti-Glare LCD Panel
  15.4 inch Wide Screen WSXGA+ TrueLife LCD Panel
  15.4 inch Wide Screen WXGA Anti-Glare LCD Panel
(These are the current options when buying this;
could be there were others in the past. Totally unknown.
Should be easy to map the alphabet soup of *GA to resolutions,
but I don't know.)

Could be also you can simulate this with a simple setting.
I'll try when I get home.
You have a small app that demonstrates the problem?

Hm..

http://en.wikipedia.org/wiki/WSXGA 
http://www.pcmag.com/encyclopedia_term/0,2542,t=WSXGA&i=54916,00.asp 

- Jay

________________________________
> Date: Tue, 19 Aug 2008 19:46:35 -0400
> From: rcoleburn at scires.com 
> To: jay.krell at cornell.edu; m3devel at elegosoft.com 
> Subject: Re: [M3devel] pixmaps et al on Win32 hi-res monitors
> 
> Jay:
> 
> Thanks.  I probably can't arrange to send you one of these computers, but I might be able to set up a way for you to remotely access it.
> 
> Regards,
> Randy
> 
>>>> Jay  8/19/2008 5:23 PM>>>
> Randy this is all unfortunate. I really wish I had this configuration locally to try out. :(
> If you or your customer can send me one....I make no promises. :)
> (It is not a cheap machine. It is a "high end" laptop ("high end" means "arbitrarily inflated price"), starts at $1400, and is not well configured at that price. You can get a much better Dell Vostro or Inspiron for half the price.)
> 
> "I kinda thunk" 96 and 75 or 96 and 96, would lead to "correcly unscaled pixmaps".
> I need to read the code more..these must have had other affects.
> 
> Be sure your customer knows it works fine on most machines/configurations.
> Try to get your customer to believe we might yet fix it.
>   However, granted, confidence in the overall system will still suffer.
> And if you can get them to send me one..just to borrow...probably not a good move in a "professional environment", use your judgement.
> 
> Sorry,
>  - Jay
> 
> 
> ________________________________
> 
> Date: Tue, 19 Aug 2008 16:55:00 -0400
> From: rcoleburn at scires.com 
> To: m3devel at elegosoft.com; jayk123 at hotmail.com 
> Subject: pixmaps et al on Win32 hi-res monitors
> 
> 
> Jay, Sorry for the delay in getting back to you.
> 
> I ran tests as you suggested, namely, in WinScreenType.InnerNew I changed the x & y resolution to be 96.0 (I did not change the pixels,  just the res field).  I tried running this version with Image.Raw.x/yres set to 75.0 and also set to 96.0.  In both cases, what I got on the screen was horrid.  Everything was extremely large and only a fraction of the window was visible on screen (e.g., shadow size on buttons appeared to be increased by a factor of 7 or more).
> 
> So, here is where I stand:
> 
> 1.  It seems that for certain high-dpi monitors (Dell M4300 laptop is only one I've tested), if you use unscaled pixmaps in FormsVBT/Trestle, the ZGrowVBT stops working for ZChassisVBT.  You can still grab the title and try to drag.  The system will put an outline around the window, but it won't let you drag it anywhere.
> 
> 2.  I have put an environment variable in my programs that lets you choose between scaled and unscaled pixmaps.  For either case, the program seems to work fine on "normal dpi" monitors, but when run on the Dell M4300 hi-res system, you get the following behavior:
> 
> Unscaled=subwindows can't be dragged around (moved), but the GUI looks good;
> 
> Scaled=subwindow dragging works as expected, but all pixmaps are double-size resulting in bad appearance (pixmaps are out of proportion with text and cause some subwindows to be too big to fit on screen).
> 
> So, the end user gets to decide via environment variable whether he wants a pretty GUI with frozen subwindows, or an ugly GUI with movable subwindows.  Alas, the choices are poor, at best.
> 
> 3.  At this point I don't know of anything else to try as a potential solution to this problem.
> 
> 4.  I am running final tests today & tomorrow at the customer location.  We will meet tomorrow (Wednesday) afternoon to decide if customer will accept the program.
> 
> If anyone has any other ideas for a solution, please let me know ASAP.
> 
> I plan to commit my changes to the repository as soon as the final decision on acceptance is rendered.  These changes will not alter the way Trestle/FormsVBT has been working on Windows, except to fix the appearance of scaled scroll bars and to add the capability to force use of unscaled pixmaps.  The latter is not done thru env var, but via a new procedure in Image.i3.  (One could use an env var in one's program, like I did, to provide a control input to the new procedure.)  Unless one calls the new procedure, the default is to use scaled pixmaps so as to maintain compatibility with the way its been done in the past, thus there is no change in operation unless explicitly called for by the programmer.
> 
> Regards,
> Randy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080821/7218998f/attachment-0001.html>

From dabenavidesd at yahoo.es  Fri Aug  1 00:43:07 2008
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Thu, 31 Jul 2008 22:43:07 +0000 (GMT)
Subject: [M3devel] need help with cm3 problem before I deliver software
	this week
In-Reply-To: <4891A737.1E75.00D7.1@scires.com>
Message-ID: <537778.13498.qm@web27107.mail.ukl.yahoo.com>

Hi all:
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.
Thanks

--- El jue, 31/7/08, Randy Coleburn <rcoleburn at scires.com> escribi?:
De: Randy Coleburn <rcoleburn at scires.com>
Asunto: Re: [M3devel] need help with cm3 problem before I deliver software this week
Para: "Rodney M. Bates" <rodney.bates at wichita.edu>
CC: m3devel at elegosoft.com
Fecha: jueves, 31 julio, 2008 10:51


 
Rodney:
?
I am using Windows XP Professional, Service Pack 2 (on some systems, Service Pack 3 is applied).
?
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?
?
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.
?
Regards,
Randy

>>> "Rodney M. Bates" <rodney.bates at wichita.edu> 7/31/2008 9:33 AM >>>
Which variant of the M3 Windows target are you using?? I don't have any
of them built right now.

Randy Coleburn wrote:
> Hi Olaf, Daniel, Rodney, et al:
>? 
> Thanks for your responses so far.? Sorry for the delay in replying, but 
> our email server has been offline for nearly 24-hours.? There were some 
> severe electrical storms that took down both redundant power systems for 
> our email system.? Hope I have not missed any of your replies.
>? 
> Right now, I am delivering the software on Windows XP using SP2 or 
> greater.? I have not tried to see if this problem also occurs on Unix.? 
> I don't have ready access to a unix system from my current location.
>? 
> So it is perhaps a Windows-only problem with Trestle/FormsVBT.? In any 
> event, it is a real problem for me.
>? 
> As for the pixmap stretching problem, I have tested various resolutions 
> on the customer's computer.? Unfortunately, the customer demands that 
> the display resolution stay at the 1920x1200.
> 1920x1200=pixmap stretch problem
> 1680x1050=pixmap stretch problem
> 1440x900=no problem
> 1024x768=no problem
>? 
> Regards,
> Randy
> 
>? >>> Olaf Wagner <wagner at elegosoft.com> 7/30/2008 2:24 AM >>>
> Quoting Randy Coleburn <rcoleburn at scires.com>:
> 
>? > Hi:
>? >
>? > 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.
>? >
>? > This problem is easily reproduced using the "formsedit" program.
>? >
>? > The problem is with the TypeIn and TypeScript FormsVBT elements used 
>? >? in my program.? Since formsedit uses these, you can easily 
>? > reproduce? the problem.
>? >
>? > 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.
> 
> Randy,
> 
> I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't able
> to reproduce the problem on FreeBSD 6.3.
> 
> Does the problem show up on all platforms you are working on?
> Which are these?
> 
> Are there any local modifications to the libraries which I may not
> have?
> 
> If it occurs only on Unix, it may be possible that a weird window
> manager interferes with the event delivery; otherwise I've got no
> good idea. If on Unix, you/we could perhaps test the behaviour
> on a different (remote) X display?
> 
> Please provide more data about the problem context and how to
> reproduce it.
> 
> Regards,
> 
> Olaf
> 
>? > 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).
>? >
>? > 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#.
>? >
>? > 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.
>? >
>? > Regards,
>? > Randy Coleburn
>? > Senior Systems Engineer
>? > Scientific Research Corporation
>? >
> 
> 
> 
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>???????????????? Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96? mobile: +49 177 2345 869? fax: +49 30 23 45 86 95
>???? http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 
> 

-- 
-------------------------------------------------------------
Rodney M. Bates, retired assistant professor
Dept. of Computer Science, Wichita State University
Wichita, KS 67260-0083
316-978-3922
rodney.bates at wichita.edu




      ______________________________________________ 
Enviado desde Correo Yahoo! La bandeja de entrada m?s inteligente.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080731/87ed8ad9/attachment-0002.html>

From jayk123 at hotmail.com  Fri Aug  1 00:52:51 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 31 Jul 2008 22:52:51 +0000
Subject: [M3devel] need help with cm3 problem before I
	deliver	software	this	week
In-Reply-To: <4891A737.1E75.00D7.1@scires.com>
References: <488F4292.1E75.00D7.1@scires.com>
	<20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com>
	<4890EB9C.1E75.00D7.1@scires.com> <4891BF18.8000905@wichita.edu> 
	<4891A737.1E75.00D7.1@scires.com>
Message-ID: <COL101-W53603D6A9F25219F7DF8C2E67C0@phx.gbl>


You reminded me -- there is something in the code about double reporting of characters and ignoring the first one.
It is, like the main/environment stuff, one of those suspicious changes that crept in  -- a change with a comment indicating the changer didn't know what is going on, and overridable with environment variable/command line switch. But I had less luck resolving this than with main/environment.
Does it repro with 4.1? Or 3.6?
I haven't tried yet but will shortly.
Been on gcc related tangents since I got a sparc/Solaris machine, sorry.
 
 - Jay



Date: Thu, 31 Jul 2008 11:51:28 -0400From: rcoleburn at scires.comTo: rodney.bates at wichita.eduCC: m3devel at elegosoft.comSubject: Re: [M3devel] need help with cm3 problem before I deliver software this week

Rodney:
 
I am using Windows XP Professional, Service Pack 2 (on some systems, Service Pack 3 is applied).
 
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?
 
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.
 
Regards,
Randy>>> "Rodney M. Bates" <rodney.bates at wichita.edu> 7/31/2008 9:33 AM >>>Which variant of the M3 Windows target are you using?  I don't have anyof them built right now.Randy Coleburn wrote:> Hi Olaf, Daniel, Rodney, et al:>  > Thanks for your responses so far.  Sorry for the delay in replying, but > our email server has been offline for nearly 24-hours.  There were some > severe electrical storms that took down both redundant power systems for > our email system.  Hope I have not missed any of your replies.>  > Right now, I am delivering the software on Windows XP using SP2 or > greater.  I have not tried to see if this problem also occurs on Unix.  > I don't have ready access to a unix system from my current location.>  > So it is perhaps a Windows-only problem with Trestle/FormsVBT.  In any > event, it is a real problem for me.>  > As for the pixmap stretching problem, I have tested various resolutions > on the customer's computer.  Unfortunately, the customer demands that > the display resolution stay at the 1920x1200.> 1920x1200=pixmap stretch problem> 1680x1050=pixmap stretch problem> 1440x900=no problem> 1024x768=no problem>  > Regards,> Randy> >  >>> Olaf Wagner <wagner at elegosoft.com> 7/30/2008 2:24 AM >>>> Quoting Randy Coleburn <rcoleburn at scires.com>:> >  > Hi:>  >>  > 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.>  >>  > This problem is easily reproduced using the "formsedit" program.>  >>  > The problem is with the TypeIn and TypeScript FormsVBT elements used >  >  in my program.  Since formsedit uses these, you can easily >  > reproduce  the problem.>  >>  > 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.> > Randy,> > I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't able> to reproduce the problem on FreeBSD 6.3.> > Does the problem show up on all platforms you are working on?> Which are these?> > Are there any local modifications to the libraries which I may not> have?> > If it occurs only on Unix, it may be possible that a weird window> manager interferes with the event delivery; otherwise I've got no> good idea. If on Unix, you/we could perhaps test the behaviour> on a different (remote) X display?> > Please provide more data about the problem context and how to> reproduce it.> > Regards,> > Olaf> >  > 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).>  >>  > 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#.>  >>  > 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.>  >>  > Regards,>  > Randy Coleburn>  > Senior Systems Engineer>  > Scientific Research Corporation>  >> > > > -- > Olaf Wagner -- elego Software Solutions GmbH>                 Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95>     http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> > -- -------------------------------------------------------------Rodney M. Bates, retired assistant professorDept. of Computer Science, Wichita State UniversityWichita, KS 67260-0083316-978-3922rodney.bates at wichita.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080731/3ccb6074/attachment-0002.html>

From dabenavidesd at yahoo.es  Fri Aug  1 01:16:05 2008
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Thu, 31 Jul 2008 23:16:05 +0000 (GMT)
Subject: [M3devel] need help with cm3 problem before I deliver software
	this week
In-Reply-To: <537778.13498.qm@web27107.mail.ukl.yahoo.com>
Message-ID: <464840.85424.qm@web27104.mail.ukl.yahoo.com>

Hi all:
They are @M3TraceWinMsgs and @M3SlowTrace
I get it in the file m3-ui/ui/src/winvbt/WinTrestle.m3
lines 1096, 1097
? trace_msgs := RTParams.IsPresent ("TraceWinMsgs");
? slow_trace := RTParams.IsPresent ("SlowTrace");
Thanks


--- El jue, 31/7/08, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:
De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] need help with cm3 problem before I deliver software this week
Para: "Rodney M. Bates" <rodney.bates at wichita.edu>, "Randy Coleburn" <rcoleburn at scires.com>
CC: m3devel at elegosoft.com
Fecha: jueves, 31 julio, 2008 5:43

Hi all:
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.
Thanks

--- El jue, 31/7/08, Randy Coleburn <rcoleburn at scires.com> escribi?:
De: Randy Coleburn <rcoleburn at scires.com>
Asunto: Re: [M3devel] need help with cm3 problem before I deliver software this
week
Para: "Rodney M. Bates" <rodney.bates at wichita.edu>
CC: m3devel at elegosoft.com
Fecha: jueves, 31 julio, 2008 10:51


 
Rodney:
?
I am using Windows XP Professional, Service Pack 2 (on some systems, Service
Pack 3 is applied).
?
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?
?
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.
?
Regards,
Randy

>>> "Rodney M. Bates" <rodney.bates at wichita.edu>
7/31/2008 9:33 AM >>>
Which variant of the M3 Windows target are you using?? I don't have any
of them built right now.

Randy Coleburn wrote:
> Hi Olaf, Daniel, Rodney, et al:
>? 
> Thanks for your responses so far.? Sorry for the delay in replying, but 
> our email server has been offline for nearly 24-hours.? There were some 
> severe electrical storms that took down both redundant power systems for 
> our email system.? Hope I have not missed any of your replies.
>? 
> Right now, I am delivering the software on Windows XP using SP2 or 
> greater.? I have not tried to see if this problem also occurs on Unix.? 
> I don't have ready access to a unix system from my current location.
>? 
> So it is perhaps a Windows-only problem with Trestle/FormsVBT.? In any 
> event, it is a real problem for me.
>? 
> As for the pixmap stretching problem, I have tested various resolutions 
> on the customer's computer.? Unfortunately, the customer demands that

> the display resolution stay at the 1920x1200.
> 1920x1200=pixmap stretch problem
> 1680x1050=pixmap stretch problem
> 1440x900=no problem
> 1024x768=no problem
>? 
> Regards,
> Randy
> 
>? >>> Olaf Wagner <wagner at elegosoft.com> 7/30/2008 2:24 AM
>>>
> Quoting Randy Coleburn <rcoleburn at scires.com>:
> 
>? > Hi:
>? >
>? > 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.
>? >
>? > This problem is easily reproduced using the "formsedit"
program.
>? >
>? > The problem is with the TypeIn and TypeScript FormsVBT elements
used 
>? >? in my program.? Since formsedit uses these, you can easily 
>? > reproduce? the problem.
>? >
>? > 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.
> 
> Randy,
> 
> I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't able
> to reproduce the problem on FreeBSD 6.3.
> 
> Does the problem show up on all platforms you are working on?
> Which are these?
> 
> Are there any local modifications to the libraries which I may not
> have?
> 
> If it occurs only on Unix, it may be possible that a weird window
> manager interferes with the event delivery; otherwise I've got no
> good idea. If on Unix, you/we could perhaps test the behaviour
> on a different (remote) X display?
> 
> Please provide more data about the problem context and how to
> reproduce it.
> 
> Regards,
> 
> Olaf
> 
>? > 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).
>? >
>? > 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#


      ?No te gusta tu direcci?n de correo?
Consigue una que te guste de verdad - millones de direcciones de correo disponibles en Yahoo!
http://es.docs.yahoo.com/mail/nueva_direccion.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080731/3ff8953c/attachment-0002.html>

From jayk123 at hotmail.com  Fri Aug  1 02:23:43 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 1 Aug 2008 00:23:43 +0000
Subject: [M3devel] need help with cm3 problem before I deliver
	software	this week
In-Reply-To: <464840.85424.qm@web27104.mail.ukl.yahoo.com>
References: <537778.13498.qm@web27107.mail.ukl.yahoo.com>
	<464840.85424.qm@web27104.mail.ukl.yahoo.com>
Message-ID: <COL101-W37FB9AE76D233A727F58D1E67F0@phx.gbl>


Try this also:
 
d:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinTrestle.m3
 
(*-------------------------------------------------------- initialization ---*)
VAR  useEvent_WM_CHAR := FALSE;BEGIN  WITH v = Env.Get("USE_EVENT_WM_CHAR") DO    IF v # NIL THEN      useEvent_WM_CHAR := Text.Length(v) = 0 OR                          Text.GetChar(v, 0) = '1' OR                          Text.GetChar(v, 0) = 'y' OR                          Text.GetChar(v, 0) = 'Y';    END;  END;  CreateTrestle ();END WinTrestle. set USE_EVENT_WM_CHAR=1
 or 
 set USE_EVENT_WM_CHAR=Yucky! 
 
(I think it should check for "y", or "yes", case insensitive, not just any string that starts with "y".., or only allow 0 or 1, and error for anything else, and put M3 or CM3 at the front of the variable to not clash with other uses...)
 
Though, granted, I am just totally guessing right now.
 
   - Jay



Date: Thu, 31 Jul 2008 23:16:05 +0000From: dabenavidesd at yahoo.esTo: rodney.bates at wichita.edu; rcoleburn at scires.comCC: m3devel at elegosoft.comSubject: Re: [M3devel] need help with cm3 problem before I deliver software this week



Hi all:They are @M3TraceWinMsgs and @M3SlowTraceI get it in the file m3-ui/ui/src/winvbt/WinTrestle.m3lines 1096, 1097  trace_msgs := RTParams.IsPresent ("TraceWinMsgs");  slow_trace := RTParams.IsPresent ("SlowTrace");Thanks--- El jue, 31/7/08, Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es> escribi?:
De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>Asunto: Re: [M3devel] need help with cm3 problem before I deliver software this weekPara: "Rodney M. Bates" <rodney.bates at wichita.edu>, "Randy Coleburn" <rcoleburn at scires.com>CC: m3devel at elegosoft.comFecha: jueves, 31 julio, 2008 5:43Hi all:I think I remember somewhere there are runtime
 parameters for debugging Trestleon windows implementation. Check the source code of it; I can't find them inthis moment.Thanks--- El jue, 31/7/08, Randy Coleburn <rcoleburn at scires.com> escribi?:De: Randy Coleburn <rcoleburn at scires.com>Asunto: Re: [M3devel] need help with cm3 problem before I deliver software thisweekPara: "Rodney M. Bates" <rodney.bates at wichita.edu>CC: m3devel at elegosoft.comFecha: jueves, 31 julio, 2008 10:51 Rodney: I am using Windows XP Professional, Service Pack 2 (on some systems, ServicePack 3 is applied). Michel Dagenais suggested that if the problem does not reproduce on Linux, thatit might have to do with how Windows reports character events.  He thought aFilter VBT may exist somewhere that would aid in debugging by printing methodcalls before propagating them to father/son.  This filter VBT would be
 insertedat different places in the VBT tree to get tracing information.  Are youfamiliar with something like this? As for the pixmaps, Michel suggests increasing the resolution of the originalpixmap to help alleviate problems with upscaling.  I may try this, but ofcourse, FormsVBT uses a lot of pixmap resources, for example, radio, boolean,checkmark, numeric, etc all use pixmaps. Regards,Randy>>> "Rodney M. Bates" <rodney.bates at wichita.edu>7/31/2008 9:33 AM >>>Which variant of the M3 Windows target are you using?  I don't have anyof them built right now.Randy Coleburn wrote:> Hi Olaf, Daniel, Rodney, et al:>  > Thanks for your responses so far.  Sorry for the delay in replying, but > our email server has been offline for nearly 24-hours.  There were some > severe electrical storms that
 took down both redundant power systems for > our email system.  Hope I have not missed any of your replies.>  > Right now, I am delivering the software on Windows XP using SP2 or > greater.  I have not tried to see if this problem also occurs on Unix.  > I don't have ready access to a unix system from my current location.>  > So it is perhaps a Windows-only problem with Trestle/FormsVBT.  In any > event, it is a real problem for me.>  > As for the pixmap stretching problem, I have tested various resolutions > on the customer's computer.  Unfortunately, the customer demands that> the display resolution stay at the 1920x1200.> 1920x1200=pixmap stretch problem> 1680x1050=pixmap stretch problem> 1440x900=no problem> 1024x768=no problem>  > Regards,> Randy> > 
 >>> Olaf Wagner <wagner at elegosoft.com> 7/30/2008 2:24 AM>>>> Quoting Randy Coleburn <rcoleburn at scires.com>:> >  > Hi:>  >>  > I've been using cm3 to develop software I am delivering thisweek to >  >  a customer.  During the acceptance testing, we've run into a>  > problem  that I have not been able to solve.  I am hoping someonein >  > the cm3  community can help.  I need to solve this problem ASAPthis >  > week.>  >>  > This problem is easily reproduced using the "formsedit"program.>  >>  > The problem is with the TypeIn and TypeScript FormsVBT elementsused >  >  in my program.  Since formsedit uses these, you can easily >  > reproduce  the
 problem.>  >>  > Click with the mouse to move the insertion point somewhere in the >  > text.  Observe that the cursor moves to that point.  Now, usethe  >  > left arrow key to move the insertion point a few characters tothe  >  > left.  Then, type a few characters.  Observe that the first  >  > character you type shows up at the place where you initiallymoved  >  > the cursor with the mouse, while the remaining characters show upat >  >  the place where you moved the cursor via the left-arrow key. This  >  > behavior is wrong.  The first character you type should be atthe  >  > current insertion point, not at the one from the mouse move.> > Randy,> > I just rebuilt the CM3 GUI
 libraries and formsedit, but I wasn't able> to reproduce the problem on FreeBSD 6.3.> > Does the problem show up on all platforms you are working on?> Which are these?> > Are there any local modifications to the libraries which I may not> have?> > If it occurs only on Unix, it may be possible that a weird window> manager interferes with the event delivery; otherwise I've got no> good idea. If on Unix, you/we could perhaps test the behaviour> on a different (remote) X display?> > Please provide more data about the problem context and how to> reproduce it.> > Regards,> > Olaf> >  > I'm sure the fix is easy, but I haven't been able to locateit yet.  >  >  It probably has to do with the internal idea of the insertionpoint >  >  not getting updated
 properly.  Note that the cursor on thescreen >  > 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).>  >>  > Any assistance you can provide is very much appreciated and willgo  >  > a long way toward keeping Modula-3 use alive and well for this  >  > project.  If we can't fix this one, the customers will wantto  >  > re-code everything in some Microsoft language, probably C++ or C#

Enviado desde Correo Yahoo!La bandeja de entrada m?s inteligente.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/3e9294c6/attachment-0002.html>

From rcoleburn at scires.com  Fri Aug  1 06:28:25 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Fri, 01 Aug 2008 00:28:25 -0400
Subject: [M3devel] need help with cm3 problem before I
	deliver	software	this week
In-Reply-To: <COL101-W37FB9AE76D233A727F58D1E67F0@phx.gbl>
References: <537778.13498.qm@web27107.mail.ukl.yahoo.com>
	<464840.85424.qm@web27104.mail.ukl.yahoo.com>
	<COL101-W37FB9AE76D233A727F58D1E67F0@phx.gbl>
Message-ID: <489258A0.1E75.00D7.1@scires.com>

Jay:
 
I tried "set USE_EVENT_WM_CHAR=1"
 
The result is that I get two or more characters on the screen for each
single character typed.
 
Regards,
Randy

>>> Jay <jayk123 at hotmail.com> 7/31/2008 8:23 PM >>>
Try this also:
 
d:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinTrestle.m3
 
(*--------------------------------------------------------
initialization ---*)
VAR
  useEvent_WM_CHAR := FALSE;
BEGIN
  WITH v = Env.Get("USE_EVENT_WM_CHAR") DO
    IF v # NIL THEN
      useEvent_WM_CHAR := Text.Length(v) = 0 OR
                          Text.GetChar(v, 0) = '1' OR
                          Text.GetChar(v, 0) = 'y' OR
                          Text.GetChar(v, 0) = 'Y';
    END;
  END;
  CreateTrestle ();
END WinTrestle.


 set USE_EVENT_WM_CHAR=1
 or 
 set USE_EVENT_WM_CHAR=Yucky! 
 
(I think it should check for "y", or "yes", case insensitive, not just
any string that starts with "y".., or only allow 0 or 1, and error for
anything else, and put M3 or CM3 at the front of the variable to not
clash with other uses...)
 
Though, granted, I am just totally guessing right now.
 
   - Jay


Date: Thu, 31 Jul 2008 23:16:05 +0000
From: dabenavidesd at yahoo.es 
To: rodney.bates at wichita.edu; rcoleburn at scires.com 
CC: m3devel at elegosoft.com 
Subject: Re: [M3devel] need help with cm3 problem before I deliver
software this week



Hi all:
They are @M3TraceWinMsgs and @M3SlowTrace
I get it in the file m3-ui/ui/src/winvbt/WinTrestle.m3
lines 1096, 1097
  trace_msgs := RTParams.IsPresent ("TraceWinMsgs");
  slow_trace := RTParams.IsPresent ("SlowTrace");
Thanks


--- El jue, 31/7/08, Daniel Alejandro Benavides D.
<dabenavidesd at yahoo.es> escribi?:


De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] need help with cm3 problem before I deliver
software this week
Para: "Rodney M. Bates" <rodney.bates at wichita.edu>, "Randy Coleburn"
<rcoleburn at scires.com>
CC: m3devel at elegosoft.com 
Fecha: jueves, 31 julio, 2008 5:43

Hi all:
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.
Thanks

--- El jue, 31/7/08, Randy Coleburn <rcoleburn at scires.com> escribi?:
De: Randy Coleburn <rcoleburn at scires.com>
Asunto: Re: [M3devel] need help with cm3 problem before I deliver
software this
week
Para: "Rodney M. Bates" <rodney.bates at wichita.edu>
CC: m3devel at elegosoft.com 
Fecha: jueves, 31 julio, 2008 10:51



Rodney:
 
I am using Windows XP Professional, Service Pack 2 (on some systems,
Service
Pack 3 is applied).
 
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?
 
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.
 
Regards,
Randy

>>> "Rodney M. Bates" <rodney.bates at wichita.edu>
7/31/2008 9:33 AM >>>
Which variant of the M3 Windows target are you using?  I don't have
any
of them built right now.

Randy Coleburn wrote:
> Hi Olaf, Daniel, Rodney, et al:
>  
> Thanks for your responses so far.  Sorry for the delay in replying,
but 
> our email server has been offline for nearly 24-hours.  There were
some 
> severe electrical storms that took down both redundant power systems
for 
> our email system.  Hope I have not missed any of your replies.
>  
> Right now, I am delivering the software on Windows XP using SP2 or 
> greater.  I have not tried to see if this problem also occurs on
Unix.  
> I don't have ready access to a unix system from my current location.
>  
> So it is perhaps a Windows-only problem with Trestle/FormsVBT.  In
any 
> event, it is a real problem for me.
>  
> As for the pixmap stretching problem, I have tested various
resolutions 
> on the customer's computer.  Unfortunately, the customer demands
that

> the display resolution stay at the 1920x1200.
> 1920x1200=pixmap stretch problem
> 1680x1050=pixmap stretch problem
> 1440x900=no problem
> 1024x768=no problem
>  
> Regards,
> Randy
> 
>  >>> Olaf Wagner <wagner at elegosoft.com> 7/30/2008 2:24 AM
>>>
> Quoting Randy Coleburn <rcoleburn at scires.com>:
> 
>  > Hi:
>  >
>  > 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.
>  >
>  > This problem is easily reproduced using the "formsedit"
program.
>  >
>  > The problem is with the TypeIn and TypeScript FormsVBT elements
used 
>  >  in my program.  Since formsedit uses these, you can easily 
>  > reproduce  the problem.
>  >
>  > 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.
> 
> Randy,
> 
> I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't
able
> to reproduce the problem on FreeBSD 6.3.
> 
> Does the problem show up on all platforms you are working on?
> Which are these?
> 
> Are there any local modifications to the libraries which I may not
> have?
> 
> If it occurs only on Unix, it may be possible that a weird window
> manager interferes with the event delivery; otherwise I've got no
> good idea. If on Unix, you/we could perhaps test the behaviour
> on a different (remote) X display?
> 
> Please provide more data about the problem context and how to
> reproduce it.
> 
> Regards,
> 
> Olaf
> 
>  > 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).
>  >
>  > 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#


Enviado desde Correo Yahoo! (
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
)
La bandeja de entrada m?s inteligente.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/03efd605/attachment-0002.html>

From rcoleburn at scires.com  Fri Aug  1 06:44:38 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Fri, 01 Aug 2008 00:44:38 -0400
Subject: [M3devel] need help with cm3 problem before I deliver	software
	this week
In-Reply-To: <464840.85424.qm@web27104.mail.ukl.yahoo.com>
References: <537778.13498.qm@web27107.mail.ukl.yahoo.com>
	<464840.85424.qm@web27104.mail.ukl.yahoo.com>
Message-ID: <48925C6D.1E75.00D7.1@scires.com>

Daniel:
 
I tried @M3SlowTrace, but it does not seem to produce any output.
 
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:

msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
msg 132 = WM_NCHITTEST
msg 32 = WM_SETCURSOR
msg 513 = WM_LBUTTONDOWN
msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
msg 514 = WM_LBUTTONUP
 | msg 132 = WM_NCHITTEST
 | msg 533 = ???
msg 514 = WM_LBUTTONUP
msg 132 = WM_NCHITTEST
msg 32 = WM_SETCURSOR
msg 512 = WM_MOUSEMOVE (aka WM_MOUSEFIRST)
msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
msg 256 = WM_KEYDOWN (aka WM_KEYFIRST)
msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
msg 257 = WM_KEYUP
msg 1033 = PAINTBATCH_VBT
msg 256 = WM_KEYDOWN (aka WM_KEYFIRST)
msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
msg 257 = WM_KEYUP
msg 1033 = PAINTBATCH_VBT
msg 256 = WM_KEYDOWN (aka WM_KEYFIRST)
msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
msg 257 = WM_KEYUP
msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
msg 256 = WM_KEYDOWN (aka WM_KEYFIRST)
msg 258 = WM_CHAR
msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
msg 257 = WM_KEYUP
msg 1033 = PAINTBATCH_VBT
msg 256 = WM_KEYDOWN (aka WM_KEYFIRST)
msg 258 = WM_CHAR
msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
msg 257 = WM_KEYUP
msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
msg 1033 = PAINTBATCH_VBT
 
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.
 
Do these messages help?  It is interesting to note that one of the
messages (#533) is identified as "???"
 
Regards,
Randy

>>> "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> 7/31/2008
7:16 PM >>>

Hi all:
They are @M3TraceWinMsgs and @M3SlowTrace
I get it in the file m3-ui/ui/src/winvbt/WinTrestle.m3
lines 1096, 1097
  trace_msgs := RTParams.IsPresent ("TraceWinMsgs");
  slow_trace := RTParams.IsPresent ("SlowTrace");
Thanks


--- El jue, 31/7/08, Daniel Alejandro Benavides D.
<dabenavidesd at yahoo.es> escribi?:


De: Daniel Alejandro Benavides D. <dabenavidesd at yahoo.es>
Asunto: Re: [M3devel] need help with cm3 problem before I deliver
software this week
Para: "Rodney M. Bates" <rodney.bates at wichita.edu>, "Randy Coleburn"
<rcoleburn at scires.com>
CC: m3devel at elegosoft.com 
Fecha: jueves, 31 julio, 2008 5:43

Hi all:
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.
Thanks

--- El jue, 31/7/08, Randy Coleburn <rcoleburn at scires.com> escribi?:
De: Randy Coleburn <rcoleburn at scires.com>
Asunto: Re: [M3devel] need help with cm3 problem before I deliver
software this
week
Para: "Rodney M. Bates" <rodney.bates at wichita.edu>
CC: m3devel at elegosoft.com 
Fecha: jueves, 31 julio, 2008 10:51



Rodney:
 
I am using Windows XP Professional, Service Pack 2 (on some systems,
Service
Pack 3 is applied).
 
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?
 
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.
 
Regards,
Randy

>>> "Rodney M. Bates" <rodney.bates at wichita.edu>
7/31/2008 9:33 AM >>>
Which variant of the M3 Windows target are you using?  I don't have
any
of them built right now.

Randy Coleburn wrote:
> Hi Olaf, Daniel, Rodney, et al:
>  
> Thanks for your responses so far.  Sorry for the delay in replying,
but 
> our email server has been offline for nearly 24-hours.  There were
some 
> severe electrical storms that took down both redundant power systems
for 
> our email system.  Hope I have not missed any of your replies.
>  
> Right now, I am delivering the software on Windows XP using SP2 or 
> greater.  I have not tried to see if this problem also occurs on
Unix.  
> I don't have ready access to a unix system from my current location.
>  
> So it is perhaps a Windows-only problem with Trestle/FormsVBT.  In
any 
> event, it is a real problem for me.
>  
> As for the pixmap stretching problem, I have tested various
resolutions 
> on the customer's computer.  Unfortunately, the customer demands
that

> the display resolution stay at the 1920x1200.
> 1920x1200=pixmap stretch problem
> 1680x1050=pixmap stretch problem
> 1440x900=no problem
> 1024x768=no problem
>  
> Regards,
> Randy
> 
>  >>> Olaf Wagner <wagner at elegosoft.com> 7/30/2008 2:24 AM
>>>
> Quoting Randy Coleburn <rcoleburn at scires.com>:
> 
>  > Hi:
>  >
>  > 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.
>  >
>  > This problem is easily reproduced using the "formsedit"
program.
>  >
>  > The problem is with the TypeIn and TypeScript FormsVBT elements
used 
>  >  in my program.  Since formsedit uses these, you can easily 
>  > reproduce  the problem.
>  >
>  > 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.
> 
> Randy,
> 
> I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't
able
> to reproduce the problem on FreeBSD 6.3.
> 
> Does the problem show up on all platforms you are working on?
> Which are these?
> 
> Are there any local modifications to the libraries which I may not
> have?
> 
> If it occurs only on Unix, it may be possible that a weird window
> manager interferes with the event delivery; otherwise I've got no
> good idea. If on Unix, you/we could perhaps test the behaviour
> on a different (remote) X display?
> 
> Please provide more data about the problem context and how to
> reproduce it.
> 
> Regards,
> 
> Olaf
> 
>  > 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).
>  >
>  > 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#


Enviado desde Correo Yahoo! (
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
)
La bandeja de entrada m?s inteligente.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/df3dc33a/attachment-0002.html>

From rcoleburn at scires.com  Fri Aug  1 07:00:24 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Fri, 01 Aug 2008 01:00:24 -0400
Subject: [M3devel] need help with cm3 problem before I
	deliver	software	this week
In-Reply-To: <20080731184449.su7qkp9x6ocwkoo0@mail.elegosoft.com>
References: <488F4292.1E75.00D7.1@scires.com>
	<20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com>
	<4890EB9C.1E75.00D7.1@scires.com> <4891BF18.8000905@wichita.edu>
	<4891A737.1E75.00D7.1@scires.com>
	<20080731184449.su7qkp9x6ocwkoo0@mail.elegosoft.com>
Message-ID: <4892601C.1E75.00D7.1@scires.com>

Olaf:
 
The problem reproduces every time on my system.  I've tried it on three
different XP computers with same results every time.
 
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.
 
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.
 
Regards,
Randy

>>> Olaf Wagner <wagner at elegosoft.com> 7/31/2008 12:44 PM >>>
Quoting Randy Coleburn <rcoleburn at scires.com>:

> Rodney:
>
> I am using Windows XP Professional, Service Pack 2 (on some systems,
> Service Pack 3 is applied).

Hi Randy,

I just tried formsedit on exactly this system (XP professional, SP2)
in my virtual machine, and wasn't able to see any fault wrt. cursor
processing and typing, too. I checked-out and compiled all the latest
sources of the relevant gui packages (ui, vbtkit, formsvbt etc.), but
that didn't make any difference (though some changes had been
applied).
For me it just seems to work correctly. It may be of interest though
that some months ago when I was last working on this system for the
regression tests, I applied all existing Microsoft patches; but you've
done that probably, too.

I've got no idea about the pixmap problem, too.
As long as nobody else is able to reproduce the problem it will
remain difficult to analyze this problem.

Sorry that I cannot be of more help,

Olaf

PS: Are you sure that you are really using exactly the current CM3 gui
libraries, and not some adapted or modified stuff from an older
release?

> 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?
>
> 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.
>
> Regards,
> Randy
>
>>>> "Rodney M. Bates" <rodney.bates at wichita.edu> 7/31/2008 9:33 AM
>>>
> Which variant of the M3 Windows target are you using?  I don't have
> any
> of them built right now.
>
> Randy Coleburn wrote:
>> Hi Olaf, Daniel, Rodney, et al:
>>
>> Thanks for your responses so far.  Sorry for the delay in replying,
> but
>> our email server has been offline for nearly 24-hours.  There were
> some
>> severe electrical storms that took down both redundant power
systems
> for
>> our email system.  Hope I have not missed any of your replies.
>>
>> Right now, I am delivering the software on Windows XP using SP2 or
>> greater.  I have not tried to see if this problem also occurs on
> Unix.
>> I don't have ready access to a unix system from my current
location.
>>
>> So it is perhaps a Windows-only problem with Trestle/FormsVBT.  In
> any
>> event, it is a real problem for me.
>>
>> As for the pixmap stretching problem, I have tested various
> resolutions
>> on the customer's computer.  Unfortunately, the customer demands
that
>
>> the display resolution stay at the 1920x1200.
>> 1920x1200=pixmap stretch problem
>> 1680x1050=pixmap stretch problem
>> 1440x900=no problem
>> 1024x768=no problem
>>
>> Regards,
>> Randy
>>
>>  >>> Olaf Wagner <wagner at elegosoft.com> 7/30/2008 2:24 AM >>>
>> Quoting Randy Coleburn <rcoleburn at scires.com>:
>>
>>  > Hi:
>>  >
>>  > 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.
>>  >
>>  > This problem is easily reproduced using the "formsedit" program.
>>  >
>>  > The problem is with the TypeIn and TypeScript FormsVBT elements
> used
>>  >  in my program.  Since formsedit uses these, you can easily
>>  > reproduce  the problem.
>>  >
>>  > 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.
>>
>> Randy,
>>
>> I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't
> able
>> to reproduce the problem on FreeBSD 6.3.
>>
>> Does the problem show up on all platforms you are working on?
>> Which are these?
>>
>> Are there any local modifications to the libraries which I may not
>> have?
>>
>> If it occurs only on Unix, it may be possible that a weird window
>> manager interferes with the event delivery; otherwise I've got no
>> good idea. If on Unix, you/we could perhaps test the behaviour
>> on a different (remote) X display?
>>
>> Please provide more data about the problem context and how to
>> reproduce it.
>>
>> Regards,
>>
>> Olaf
>>
>>  > 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).
>>  >
>>  > 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#.
>>  >
>>  > 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.
>>  >
>>  > Regards,
>>  > Randy Coleburn
>>  > Senior Systems Engineer
>>  > Scientific Research Corporation
>>  >
>>
>>
>>
>> --
>> Olaf Wagner -- elego Software Solutions GmbH
>>                 Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin,
> Germany
>> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23
> 45 86 95
>>     http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz:
> Berlin
>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:
> DE163214194
>>
>>
>
> --
> -------------------------------------------------------------
> Rodney M. Bates, retired assistant professor
> Dept. of Computer Science, Wichita State University
> Wichita, KS 67260-0083
> 316-978-3922
> rodney.bates at wichita.edu 
>
>



-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin,
Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45
86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz:
Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:
DE163214194


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/32d067b8/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: formsedit.exe.gz
Type: application/x-gzip
Size: 747981 bytes
Desc: not available
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/32d067b8/attachment-0002.bin>

From jayk123 at hotmail.com  Fri Aug  1 10:43:31 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 1 Aug 2008 08:43:31 +0000
Subject: [M3devel] need help with cm3 problem before I deliver
	software	this week
In-Reply-To: <537778.13498.qm@web27107.mail.ukl.yahoo.com>
References: <4891A737.1E75.00D7.1@scires.com>
	<537778.13498.qm@web27107.mail.ukl.yahoo.com>
Message-ID: <COL101-W47C793FC4B3AB08006FD9DE67F0@phx.gbl>


I can reproduce the problem. Exactly as well reported.
It kind of only happens once. Bring up formsedit, click, left arrow(s), type, it does what Randy said.
Click again, arrows again, type again, not a second time. Good enough though.
Close formsedit, reopen, it repros. Good.
file.save, type backslash or forward slash in the dialog, press return, and boom:
Most other strings are ok, but a single forward or backward slash, booms.
 
****** runtime error:***    An enumeration or subrange value was out of range.***    file "..\src\os\WIN32\FSWin32.m3", line 435***
Stack trace:   FP         PC      Procedure---------  ---------  -------------------------------0x67afccc   0x42524f  BuildStatus + 0x21 in ..\src\os\WIN32\FSWin32.m30x67afe60   0x4251dc  Status + 0x137 in ..\src\os\WIN32\FSWin32.m30x67aff50   0xd9d131  DoStats + 0x253 in ..\src\lego\FileBrowserVBT.m30x67aff88   0x53a6ca  RunThread + 0x1f6 in ..\src\thread\WIN32\ThreadWin32.m30x67affb4   0x53a463  ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3.........  .........  ... more frames ...
 
bugs...
 
 
And is that red line supposed to appear in the gui?
 
 - Jay> Date: Thu, 31 Jul 2008 22:43:07 +0000> From: dabenavidesd at yahoo.es> To: rodney.bates at wichita.edu; rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] need help with cm3 problem before I deliver software this week> > Hi all:> 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.> Thanks> > --- El jue, 31/7/08, Randy Coleburn <rcoleburn at scires.com> escribi?:> De: Randy Coleburn <rcoleburn at scires.com>> Asunto: Re: [M3devel] need help with cm3 problem before I deliver software this week> Para: "Rodney M. Bates" <rodney.bates at wichita.edu>> CC: m3devel at elegosoft.com> Fecha: jueves, 31 julio, 2008 10:51> > > > Rodney:>  > I am using Windows XP Professional, Service Pack 2 (on some systems, Service Pack 3 is applied).>  > 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?>  > 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.>  > Regards,> Randy> > >>> "Rodney M. Bates" <rodney.bates at wichita.edu> 7/31/2008 9:33 AM >>>> Which variant of the M3 Windows target are you using?  I don't have any> of them built right now.> > Randy Coleburn wrote:> > Hi Olaf, Daniel, Rodney, et al:> >  > > Thanks for your responses so far.  Sorry for the delay in replying, but > > our email server has been offline for nearly 24-hours.  There were some > > severe electrical storms that took down both redundant power systems for > > our email system.  Hope I have not missed any of your replies.> >  > > Right now, I am delivering the software on Windows XP using SP2 or > > greater.  I have not tried to see if this problem also occurs on Unix.  > > I don't have ready access to a unix system from my current location.> >  > > So it is perhaps a Windows-only problem with Trestle/FormsVBT.  In any > > event, it is a real problem for me.> >  > > As for the pixmap stretching problem, I have tested various resolutions > > on the customer's computer.  Unfortunately, the customer demands that > > the display resolution stay at the 1920x1200.> > 1920x1200=pixmap stretch problem> > 1680x1050=pixmap stretch problem> > 1440x900=no problem> > 1024x768=no problem> >  > > Regards,> > Randy> > > >  >>> Olaf Wagner <wagner at elegosoft.com> 7/30/2008 2:24 AM >>>> > Quoting Randy Coleburn <rcoleburn at scires.com>:> > > >  > Hi:> >  >> >  > 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.> >  >> >  > This problem is easily reproduced using the "formsedit" program.> >  >> >  > The problem is with the TypeIn and TypeScript FormsVBT elements used > >  >  in my program.  Since formsedit uses these, you can easily > >  > reproduce  the problem.> >  >> >  > 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.> > > > Randy,> > > > I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't able> > to reproduce the problem on FreeBSD 6.3.> > > > Does the problem show up on all platforms you are working on?> > Which are these?> > > > Are there any local modifications to the libraries which I may not> > have?> > > > If it occurs only on Unix, it may be possible that a weird window> > manager interferes with the event delivery; otherwise I've got no> > good idea. If on Unix, you/we could perhaps test the behaviour> > on a different (remote) X display?> > > > Please provide more data about the problem context and how to> > reproduce it.> > > > Regards,> > > > Olaf> > > >  > 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).> >  >> >  > 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#
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/a6c7192d/attachment-0002.html>

From jayk123 at hotmail.com  Fri Aug  1 10:57:20 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 1 Aug 2008 08:57:20 +0000
Subject: [M3devel] files over 2gig break 32bit Trestle file browser
 (maybe only Win32) (was the formsedit bug)
In-Reply-To: <COL101-W47C793FC4B3AB08006FD9DE67F0@phx.gbl>
References: <4891A737.1E75.00D7.1@scires.com>
	<537778.13498.qm@web27107.mail.ukl.yahoo.com> 
	<COL101-W47C793FC4B3AB08006FD9DE67F0@phx.gbl>
Message-ID: <COL101-W749C621ADBFF6587DAC097E67F0@phx.gbl>


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



From: jayk123 at hotmail.comTo: dabenavidesd at yahoo.es; rodney.bates at wichita.edu; rcoleburn at scires.comDate: Fri, 1 Aug 2008 08:43:31 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] need help with cm3 problem before I deliver software this week


I can reproduce the problem. Exactly as well reported.It kind of only happens once. Bring up formsedit, click, left arrow(s), type, it does what Randy said.Click again, arrows again, type again, not a second time. Good enough though.Close formsedit, reopen, it repros. Good.file.save, type backslash or forward slash in the dialog, press return, and boom:Most other strings are ok, but a single forward or backward slash, booms. ****** runtime error:***    An enumeration or subrange value was out of range.***    file "..\src\os\WIN32\FSWin32.m3", line 435***Stack trace:   FP         PC      Procedure---------  ---------  -------------------------------0x67afccc   0x42524f  BuildStatus + 0x21 in ..\src\os\WIN32\FSWin32.m30x67afe60   0x4251dc  Status + 0x137 in ..\src\os\WIN32\FSWin32.m30x67aff50   0xd9d131  DoStats + 0x253 in ..\src\lego\FileBrowserVBT.m30x67aff88   0x53a6ca  RunThread + 0x1f6 in ..\src\thread\WIN32\ThreadWin32.m30x67affb4   0x53a463  ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3.........  .........  ... more frames ... bugs...  And is that red line supposed to appear in the gui?  - Jay> Date: Thu, 31 Jul 2008 22:43:07 +0000> From: dabenavidesd at yahoo.es> To: rodney.bates at wichita.edu; rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] need help with cm3 problem before I deliver software this week> > Hi all:> 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.> Thanks> > --- El jue, 31/7/08, Randy Coleburn <rcoleburn at scires.com> escribi?:> De: Randy Coleburn <rcoleburn at scires.com>> Asunto: Re: [M3devel] need help with cm3 problem before I deliver software this week> Para: "Rodney M. Bates" <rodney.bates at wichita.edu>> CC: m3devel at elegosoft.com> Fecha: jueves, 31 julio, 2008 10:51> > > > Rodney:>  > I am using Windows XP Professional, Service Pack 2 (on some systems, Service Pack 3 is applied).>  > 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?>  > 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.>  > Regards,> Randy> > >>> "Rodney M. Bates" <rodney.bates at wichita.edu> 7/31/2008 9:33 AM >>>> Which variant of the M3 Windows target are you using?  I don't have any> of them built right now.> > Randy Coleburn wrote:> > Hi Olaf, Daniel, Rodney, et al:> >  > > Thanks for your responses so far.  Sorry for the delay in replying, but > > our email server has been offline for nearly 24-hours.  There were some > > severe electrical storms that took down both redundant power systems for > > our email system.  Hope I have not missed any of your replies.> >  > > Right now, I am delivering the software on Windows XP using SP2 or > > greater.  I have not tried to see if this problem also occurs on Unix.  > > I don't have ready access to a unix system from my current location.> >  > > So it is perhaps a Windows-only problem with Trestle/FormsVBT.  In any > > event, it is a real problem for me.> >  > > As for the pixmap stretching problem, I have tested various resolutions > > on the customer's computer.  Unfortunately, the customer demands that > > the display resolution stay at the 1920x1200.> > 1920x1200=pixmap stretch problem> > 1680x1050=pixmap stretch problem> > 1440x900=no problem> > 1024x768=no problem> >  > > Regards,> > Randy> > > >  >>> Olaf Wagner <wagner at elegosoft.com> 7/30/2008 2:24 AM >>>> > Quoting Randy Coleburn <rcoleburn at scires.com>:> > > >  > Hi:> >  >> >  > 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.> >  >> >  > This problem is easily reproduced using the "formsedit" program.> >  >> >  > The problem is with the TypeIn and TypeScript FormsVBT elements used > >  >  in my program.  Since formsedit uses these, you can easily > >  > reproduce  the problem.> >  >> >  > 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.> > > > Randy,> > > > I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't able> > to reproduce the problem on FreeBSD 6.3.> > > > Does the problem show up on all platforms you are working on?> > Which are these?> > > > Are there any local modifications to the libraries which I may not> > have?> > > > If it occurs only on Unix, it may be possible that a weird window> > manager interferes with the event delivery; otherwise I've got no> > good idea. If on Unix, you/we could perhaps test the behaviour> > on a different (remote) X display?> > > > Please provide more data about the problem context and how to> > reproduce it.> > > > Regards,> > > > Olaf> > > >  > 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).> >  >> >  > 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#
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/112b85c5/attachment-0002.html>

From jayk123 at hotmail.com  Fri Aug  1 11:15:56 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 1 Aug 2008 09:15:56 +0000
Subject: [M3devel] need help with cm3 problem before I deliver
	software	this week
In-Reply-To: <537778.13498.qm@web27107.mail.ukl.yahoo.com>
References: <4891A737.1E75.00D7.1@scires.com>
	<537778.13498.qm@web27107.mail.ukl.yahoo.com> 
Message-ID: <COL101-W61F864A9FD2E441743295E67F0@phx.gbl>


I take that back -- it repros better than I said.
Every time I click, arrow, type, the first text insertion happens where I clicked.
Trestle is so layered..so many calls to a function called "Mouse" when you click..
 
 - Jay



From: jayk123 at hotmail.comTo: dabenavidesd at yahoo.es; rodney.bates at wichita.edu; rcoleburn at scires.comCC: m3devel at elegosoft.comSubject: RE: [M3devel] need help with cm3 problem before I deliver software this weekDate: Fri, 1 Aug 2008 08:43:31 +0000


I can reproduce the problem. Exactly as well reported.It kind of only happens once. Bring up formsedit, click, left arrow(s), type, it does what Randy said.Click again, arrows again, type again, not a second time. Good enough though.Close formsedit, reopen, it repros. Good.file.save, type backslash or forward slash in the dialog, press return, and boom:Most other strings are ok, but a single forward or backward slash, booms. ****** runtime error:***    An enumeration or subrange value was out of range.***    file "..\src\os\WIN32\FSWin32.m3", line 435***Stack trace:   FP         PC      Procedure---------  ---------  -------------------------------0x67afccc   0x42524f  BuildStatus + 0x21 in ..\src\os\WIN32\FSWin32.m30x67afe60   0x4251dc  Status + 0x137 in ..\src\os\WIN32\FSWin32.m30x67aff50   0xd9d131  DoStats + 0x253 in ..\src\lego\FileBrowserVBT.m30x67aff88   0x53a6ca  RunThread + 0x1f6 in ..\src\thread\WIN32\ThreadWin32.m30x67affb4   0x53a463  ThreadBase + 0x3a in ..\src\thread\WIN32\ThreadWin32.m3.........  .........  ... more frames ... bugs...  And is that red line supposed to appear in the gui?  - Jay> Date: Thu, 31 Jul 2008 22:43:07 +0000> From: dabenavidesd at yahoo.es> To: rodney.bates at wichita.edu; rcoleburn at scires.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] need help with cm3 problem before I deliver software this week> > Hi all:> 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.> Thanks> > --- El jue, 31/7/08, Randy Coleburn <rcoleburn at scires.com> escribi?:> De: Randy Coleburn <rcoleburn at scires.com>> Asunto: Re: [M3devel] need help with cm3 problem before I deliver software this week> Para: "Rodney M. Bates" <rodney.bates at wichita.edu>> CC: m3devel at elegosoft.com> Fecha: jueves, 31 julio, 2008 10:51> > > > Rodney:>  > I am using Windows XP Professional, Service Pack 2 (on some systems, Service Pack 3 is applied).>  > 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?>  > 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.>  > Regards,> Randy> > >>> "Rodney M. Bates" <rodney.bates at wichita.edu> 7/31/2008 9:33 AM >>>> Which variant of the M3 Windows target are you using?  I don't have any> of them built right now.> > Randy Coleburn wrote:> > Hi Olaf, Daniel, Rodney, et al:> >  > > Thanks for your responses so far.  Sorry for the delay in replying, but > > our email server has been offline for nearly 24-hours.  There were some > > severe electrical storms that took down both redundant power systems for > > our email system.  Hope I have not missed any of your replies.> >  > > Right now, I am delivering the software on Windows XP using SP2 or > > greater.  I have not tried to see if this problem also occurs on Unix.  > > I don't have ready access to a unix system from my current location.> >  > > So it is perhaps a Windows-only problem with Trestle/FormsVBT.  In any > > event, it is a real problem for me.> >  > > As for the pixmap stretching problem, I have tested various resolutions > > on the customer's computer.  Unfortunately, the customer demands that > > the display resolution stay at the 1920x1200.> > 1920x1200=pixmap stretch problem> > 1680x1050=pixmap stretch problem> > 1440x900=no problem> > 1024x768=no problem> >  > > Regards,> > Randy> > > >  >>> Olaf Wagner <wagner at elegosoft.com> 7/30/2008 2:24 AM >>>> > Quoting Randy Coleburn <rcoleburn at scires.com>:> > > >  > Hi:> >  >> >  > 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.> >  >> >  > This problem is easily reproduced using the "formsedit" program.> >  >> >  > The problem is with the TypeIn and TypeScript FormsVBT elements used > >  >  in my program.  Since formsedit uses these, you can easily > >  > reproduce  the problem.> >  >> >  > 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.> > > > Randy,> > > > I just rebuilt the CM3 GUI libraries and formsedit, but I wasn't able> > to reproduce the problem on FreeBSD 6.3.> > > > Does the problem show up on all platforms you are working on?> > Which are these?> > > > Are there any local modifications to the libraries which I may not> > have?> > > > If it occurs only on Unix, it may be possible that a weird window> > manager interferes with the event delivery; otherwise I've got no> > good idea. If on Unix, you/we could perhaps test the behaviour> > on a different (remote) X display?> > > > Please provide more data about the problem context and how to> > reproduce it.> > > > Regards,> > > > Olaf> > > >  > 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).> >  >> >  > 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#
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/f991c98a/attachment-0002.html>

From jayk123 at hotmail.com  Fri Aug  1 15:04:13 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 1 Aug 2008 13:04:13 +0000
Subject: [M3devel] winuser.i3
Message-ID: <COL101-W12E97C0F8EA0D9038B2985E67F0@phx.gbl>


Darko,
 
1) Where did these come from?
    (* Where did these come from? *)     MFS_MASK            = 16_0000108B;     MFS_HOTTRACKDRAWN   = 16_10000000;     MFS_CACHEDBMP       = 16_20000000;     MFS_BOTTOMGAPDROP   = 16_40000000;     MFS_TOPGAPDROP      = 16_80000000;     MFS_GAPDROP         = 16_C0000000;
I can't find them in "real" headers.
 
2) Why DEFAULT_GUI_FONT here? It belongs in WinGDI.i3. I'm moving it.
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/de74cb54/attachment-0002.html>

From jayk123 at hotmail.com  Fri Aug  1 15:52:43 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 1 Aug 2008 13:52:43 +0000
Subject: [M3devel] need help with cm3 problem before I
	deliver	software	this week
In-Reply-To: <48925C6D.1E75.00D7.1@scires.com>
References: <537778.13498.qm@web27107.mail.ukl.yahoo.com>
	<464840.85424.qm@web27104.mail.ukl.yahoo.com> 
	<48925C6D.1E75.00D7.1@scires.com>
Message-ID: <COL101-W5623694736FE1A45441C7EE67F0@phx.gbl>


 > It is interesting to note that one of the messages (#533) is identified as "???"
This is not worrisome, and it should be fixed now.
They are:
#define WM_CAPTURECHANGED               0x0215
Sadly the real problem is not yet fixed -- not even understood. :(
 
It definitely doesn't occur on other systems?
It seems quite odd -- clearly formsedit is not missing any mouse or key events, and it is dealing with all of them at least partly correctly.
It clearly isn't missing any events, otherwise it wouldn't act as correctly as it does.
The mouse click moves the insertion point and the blinking cursor. The arrow keys move the blinking cursor and the "next" insertion point, typing insert the desired characters, just that FIRST character goes to the wrong place. Strange.
 
Recoding everything in C++ or C# isn't a bad idea imho, but certainly overkill for this one problem...
 
Trying with 3.6 or 4.1 would be good. I should do that very soon. Easier than reading through all the Trestle code. :(
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/d6a91b2a/attachment-0002.html>

From jayk123 at hotmail.com  Fri Aug  1 16:06:45 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 1 Aug 2008 14:06:45 +0000
Subject: [M3devel] need help with cm3 problem before
	I	deliver	software	this week
In-Reply-To: <COL101-W5623694736FE1A45441C7EE67F0@phx.gbl>
References: <537778.13498.qm@web27107.mail.ukl.yahoo.com>
	<464840.85424.qm@web27104.mail.ukl.yahoo.com> 
	<48925C6D.1E75.00D7.1@scires.com> 
	<COL101-W5623694736FE1A45441C7EE67F0@phx.gbl>
Message-ID: <COL101-W806E32408CDC1FE80AE503E67F0@phx.gbl>


It works ok with 3.6..

From: jayk123 at hotmail.comTo: rcoleburn at scires.com; rodney.bates at wichita.edu; dabenavidesd at yahoo.esDate: Fri, 1 Aug 2008 13:52:43 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] need help with cm3 problem before I deliver software this week


 > It is interesting to note that one of the messages (#533) is identified as "???"This is not worrisome, and it should be fixed now.They are:#define WM_CAPTURECHANGED               0x0215Sadly the real problem is not yet fixed -- not even understood. :( It definitely doesn't occur on other systems?It seems quite odd -- clearly formsedit is not missing any mouse or key events, and it is dealing with all of them at least partly correctly.It clearly isn't missing any events, otherwise it wouldn't act as correctly as it does.The mouse click moves the insertion point and the blinking cursor. The arrow keys move the blinking cursor and the "next" insertion point, typing insert the desired characters, just that FIRST character goes to the wrong place. Strange. Recoding everything in C++ or C# isn't a bad idea imho, but certainly overkill for this one problem... Trying with 3.6 or 4.1 would be good. I should do that very soon. Easier than reading through all the Trestle code. :(  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/217e4bbc/attachment-0002.html>

From jayk123 at hotmail.com  Fri Aug  1 16:45:02 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 1 Aug 2008 14:45:02 +0000
Subject: [M3devel] need help with cm3 problem before
	I	deliver	software	this week
In-Reply-To: <COL101-W5623694736FE1A45441C7EE67F0@phx.gbl>
References: <537778.13498.qm@web27107.mail.ukl.yahoo.com>
	<464840.85424.qm@web27104.mail.ukl.yahoo.com> 
	<48925C6D.1E75.00D7.1@scires.com> 
	<COL101-W5623694736FE1A45441C7EE67F0@phx.gbl> 
Message-ID: <COL101-W5340B42054B530082445DCE67F0@phx.gbl>


 > It works ok with 3.6..
 
a *quick* and *incomplete* survey of 3.6 vs. current shows:  - deal with change in Text type (platform independent)   - handle WM_CHAR (windows specific)   - handle newlines differently (platform independly, except maybe the data varies per platform) 
 I tried undoing the last two, still no luck. The first is harder to undo, maybe "impossible", just have to read/debug it and decide it is ok or not..?
 Next easy step is probably to see if repros with 4.1,  and then proceed with comparing the "closer" repro vs. non-repro.  If it does not repro with 4.1, and newer releases are available  between it and current -- e.g. 5.2 -- would be good to narrow  down when it started happening and compare those source trees.
The code in question is stuff like mtext and textport.
There are functions named key or Key or mouse or Mouse. Those are also important to look at, I think.
Not being particularly close to figuring this out, consider ignoring everything I have said. :)
It is hard to pass up such a simple repro. :)And the knowledge that 3.6 works, and really not much has changed in the intervening ~12 years..
Oh, and there are pixmap changes.Randy, I glossed over the mail about pixmaps.You have a simple repro of that?You can try it with 3.6?
3.6 should still be readily downloadable from the web, and it really isn'tdifficult to get it up and running, at least on Windows.(I can't speak for Linux. I ran 3.6, albeit hardly at all, on Linux 1.2 I think it was,and NT 3.51, maybe later NT and maybe Win9x)
(and 3.6 is liberally licensed, so anyone can send it around.The notion that 5.1 was the open source release always sounded wrong...)
 - Jay



From: jayk123 at hotmail.comTo: rcoleburn at scires.com; rodney.bates at wichita.edu; dabenavidesd at yahoo.esCC: m3devel at elegosoft.comSubject: RE: [M3devel] need help with cm3 problem before I deliver software this weekDate: Fri, 1 Aug 2008 14:06:45 +0000


It works ok with 3.6..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/ca6fbed3/attachment-0002.html>

From jayk123 at hotmail.com  Fri Aug  1 16:43:17 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 1 Aug 2008 14:43:17 +0000
Subject: [M3devel] winuser.i3
In-Reply-To: <CD17C8FC-CD4C-4927-85C6-6C2FB20F80A2@darko.org>
References: <COL101-W12E97C0F8EA0D9038B2985E67F0@phx.gbl>
	<CD17C8FC-CD4C-4927-85C6-6C2FB20F80A2@darko.org>
Message-ID: <COL101-W4910DD3A123B57A3DFAAE9E67F0@phx.gbl>


Yes, I wouldn't mind that either. Windows.i3, MSWindows.i3.
For now thought I have preserved the structure and moved the font to WinGDI.i3, since it is in WinGDI.h.
I commented out the others, until such time as they are found *somewhere*, so I can least verify their correctness.
(NOT that I am in general verifying everything, just random samples.)
 
 
 - Jay



CC: m3devel at elegosoft.comFrom: darko at darko.orgTo: jayk123 at hotmail.comSubject: Re: [M3devel] winuser.i3Date: Fri, 1 Aug 2008 16:29:15 +0200
I have no Idea where there came from or where they go. Personally I'm of the opinion that all the Windows defs should go in one big file (Win.i3).


On 01/08/2008, at 3:04 PM, Jay wrote:

Darko, 1) Where did these come from?    (* Where did these come from? *)     MFS_MASK            = 16_0000108B;     MFS_HOTTRACKDRAWN   = 16_10000000;     MFS_CACHEDBMP       = 16_20000000;     MFS_BOTTOMGAPDROP   = 16_40000000;     MFS_TOPGAPDROP      = 16_80000000;     MFS_GAPDROP         = 16_C0000000;I can't find them in "real" headers. 2) Why DEFAULT_GUI_FONT here? It belongs in WinGDI.i3. I'm moving it.  - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/d2d11f3a/attachment-0002.html>

From darko at darko.org  Fri Aug  1 16:29:15 2008
From: darko at darko.org (Darko)
Date: Fri, 1 Aug 2008 16:29:15 +0200
Subject: [M3devel] winuser.i3
In-Reply-To: <COL101-W12E97C0F8EA0D9038B2985E67F0@phx.gbl>
References: <COL101-W12E97C0F8EA0D9038B2985E67F0@phx.gbl>
Message-ID: <CD17C8FC-CD4C-4927-85C6-6C2FB20F80A2@darko.org>

I have no Idea where there came from or where they go. Personally I'm  
of the opinion that all the Windows defs should go in one big file  
(Win.i3).


On 01/08/2008, at 3:04 PM, Jay wrote:

> Darko,
>
> 1) Where did these come from?
>     (* Where did these come from? *)
>      MFS_MASK            = 16_0000108B;
>      MFS_HOTTRACKDRAWN   = 16_10000000;
>      MFS_CACHEDBMP       = 16_20000000;
>      MFS_BOTTOMGAPDROP   = 16_40000000;
>      MFS_TOPGAPDROP      = 16_80000000;
>      MFS_GAPDROP         = 16_C0000000;
>
> I can't find them in "real" headers.
>
> 2) Why DEFAULT_GUI_FONT here? It belongs in WinGDI.i3. I'm moving it.
>
>  - Jay
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/057ae0fa/attachment-0002.html>

From jayk123 at hotmail.com  Fri Aug  1 17:28:16 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 1 Aug 2008 15:28:16 +0000
Subject: [M3devel] need help with cm3 problem
	before	I	deliver	software	this week
In-Reply-To: <COL101-W5340B42054B530082445DCE67F0@phx.gbl>
References: <537778.13498.qm@web27107.mail.ukl.yahoo.com>
	<464840.85424.qm@web27104.mail.ukl.yahoo.com> 
	<48925C6D.1E75.00D7.1@scires.com> 
	<COL101-W5623694736FE1A45441C7EE67F0@phx.gbl>  
	<COL101-W5340B42054B530082445DCE67F0@phx.gbl>
Message-ID: <COL101-W37A68B1566CAAAF8791DBFE67F0@phx.gbl>


Clarification: there are other changes.
There was a change in font stuff.
There was added batching of painting.
And more.
 
I'm still stumped. I have to be away from this for a few hours or all day.
I think seeing if 4.1 repros will be good, and then maybe widen the net on either a) what changed (not just trestle?) and b) debugging it.
Really it shouldn't be hard..to figure how out it decides where to place the character.
 
Oh, and save the text file, see if it is in memory and on disk where it is drawn on the screen.
That would be useful to know.
 
ok..the text matches the display.
 
I can roll Wintrestle.i3 back to cm3.6, still repros.
 
Ok, the reason it is platform specific is because of:
 
Searching for 'TextPortModel: TEXT := "'...C:\dev2\cm3.2\m3-ui\vbtkit\src\vbtkitutils\POSIX\VBTKitEnv.i3(30):  TextPortModel: TEXT := "emacs";C:\dev2\cm3.2\m3-ui\vbtkit\src\vbtkitutils\WIN32\VBTKitEnv.i3(30):  TextPortModel: TEXT := "mac";
If you change Windows the the emacs model, no repro.
So try Posix to mac model, hopefully it repros.
 
Ok, Randy, is this actually your bug, or just indicative of it?
 
 - Jay



From: jayk123 at hotmail.comTo: rcoleburn at scires.com; rodney.bates at wichita.edu; dabenavidesd at yahoo.esDate: Fri, 1 Aug 2008 14:45:02 +0000CC: m3devel at elegosoft.comSubject: Re: [M3devel] need help with cm3 problem before I deliver software this week


 > It works ok with 3.6.. a *quick* and *incomplete* survey of 3.6 vs. current shows:  - deal with change in Text type (platform independent)   - handle WM_CHAR (windows specific)   - handle newlines differently (platform independly, except maybe the data varies per platform)  I tried undoing the last two, still no luck. The first is harder to undo, maybe "impossible", just have to read/debug it and decide it is ok or not..? Next easy step is probably to see if repros with 4.1,  and then proceed with comparing the "closer" repro vs. non-repro.  If it does not repro with 4.1, and newer releases are available  between it and current -- e.g. 5.2 -- would be good to narrow  down when it started happening and compare those source trees.The code in question is stuff like mtext and textport.There are functions named key or Key or mouse or Mouse. Those are also important to look at, I think.Not being particularly close to figuring this out, consider ignoring everything I have said. :)It is hard to pass up such a simple repro. :)And the knowledge that 3.6 works, and really not much has changed in the intervening ~12 years..Oh, and there are pixmap changes.Randy, I glossed over the mail about pixmaps.You have a simple repro of that?You can try it with 3.6?3.6 should still be readily downloadable from the web, and it really isn'tdifficult to get it up and running, at least on Windows.(I can't speak for Linux. I ran 3.6, albeit hardly at all, on Linux 1.2 I think it was,and NT 3.51, maybe later NT and maybe Win9x)(and 3.6 is liberally licensed, so anyone can send it around.The notion that 5.1 was the open source release always sounded wrong...) - Jay



From: jayk123 at hotmail.comTo: rcoleburn at scires.com; rodney.bates at wichita.edu; dabenavidesd at yahoo.esCC: m3devel at elegosoft.comSubject: RE: [M3devel] need help with cm3 problem before I deliver software this weekDate: Fri, 1 Aug 2008 14:06:45 +0000

It works ok with 3.6..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/0a69aa5b/attachment-0002.html>

From wagner at elegosoft.com  Fri Aug  1 17:59:07 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Fri, 01 Aug 2008 17:59:07 +0200
Subject: [M3devel] need help with cm3 problem before I deliver
	software	this week
In-Reply-To: <4892601C.1E75.00D7.1@scires.com>
References: <488F4292.1E75.00D7.1@scires.com>
	<20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com>
	<4890EB9C.1E75.00D7.1@scires.com> <4891BF18.8000905@wichita.edu>
	<4891A737.1E75.00D7.1@scires.com>
	<20080731184449.su7qkp9x6ocwkoo0@mail.elegosoft.com>
	<4892601C.1E75.00D7.1@scires.com>
Message-ID: <20080801175907.irr4cv7jls0gokc0@mail.elegosoft.com>

Quoting Randy Coleburn <rcoleburn at scires.com>:

> Olaf:
>
> The problem reproduces every time on my system.  I've tried it on three
> different XP computers with same results every time.
>
> 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.
>
> 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.

Randy,

indeed your compiled program shows the strange behaviour. I'll add
my version as someone may be able to compare the linked objects and
see which are significantly different.

We can now be sure that it is indeed either a difference in the source
code or a difference in the code my and your compiler generate.
I haven't upgrade my Windows compiler for more than two months.
I'll try an upgrade of the core system later.

Regards,

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194

-------------- next part --------------
A non-text attachment was scrubbed...
Name: formsedit.exe.gz
Type: application/gzip
Size: 746259 bytes
Desc: not available
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/03eb6d8b/attachment-0002.bin>

From rcoleburn at scires.com  Fri Aug  1 18:06:31 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Fri, 01 Aug 2008 12:06:31 -0400
Subject: [M3devel] need help with cm3 problem	before	I	deliver	software
	this week
In-Reply-To: <COL101-W37A68B1566CAAAF8791DBFE67F0@phx.gbl>
References: <537778.13498.qm@web27107.mail.ukl.yahoo.com>
	<464840.85424.qm@web27104.mail.ukl.yahoo.com>
	<48925C6D.1E75.00D7.1@scires.com>
	<COL101-W5623694736FE1A45441C7EE67F0@phx.gbl>
	<COL101-W5340B42054B530082445DCE67F0@phx.gbl><COL101-W5340B42054B530082445DCE67F0@phx.gbl>
	<COL101-W37A68B1566CAAAF8791DBFE67F0@phx.gbl>
Message-ID: <4892FC3F.1E75.00D7.1@scires.com>

Jay:
 
I have checked my Reactor v4.1 distribution and the problem also reproduces there as well, so this is not something new, its been around awhile.  I guess my memory must be failing that I don't remember this bug.  In any event, my customer is not happy, so I have to try and fix this and the pixmap problem.
 
I've returned back home from the customer site.  They have given me two weeks to fix these problems and to make some enhancements they want in the product before it is released to the end users.  So, that is my time interval--I've got 2 weeks max to fix everything.  The customer is not going to accept the product if I can't fix the cursor movement typein problem.  They don't like the pixmap problem, but since it is a non-functional issue, they will have to accept the defect if I can't fix it.  So, number one priority is to get the typein at cursor issue solved.
 
Note that this problem seems to reproduce in all FormsVBT places where you can type text, even in numerics.  Thus, it is a real problem.  My product uses several windows that have fields where the user has to type to change values.  In every case, when you click the mouse and also use the arrow keys, the first character typed goes to the wrong place.  I guess I never observed this because I always clicked the mouse to the exact place I wanted and didn't use the arrow keys.
 
Jay, you mention something about changing the TextPort model and ask "is this actually your bug, or just indicative of it"?  I'm not sure exactly what you are asking me, so if you will clarify your question, I'll try to give a better answer.  I don't think switching the TextPortModel will have a bearing on the problem I am having.
 
I have to leave now for a family reunion event, so I won't have email access again until late Sunday.  When I get back, I'll try to send a short program to demonstrate the pixmap problem, but then I'm not sure you can reproduce it unless you can set your screen resolution to 1920x1200.  At a minimum, I'll try and capture some screen images to show the difference in the same window when run at the various resolutions.
 
Thanks for your assistance in helping track down this problem.
 
Regards,
Randy

>>> Jay <jayk123 at hotmail.com> 8/1/2008 11:28 AM >>>
Clarification: there are other changes.
There was a change in font stuff.
There was added batching of painting.
And more.
 
I'm still stumped. I have to be away from this for a few hours or all day.
I think seeing if 4.1 repros will be good, and then maybe widen the net on either a) what changed (not just trestle?) and b) debugging it.
Really it shouldn't be hard..to figure how out it decides where to place the character.
 
Oh, and save the text file, see if it is in memory and on disk where it is drawn on the screen.
That would be useful to know.
 
ok..the text matches the display.
 
I can roll Wintrestle.i3 back to cm3.6, still repros.
 
Ok, the reason it is platform specific is because of:
 
Searching for 'TextPortModel: TEXT := "'...
C:\dev2\cm3.2\m3-ui\vbtkit\src\vbtkitutils\POSIX\VBTKitEnv.i3(30):  TextPortModel: TEXT := "emacs";
C:\dev2\cm3.2\m3-ui\vbtkit\src\vbtkitutils\WIN32\VBTKitEnv.i3(30):  TextPortModel: TEXT := "mac";

If you change Windows the the emacs model, no repro.
So try Posix to mac model, hopefully it repros.
 
Ok, Randy, is this actually your bug, or just indicative of it?
 
 - Jay



From: jayk123 at hotmail.com 
To: rcoleburn at scires.com; rodney.bates at wichita.edu; dabenavidesd at yahoo.es 
Date: Fri, 1 Aug 2008 14:45:02 +0000
CC: m3devel at elegosoft.com 
Subject: Re: [M3devel] need help with cm3 problem before I deliver software this week

 > It works ok with 3.6..

 
a *quick* and *incomplete* survey of 3.6 vs. current shows:
  - deal with change in Text type (platform independent) 
  - handle WM_CHAR (windows specific) 
  - handle newlines differently (platform independly, except maybe the data varies per platform) 

 I tried undoing the last two, still no luck.
 The first is harder to undo, maybe "impossible", just have to read/debug it and decide it is ok or not..?

 Next easy step is probably to see if repros with 4.1,
  and then proceed with comparing the "closer" repro vs. non-repro.
  If it does not repro with 4.1, and newer releases are available
  between it and current -- e.g. 5.2 -- would be good to narrow
  down when it started happening and compare those source trees.

The code in question is stuff like mtext and textport.

There are functions named key or Key or mouse or Mouse. Those are also important to look at, I think.

Not being particularly close to figuring this out, consider ignoring everything I have said. :)

It is hard to pass up such a simple repro. :)
And the knowledge that 3.6 works, and really not much has changed in the intervening ~12 years..

Oh, and there are pixmap changes.
Randy, I glossed over the mail about pixmaps.
You have a simple repro of that?
You can try it with 3.6?

3.6 should still be readily downloadable from the web, and it really isn't
difficult to get it up and running, at least on Windows.
(I can't speak for Linux. I ran 3.6, albeit hardly at all, on Linux 1.2 I think it was,
and NT 3.51, maybe later NT and maybe Win9x)
(and 3.6 is liberally licensed, so anyone can send it around.
The notion that 5.1 was the open source release always sounded wrong...)

 - Jay





From: jayk123 at hotmail.com 
To: rcoleburn at scires.com; rodney.bates at wichita.edu; dabenavidesd at yahoo.es 
CC: m3devel at elegosoft.com 
Subject: RE: [M3devel] need help with cm3 problem before I deliver software this week
Date: Fri, 1 Aug 2008 14:06:45 +0000

It works ok with 3.6..


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/811dfc2d/attachment-0002.html>

From rcoleburn at scires.com  Fri Aug  1 18:29:38 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Fri, 01 Aug 2008 12:29:38 -0400
Subject: [M3devel] need help with cm3 problem before I
	deliver	software	this week
In-Reply-To: <20080801175907.irr4cv7jls0gokc0@mail.elegosoft.com>
References: <488F4292.1E75.00D7.1@scires.com>
	<20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com>
	<4890EB9C.1E75.00D7.1@scires.com> <4891BF18.8000905@wichita.edu>
	<4891A737.1E75.00D7.1@scires.com>
	<20080731184449.su7qkp9x6ocwkoo0@mail.elegosoft.com>
	<4892601C.1E75.00D7.1@scires.com>
	<20080801175907.irr4cv7jls0gokc0@mail.elegosoft.com>
Message-ID: <489301AA.1E75.00D7.1@scires.com>

Olaf:
 
I tested your version of formsedit on my computer and it works
correctly.
 
This is a big clue I think.  We now have the same program built on two
different machines.  One works well and one has a bug.  The bug
manifests on both systems using same EXE, so we can rule out a
difference in the computer causing the bug to manifest.  Thus, there
must be either (1) a difference in the source code base, OR (2) a
difference in the way the EXE is produced.
 
If we could compare the two source trees and find them identical, then
the problem could be traced to #2.  If the sources differ, the problem
could still be #2, but more likely would be #1.
 
Would it make sense for me to make a tar gzip file of my cm3 source
tree and send to you for compare?  Alternately, you could make the
tarball and send to me for compare with my source tree.
 
Regards,
Randy

>>> Olaf Wagner <wagner at elegosoft.com> 8/1/2008 11:59 AM >>>
Quoting Randy Coleburn <rcoleburn at scires.com>:

> Olaf:
>
> The problem reproduces every time on my system.  I've tried it on
three
> different XP computers with same results every time.
>
> 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.
>
> 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.

Randy,

indeed your compiled program shows the strange behaviour. I'll add
my version as someone may be able to compare the linked objects and
see which are significantly different.

We can now be sure that it is indeed either a difference in the source
code or a difference in the code my and your compiler generate.
I haven't upgrade my Windows compiler for more than two months.
I'll try an upgrade of the core system later.

Regards,

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin,
Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45
86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz:
Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:
DE163214194

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/ead69b46/attachment-0002.html>

From wagner at elegosoft.com  Fri Aug  1 19:33:11 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Fri, 01 Aug 2008 19:33:11 +0200
Subject: [M3devel] need help with cm3 problem before I deliver
	software	this week
In-Reply-To: <489301AA.1E75.00D7.1@scires.com>
References: <488F4292.1E75.00D7.1@scires.com>
	<20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com>
	<4890EB9C.1E75.00D7.1@scires.com> <4891BF18.8000905@wichita.edu>
	<4891A737.1E75.00D7.1@scires.com>
	<20080731184449.su7qkp9x6ocwkoo0@mail.elegosoft.com>
	<4892601C.1E75.00D7.1@scires.com>
	<20080801175907.irr4cv7jls0gokc0@mail.elegosoft.com>
	<489301AA.1E75.00D7.1@scires.com>
Message-ID: <20080801193311.cr577vkk8cw88w4s@mail.elegosoft.com>

Quoting Randy Coleburn <rcoleburn at scires.com>:

> Olaf:
>
> I tested your version of formsedit on my computer and it works
> correctly.
>
> This is a big clue I think.  We now have the same program built on two
> different machines.  One works well and one has a bug.  The bug
> manifests on both systems using same EXE, so we can rule out a
> difference in the computer causing the bug to manifest.  Thus, there
> must be either (1) a difference in the source code base, OR (2) a
> difference in the way the EXE is produced.
>
> If we could compare the two source trees and find them identical, then
> the problem could be traced to #2.  If the sources differ, the problem
> could still be #2, but more likely would be #1.
>
> Would it make sense for me to make a tar gzip file of my cm3 source
> tree and send to you for compare?  Alternately, you could make the
> tarball and send to me for compare with my source tree.

In the meantime I have updated my core system on Windows (m3-sys and
m3-libs and performed scripts/upgrade.sh) and rebuilt all the GUI
sources (they were already up-to-date). Now I can reproduce the problem.
So something must definitely been broken in the recent months.

Of course I saved all the old sources and binaries before, so I am now
able to compare them. There have been quite a lot of changes though,
so it may take a while. I don't think it is necessary that you send
me your sources now. I'll let you know what I find.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From wagner at elegosoft.com  Fri Aug  1 22:15:51 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Fri, 01 Aug 2008 22:15:51 +0200
Subject: [M3devel] need help with cm3 problem before I deliver
	software	this week
In-Reply-To: <489301AA.1E75.00D7.1@scires.com>
References: <488F4292.1E75.00D7.1@scires.com>
	<20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com>
	<4890EB9C.1E75.00D7.1@scires.com> <4891BF18.8000905@wichita.edu>
	<4891A737.1E75.00D7.1@scires.com>
	<20080731184449.su7qkp9x6ocwkoo0@mail.elegosoft.com>
	<4892601C.1E75.00D7.1@scires.com>
	<20080801175907.irr4cv7jls0gokc0@mail.elegosoft.com>
	<489301AA.1E75.00D7.1@scires.com>
Message-ID: <20080801221551.padpgo9q4gsssgsk@mail.elegosoft.com>

Quoting Randy Coleburn <rcoleburn at scires.com>:

> Olaf:
>
> I tested your version of formsedit on my computer and it works
> correctly.
>
> This is a big clue I think.  We now have the same program built on two
> different machines.  One works well and one has a bug.  The bug
> manifests on both systems using same EXE, so we can rule out a
> difference in the computer causing the bug to manifest.  Thus, there
> must be either (1) a difference in the source code base, OR (2) a
> difference in the way the EXE is produced.
>
> If we could compare the two source trees and find them identical, then
> the problem could be traced to #2.  If the sources differ, the problem
> could still be #2, but more likely would be #1.

After I first had problems to reproduce the problem, I now seem unable
to make it disappear again. I saved all sources and executables
(cm3 installation, m3-libs, m3-sys) before I did a cvs update and
upgrade on them (after which the problem showed up), but moving back
the old sources and compiler produces the same failure still.

I'm at a complete loss right now. Perhaps we really need to compare
the linked objects in both the working and broken executable after all :-/
I seem unable to narrow down the faulting component.

Perhaps I need something to eat and then some sleep...

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From jayk123 at hotmail.com  Sat Aug  2 03:18:40 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 2 Aug 2008 01:18:40 +0000
Subject: [M3devel] formsedit/pixmap bugs
In-Reply-To: <20080801221551.padpgo9q4gsssgsk@mail.elegosoft.com>
References: <488F4292.1E75.00D7.1@scires.com>
	<20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com>
	<4890EB9C.1E75.00D7.1@scires.com> <4891BF18.8000905@wichita.edu>
	<4891A737.1E75.00D7.1@scires.com>
	<20080731184449.su7qkp9x6ocwkoo0@mail.elegosoft.com>
	<4892601C.1E75.00D7.1@scires.com>
	<20080801175907.irr4cv7jls0gokc0@mail.elegosoft.com>
	<489301AA.1E75.00D7.1@scires.com> 
	<20080801221551.padpgo9q4gsssgsk@mail.elegosoft.com>
Message-ID: <COL101-W16F4A874630C2E5F5A76CEE67E0@phx.gbl>


Darnit I realized what I should have quickly checked for before disappearing for a few hours.
(and darnit, did anyone else look at any code?)


The bug is in 3.6, essentially.
Anyone have anything older?
I think older might be readily available, but I also think 3.6 might be the first version with a Win32 Trestle, declared experimental at that.


3.6:
Searching for 'TextPortModel'...
D:\modula-3\src\vbtkit\src\vbtkitutils\VBTKitEnv.i3(30):  TextPortModel: TEXT := "emacs";
D:\modula-3\src\vbtkit\src\vbtkitutils\VBTKitEnv.m3(27):      IF Text.Equal (s, "ivy") THEN TextPortModel := "ivy" 
D:\modula-3\src\vbtkit\src\vbtkitutils\VBTKitEnv.m3(28):      ELSIF Text.Equal (s, "mac") THEN TextPortModel := "mac" 
D:\modula-3\src\vbtkit\src\vbtkitutils\VBTKitEnv.m3(29):      ELSIF Text.Equal (s, "xterm") THEN TextPortModel := "xterm"


The environment variable being checked for in the last lines didn't seem to work.
So I fiddled with the first line directly.
Change it to "mac" and it repros with 3.6.


Short term fix:
  Change the default to emacs for all platforms.


After that:
 Fix the mac model.


This is all related to how selection works.
Like if I select text, and then type, does the selected text get wholly replaced (mac) or does something wierd happen (emacs).
Or something like that.
"Model" is a plugin to "TextPort" that varies some of the behavior.
I only first heard of this this morning, skimming the code


If anyone can show me it *working* with the mac model in any version, I'm slightly interested.
Really we should just focus on MacModel.m3 and fix it, for the first time.
The problem is narrowed down enough, that it should be easy.


Please make the pixmap bug clear to me. I've only skimmed and I have noticed no description at all of the bug.
Just that there is a problem with pixmaps.
There was churn here between 3.6 and current.
Please test with 3.6 and/or 4.1 if you can.


I assume the "formsedit" bug is bad behavior in various "text fields" in a gui.
Formsedit is just one user of that -- of TextPort.


 - Jay

From jayk123 at hotmail.com  Sat Aug  2 03:39:34 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 2 Aug 2008 01:39:34 +0000
Subject: [M3devel] formsedit/pixmap bugs
In-Reply-To: <COL101-W16F4A874630C2E5F5A76CEE67E0@phx.gbl>
References: <488F4292.1E75.00D7.1@scires.com>
	<20080730082411.dnbz6t4n8k8kccog@mail.elegosoft.com>
	<4890EB9C.1E75.00D7.1@scires.com> <4891BF18.8000905@wichita.edu>
	<4891A737.1E75.00D7.1@scires.com>
	<20080731184449.su7qkp9x6ocwkoo0@mail.elegosoft.com>
	<4892601C.1E75.00D7.1@scires.com>
	<20080801175907.irr4cv7jls0gokc0@mail.elegosoft.com>
	<489301AA.1E75.00D7.1@scires.com> 
	<20080801221551.padpgo9q4gsssgsk@mail.elegosoft.com> 
	<COL101-W16F4A874630C2E5F5A76CEE67E0@phx.gbl>
Message-ID: <COL101-W71F979196B1C29448A15C2E67E0@phx.gbl>


Duh, it's obvious why the environment variable didn't work.
 
You can now revert to the "working" 3.6 behavior by setting the environment variable TEXTPORTMODEL=emacs.
It already supported TEXTPORTMODEL=mac, TEXTPORTMODEL=ivy, TEXTPORTMODEL=and xterm, and defaulted to emacs on Posix, but defaults to mac on Win32, without enabling getting the emacs mode.
3.6 defaulted to emacs for all platforms, that's why 3.6 "worked".
 
The mac model should still be fixed.
 
Some of the relevant files are:
 
D:\modula-3\src>dir /s/b *model*3D:\modula-3\src\vbtkit\src\etext\EmacsModel.i3D:\modula-3\src\vbtkit\src\etext\EmacsModel.m3D:\modula-3\src\vbtkit\src\etext\IvyModel.i3D:\modula-3\src\vbtkit\src\etext\IvyModel.m3D:\modula-3\src\vbtkit\src\etext\MacModel.i3D:\modula-3\src\vbtkit\src\etext\MacModel.m3D:\modula-3\src\vbtkit\src\etext\XtermModel.i3D:\modula-3\src\vbtkit\src\etext\XtermModel.m3
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080802/f17547df/attachment-0002.html>

From rcoleburn at scires.com  Sat Aug  2 05:18:56 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Fri, 01 Aug 2008 23:18:56 -0400
Subject: [M3devel] screen shots of pixmap problem
Message-ID: <489399D1.1E75.00D7.1@scires.com>

I managed to get the customer to grab a few screen images that illustrate the pixmap problem we are having.  These screen shots supplied by the customer don't show the full extent of the pixmap problem, but I do think they show the basic issues.  Quality of the bitmaps isn't great, but I think it illustrates the problem.  
 
I think my whole application is fairly sophisticated in its use of Trestle/FormsVBT.  After the delivery, I'll try to provide the community with a portfolio of pictures we can add to the web site to show the capability of Trestle/FormsVBT.
 
The attached ZIP file contains the following files:
1.  splash_1440.bmp = the startup splash screen bitmap viewed at 1440x900 resolution.
 
2.  splash_1920.bmp = same bitmap as #1, but viewed at 1920x1200 resolution.  It is huge compared to #1.  Normally, when you increase resolution on the same screen, the images get smaller, but this time they get larger.
 
3.  aoi_1440.bmp = one of the windows viewed at 1440x900 resolution.
 
4.  aoi_1920.bmp = same window viewed at 1920x1200 resolution.  Notice that the black triangles in front of Polygon and Minutes are huge.  The text seems to be scaling fine, but the bitmaps are scaling much larger to be out of proportion with the text.  Also notice that the choice radio buttons in the Coordinates block are enlarged out of proportion.  If you look at the numeric in the lower right corner you will notice that the numeric text is elevated in the pixmap background rather than centered.  This is because the pixmap has been enlarged.  
 
Hope these screen shots help illustrate the types of problems I am having.  I have another window that has a number of Boolean choice boxes on it.  When you go to 1920x1200 these boolean pixmaps get enlarged so much that the window won't fit vertically on the screen anymore.  The OK, Close, Cancel buttons actually show off the screen, so the user can't even complete the interaction.  This same window at 1440x900 or lower looks fine and fits on the screen with no issue.
 
Any insight folks can supply on how to resolve this issue would be appreciated.
 
Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/831cb092/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pics.zip
Type: application/x-zip-compressed
Size: 419491 bytes
Desc: not available
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080801/831cb092/attachment-0002.bin>

From jayk123 at hotmail.com  Tue Aug  5 13:40:12 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 5 Aug 2008 11:40:12 +0000
Subject: [M3devel] formsediit/macmodel problem
Message-ID: <COL101-W272B732C79E4B4AD2F0202E67B0@phx.gbl>


That's better, thanks!
I still have little idea what is going on here.
I can test it out a bit, can't vouch for it via code review,
at least not yet.

If you have multiple lines, of varying lengths..
not sure if this is due to word wrap or not,
and click in empty space past the end of one of the lines
and type, letters do not appear.

If you click at the end of the line ok.
I think clicking past the end of the line needs to pin the resulting
cursor location to the end of the line.

 I really don't know this code. :(
I think it was written by people who had implemented the same
things multiple times and by this time had all exactly in their head
just how to factor it perfectly for the right amount of flexibility.
"Right amount of flexibility" => "harder for newbies to understand.." :(
I need to read the green book and pay close attn the whole time. :)

I still get a sort of stray looking vertical red line when I first type after clicking.
But it can be deemed minor (depending on Randy's customer really).
Probably should focus on the pixmap problem.
Can I repro it on one machine???

Randy, you might want to try out the "emacs" model, perhaps it is better tested
and works ok. ?

 - Jay



> Date: Sun, 3 Aug 2008 11:44:54 +0000
> To: m3commit at elegosoft.com
> From: wagner at elego.de
> Subject: [M3commit] CVS Update: cm3
>
> CVSROOT: /usr/cvs
> Changes by: wagner at birch. 08/08/03 11:44:54
>
> Modified files:
> cm3/m3-ui/vbtkit/src/: m3overrides
> cm3/m3-ui/vbtkit/src/etext/: MacModel.m3 TextPort.m3
>
> Log message:
> tentative fix for text selection and insertion in the Mac TextPortModel:
>
> The strange behaviour reported by Randy Coleburn (mouse click, left, left,
> insert --> first character inserted at mouse click point) should now be gone;
> cursor up and down at the right end of ragged paragraphs still looks
> a bit strange, but that seems to be not worse than before. It still
> should be fixed though.
>
> These changes should be reviewed and tested by others; they seem to do
> the right thing for me, but I haven't done extensive testing, especially
> in other modes.
>


From wagner at elegosoft.com  Tue Aug  5 14:05:40 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 05 Aug 2008 14:05:40 +0200
Subject: [M3devel] formsediit/macmodel problem
In-Reply-To: <COL101-W272B732C79E4B4AD2F0202E67B0@phx.gbl>
References: <COL101-W272B732C79E4B4AD2F0202E67B0@phx.gbl>
Message-ID: <20080805140540.16dyn3kxc04ogkww@mail.elegosoft.com>

Quoting Jay <jayk123 at hotmail.com>:

> That's better, thanks!
> I still have little idea what is going on here.
> I can test it out a bit, can't vouch for it via code review,
> at least not yet.
>
> If you have multiple lines, of varying lengths..
> not sure if this is due to word wrap or not,
> and click in empty space past the end of one of the lines
> and type, letters do not appear.

Yes, the end-of-line behaviour is strange.

> If you click at the end of the line ok.
> I think clicking past the end of the line needs to pin the resulting
> cursor location to the end of the line.
>
>  I really don't know this code. :(

I doubt there is somebody around in our community who really does ;-)

> I think it was written by people who had implemented the same
> things multiple times and by this time had all exactly in their head
> just how to factor it perfectly for the right amount of flexibility.
> "Right amount of flexibility" => "harder for newbies to understand.." :(
> I need to read the green book and pay close attn the whole time. :)
>
> I still get a sort of stray looking vertical red line when I first   
> type after clicking.
> But it can be deemed minor (depending on Randy's customer really).
> Probably should focus on the pixmap problem.
> Can I repro it on one machine???
>
> Randy, you might want to try out the "emacs" model, perhaps it is   
> better tested
> and works ok. ?

I doubt that anybody used to working on Windows or Apple would like
to use the Emacs model...

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From hosking at cs.purdue.edu  Tue Aug  5 15:38:18 2008
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 5 Aug 2008 09:38:18 -0400
Subject: [M3devel] formsediit/macmodel problem
In-Reply-To: <20080805140540.16dyn3kxc04ogkww@mail.elegosoft.com>
References: <COL101-W272B732C79E4B4AD2F0202E67B0@phx.gbl>
	<20080805140540.16dyn3kxc04ogkww@mail.elegosoft.com>
Message-ID: <109A2D6C-1849-4F77-8323-B55A97D5BB92@cs.purdue.edu>

I use emacs bindings all the time on OS X (it tends to support them in  
most apps).

On Aug 5, 2008, at 8:05 AM, Olaf Wagner wrote:

> Quoting Jay <jayk123 at hotmail.com>:
>
>> That's better, thanks!
>> I still have little idea what is going on here.
>> I can test it out a bit, can't vouch for it via code review,
>> at least not yet.
>>
>> If you have multiple lines, of varying lengths..
>> not sure if this is due to word wrap or not,
>> and click in empty space past the end of one of the lines
>> and type, letters do not appear.
>
> Yes, the end-of-line behaviour is strange.
>
>> If you click at the end of the line ok.
>> I think clicking past the end of the line needs to pin the resulting
>> cursor location to the end of the line.
>>
>> I really don't know this code. :(
>
> I doubt there is somebody around in our community who really does ;-)
>
>> I think it was written by people who had implemented the same
>> things multiple times and by this time had all exactly in their head
>> just how to factor it perfectly for the right amount of flexibility.
>> "Right amount of flexibility" => "harder for newbies to  
>> understand.." :(
>> I need to read the green book and pay close attn the whole time. :)
>>
>> I still get a sort of stray looking vertical red line when I first   
>> type after clicking.
>> But it can be deemed minor (depending on Randy's customer really).
>> Probably should focus on the pixmap problem.
>> Can I repro it on one machine???
>>
>> Randy, you might want to try out the "emacs" model, perhaps it is   
>> better tested
>> and works ok. ?
>
> I doubt that anybody used to working on Windows or Apple would like
> to use the Emacs model...
>
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>               Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin,  
> Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23  
> 45 86 95
>   http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz:  
> Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:  
> DE163214194
>



From jayk123 at hotmail.com  Tue Aug  5 15:01:54 2008
From: jayk123 at hotmail.com (Jay)
Date: Tue, 5 Aug 2008 13:01:54 +0000
Subject: [M3devel] pixmap problem
Message-ID: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>



Randy, I'm pretty clueless here.
I don't do gui or graphics.
If anyone has a clue, please stand up.
If you can get us code to run, please do.
But I think I need multiple particularly configured machines too.

I'm curious what this code prints on the systems:

#include
#include

int main()
{
int pix_ver = { 0 };
int pix_hor = { 0 };
int mm_hor = { 0 };
int mm_ver = { 0 };
HWND hwnd = { 0 };
HDC hdc = { 0 };

hwnd = GetDesktopWindow();
hdc = GetDC(hwnd);
mm_hor = GetDeviceCaps(hdc, HORZSIZE);
mm_ver = GetDeviceCaps(hdc, VERTSIZE);
pix_hor = GetSystemMetrics(SM_CXSCREEN);
pix_ver = GetSystemMetrics(SM_CYSCREEN);

printf("horizonal pixels %d\n", pix_hor);
printf("veritical pixels SM_CYSCREEN %d\n", pix_ver);
printf("horizontal millimeters %d\n", mm_hor);
printf("veritical millimeters %d\n", mm_ver);

printf("horizontal pixels per millimeter %f\n", (((float) pix_hor) / ((float) mm_hor)));
printf("vertical pixels per millimeter %f\n", (((float) pix_ver) / ((float) mm_ver)));

printf("horizontal pixels per inch %f\n", (((float) pix_hor) / ((float) mm_hor) * 10.0 * 2.54));
printf("vertical pixels per inch %f\n", (((float) pix_ver) / ((float) mm_ver) * 10.0 * 2.54));

return 0;
}


for me:

$ gcc dpi.c -luser32 -lgdi32

jay at jay-win9 /dev2/j/dpi
$ ./a
horizonal pixels 1280
veritical pixels SM_CYSCREEN 800
horizontal millimeters 384
veritical millimeters 240
horizontal pixels per millimeter 3.333333
vertical pixels per millimeter 3.333333
horizontal pixels per inch 84.666667
vertical pixels per inch 84.666667

(Visual C++ is fine:
cl dpi.c user32.lib gdi32.lib
.\dpi
)

I wonder if lying in this code:

Searching for 'GetDeviceCaps'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(25): VAR res := NEW(T); n_colors := GetDeviceCaps (WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(32): res.depth := GetDeviceCaps(WinGDI.BITSPIXEL); (* John Karnak 8/3/98 *)
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(68): mm_hor = GetDeviceCaps (WinGDI.HORZSIZE),
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(69): mm_ver = GetDeviceCaps (WinGDI.VERTSIZE) DO

Searching for 'res.res[Axis.T.'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(71): res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(72): res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);


D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(89):PROCEDURE GetDeviceCaps (cap: Ctypes.int): INTEGER =
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(93): res := WinGDI.GetDeviceCaps (hdc, cap);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(98): END GetDeviceCaps;
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnColorMap.m3(268): cnt := WinGDI.GetDeviceCaps (hdc, WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnFont.m3(316): LogicalPixelsPerVertInch := WinGDI.GetDeviceCaps(er.hdc, WinGDI.LOGPIXELSY);
9 occurrence(s) have been found.


Searching for '1000.0'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(463): bmih.biXPelsPerMeter := ROUND (st.res[Axis.T.Hor] * 1000.0);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(464): bmih.biYPelsPerMeter := ROUND (st.res[Axis.T.Ver] * 1000.0);


and just claiming 96dpi is the way to go.
Can you try that??


Specifically try setting res.res[Axis.T.Hor] and .Ver to 3.779527559055118.
Or heck to 3.3333 like my laptop has.


Or maybe claiming ignorance and setting biXPelsPerMeter and biYPelsPerMeter to 0???
Claiming ignorance feels better than lying of course. :)

Hm, so throw in also:

printf("LogicalPixelsX %u\n", GetDeviceCaps(hdc, LOGPIXELSX));
printf("LogicalPixelsY %u\n", GetDeviceCaps(hdc, LOGPIXELSY));

I get the magic number 96.

- Jay
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dpi.c
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080805/2ec540e4/attachment-0002.c>

From dabenavidesd at yahoo.es  Tue Aug  5 15:02:28 2008
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Tue, 5 Aug 2008 13:02:28 +0000 (GMT)
Subject: [M3devel] screen shots of pixmap problem
In-Reply-To: <489399D1.1E75.00D7.1@scires.com>
Message-ID: <46113.94040.qm@web27103.mail.ukl.yahoo.com>

Dear Randy:
Could you try to check (with cm3ide)
http://localhost:3800/public/vbtkit/src/lego/Image.i3/Raw#_DECL_ (or just on cm3/m3-ui/vbtkit/src/lego/Image.i3 )
see that line 43 has 
xres, yres: REAL := 75.0; (* in pixels per inch *) 
which is set from the sourcecode (not from the runtime variables).
you can calulate with 1920x1200 screen resolution pixels per inch
first, you apply pythogorean theorem with both catets 
Dp=sqrt(Wp^2+Wh^2)
Then PPI(or Pixels Per inch)=Dp/Di
where Di is the diagonal size in inches (the screen size), as Wikipedia says:
http://en.wikipedia.org/wiki/Pixels_per_inch
?In my case a SyncMaster 753DFX the PPI=96.42351792840054493 (Iguess the monitor you have should have more, rigth?). So you should fixed if needed the PPI rate in the source code or maybe use another variable that has the correct value.

I hope this helps, let me know
Thanks


--- El vie, 1/8/08, Randy Coleburn <rcoleburn at scires.com> escribi?:
De: Randy Coleburn <rcoleburn at scires.com>
Asunto: [M3devel] screen shots of pixmap problem
Para: m3devel at elegosoft.com
Fecha: viernes, 1 agosto, 2008 10:18


 
I managed to get the customer to grab a few screen images that illustrate the pixmap problem we are having.? These screen shots supplied by the customer don't show the full extent of the pixmap problem, but I do think they show the basic issues.? Quality of the bitmaps isn't great, but I think it illustrates the problem.? 
?
I think my whole application is fairly sophisticated in its use of Trestle/FormsVBT.? After the delivery, I'll try to provide the community with a portfolio of pictures we can add to the web site to show the capability of Trestle/FormsVBT.
?
The attached ZIP file contains the following files:
1.? splash_1440.bmp = the startup splash screen bitmap viewed at 1440x900 resolution.
?
2.? splash_1920.bmp = same bitmap as #1, but viewed at 1920x1200 resolution.? It is huge compared to #1.? Normally, when you increase resolution on the same screen, the images get smaller, but this time they get larger.
?
3.? aoi_1440.bmp = one of the windows viewed at 1440x900 resolution.
?
4.? aoi_1920.bmp = same window viewed at 1920x1200 resolution.? Notice that the black triangles in front of Polygon and Minutes are huge.? The text seems to be scaling fine, but the bitmaps are scaling much larger to be out of proportion with the text.? Also notice that the choice radio buttons in the Coordinates block are enlarged out of proportion.? If you look at the numeric in the lower right corner you will notice that the numeric text is elevated in the pixmap background rather than centered.? This is because the pixmap has been enlarged.? 
?
Hope these screen shots help illustrate the types of problems I am having.? I have another window that has a number of Boolean choice boxes on it.? When you go to 1920x1200 these boolean pixmaps get enlarged so much that the window won't fit vertically on the screen anymore.? The OK, Close, Cancel buttons actually show off the screen, so the user can't even complete the interaction.? This same window at 1440x900 or lower looks fine and fits on the screen with no issue.
?
Any insight folks can supply on how to resolve this issue would be appreciated.
?
Regards,
Randy


      ______________________________________________ 
Enviado desde Correo Yahoo! La bandeja de entrada m?s inteligente.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080805/054f3fd5/attachment-0002.html>

From rcoleburn at scires.com  Tue Aug  5 16:00:54 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Tue, 05 Aug 2008 10:00:54 -0400
Subject: [M3devel] screen shots of pixmap problem
In-Reply-To: <46113.94040.qm@web27103.mail.ukl.yahoo.com>
References: <489399D1.1E75.00D7.1@scires.com>
	<46113.94040.qm@web27103.mail.ukl.yahoo.com>
Message-ID: <489824D0.1E75.00D7.1@scires.com>

Daniel:
 
Thanks, I will check this out today.
 
In my experience, the normal dpi setting on most all Windows computers
is 96 dpi.  If the source is fixing it at 75 dpi, that would be a
problem.
 
Regards,
Randy

>>> "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es> 8/5/2008
9:02 AM >>>

Dear Randy:
Could you try to check (with cm3ide)
http://localhost:3800/public/vbtkit/src/lego/Image.i3/Raw#_DECL_ (or
just on cm3/m3-ui/vbtkit/src/lego/Image.i3 )
see that line 43 has 
xres, yres: REAL := 75.0; (* in pixels per inch *) 
which is set from the sourcecode (not from the runtime variables).
you can calulate with 1920x1200 screen resolution pixels per inch
first, you apply pythogorean theorem with both catets 
Dp=sqrt(Wp^2+Wh^2)
Then PPI(or Pixels Per inch)=Dp/Di
where Di is the diagonal size in inches (the screen size), as Wikipedia
says:
http://en.wikipedia.org/wiki/Pixels_per_inch 
 In my case a SyncMaster 753DFX the PPI=96.42351792840054493 (Iguess
the monitor you have should have more, rigth?). So you should fixed if
needed the PPI rate in the source code or maybe use another variable
that has the correct value.

I hope this helps, let me know
Thanks


--- El vie, 1/8/08, Randy Coleburn <rcoleburn at scires.com> escribi?:


De: Randy Coleburn <rcoleburn at scires.com>
Asunto: [M3devel] screen shots of pixmap problem
Para: m3devel at elegosoft.com 
Fecha: viernes, 1 agosto, 2008 10:18

I managed to get the customer to grab a few screen images that
illustrate the pixmap problem we are having.  These screen shots
supplied by the customer don't show the full extent of the pixmap
problem, but I do think they show the basic issues.  Quality of the
bitmaps isn't great, but I think it illustrates the problem.  
 
I think my whole application is fairly sophisticated in its use of
Trestle/FormsVBT.  After the delivery, I'll try to provide the community
with a portfolio of pictures we can add to the web site to show the
capability of Trestle/FormsVBT.
 
The attached ZIP file contains the following files:
1.  splash_1440.bmp = the startup splash screen bitmap viewed at
1440x900 resolution.
 
2.  splash_1920.bmp = same bitmap as #1, but viewed at 1920x1200
resolution.  It is huge compared to #1.  Normally, when you increase
resolution on the same screen, the images get smaller, but this time
they get larger.
 
3.  aoi_1440.bmp = one of the windows viewed at 1440x900 resolution.
 
4.  aoi_1920.bmp = same window viewed at 1920x1200 resolution.  Notice
that the black triangles in front of Polygon and Minutes are huge.  The
text seems to be scaling fine, but the bitmaps are scaling much larger
to be out of proportion with the text.  Also notice that the choice
radio buttons in the Coordinates block are enlarged out of proportion. 
If you look at the numeric in the lower right corner you will notice
that the numeric text is elevated in the pixmap background rather than
centered.  This is because the pixmap has been enlarged.  
 
Hope these screen shots help illustrate the types of problems I am
having.  I have another window that has a number of Boolean choice boxes
on it.  When you go to 1920x1200 these boolean pixmaps get enlarged so
much that the window won't fit vertically on the screen anymore.  The
OK, Close, Cancel buttons actually show off the screen, so the user
can't even complete the interaction.  This same window at 1440x900 or
lower looks fine and fits on the screen with no issue.
 
Any insight folks can supply on how to resolve this issue would be
appreciated.
 
Regards,
Randy



Enviado desde Correo Yahoo! (
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
)
La bandeja de entrada m?s inteligente.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080805/4f349ebe/attachment-0002.html>

From rcoleburn at scires.com  Fri Aug  8 01:22:39 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Thu, 07 Aug 2008 19:22:39 -0400
Subject: [M3devel] pixmap problem
In-Reply-To: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>
References: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>
Message-ID: <489B4B79.1E75.00D7.1@scires.com>

Jay, I ran your program on a Lenovo/IBM ThinkPad T60 running at 1280x1024 resolution.  Here are the results:
 
horizonal pixels 1280
veritical pixels SM_CYSCREEN 1024
horizontal millimeters 375
veritical millimeters 300
horizontal pixels per millimeter 3.413333
vertical pixels per millimeter 3.413333
horizontal pixels per inch 86.698667
vertical pixels per inch 86.698667
 
I tried to run this program on the Dell M4300 system at 1920x1200, but I'm running into some stupid Microsoft problem.  I installed the VC_Redist, but it still doesn't work on this system.  Not sure what is wrong yet.
 
Regards,
Randy

>>> Jay <jayk123 at hotmail.com> 8/5/2008 9:01 AM >>>


Randy, I'm pretty clueless here.
I don't do gui or graphics.
If anyone has a clue, please stand up.
If you can get us code to run, please do.
But I think I need multiple particularly configured machines too.

I'm curious what this code prints on the systems:

#include
#include

int main()
{
int pix_ver = { 0 };
int pix_hor = { 0 };
int mm_hor = { 0 };
int mm_ver = { 0 };
HWND hwnd = { 0 };
HDC hdc = { 0 };

hwnd = GetDesktopWindow();
hdc = GetDC(hwnd);
mm_hor = GetDeviceCaps(hdc, HORZSIZE);
mm_ver = GetDeviceCaps(hdc, VERTSIZE);
pix_hor = GetSystemMetrics(SM_CXSCREEN);
pix_ver = GetSystemMetrics(SM_CYSCREEN);

printf("horizonal pixels %d\n", pix_hor);
printf("veritical pixels SM_CYSCREEN %d\n", pix_ver);
printf("horizontal millimeters %d\n", mm_hor);
printf("veritical millimeters %d\n", mm_ver);

printf("horizontal pixels per millimeter %f\n", (((float) pix_hor) / ((float) mm_hor)));
printf("vertical pixels per millimeter %f\n", (((float) pix_ver) / ((float) mm_ver)));

printf("horizontal pixels per inch %f\n", (((float) pix_hor) / ((float) mm_hor) * 10.0 * 2.54));
printf("vertical pixels per inch %f\n", (((float) pix_ver) / ((float) mm_ver) * 10.0 * 2.54));

return 0;
}


for me:

$ gcc dpi.c -luser32 -lgdi32

jay at jay-win9 /dev2/j/dpi
$ ./a
horizonal pixels 1280
veritical pixels SM_CYSCREEN 800
horizontal millimeters 384
veritical millimeters 240
horizontal pixels per millimeter 3.333333
vertical pixels per millimeter 3.333333
horizontal pixels per inch 84.666667
vertical pixels per inch 84.666667

(Visual C++ is fine:
cl dpi.c user32.lib gdi32.lib
.\dpi
)

I wonder if lying in this code:

Searching for 'GetDeviceCaps'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(25): VAR res := NEW(T); n_colors := GetDeviceCaps (WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(32): res.depth := GetDeviceCaps(WinGDI.BITSPIXEL); (* John Karnak 8/3/98 *)
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(68): mm_hor = GetDeviceCaps (WinGDI.HORZSIZE),
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(69): mm_ver = GetDeviceCaps (WinGDI.VERTSIZE) DO

Searching for 'res.res[Axis.T.'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(71): res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(72): res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);


D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(89):PROCEDURE GetDeviceCaps (cap: Ctypes.int): INTEGER =
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(93): res := WinGDI.GetDeviceCaps (hdc, cap);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(98): END GetDeviceCaps;
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnColorMap.m3(268): cnt := WinGDI.GetDeviceCaps (hdc, WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnFont.m3(316): LogicalPixelsPerVertInch := WinGDI.GetDeviceCaps(er.hdc, WinGDI.LOGPIXELSY);
9 occurrence(s) have been found.


Searching for '1000.0'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(463): bmih.biXPelsPerMeter := ROUND (st.res[Axis.T.Hor] * 1000.0);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(464): bmih.biYPelsPerMeter := ROUND (st.res[Axis.T.Ver] * 1000.0);


and just claiming 96dpi is the way to go.
Can you try that??


Specifically try setting res.res[Axis.T.Hor] and .Ver to 3.779527559055118.
Or heck to 3.3333 like my laptop has.


Or maybe claiming ignorance and setting biXPelsPerMeter and biYPelsPerMeter to 0???
Claiming ignorance feels better than lying of course. :)

Hm, so throw in also:

printf("LogicalPixelsX %u\n", GetDeviceCaps(hdc, LOGPIXELSX));
printf("LogicalPixelsY %u\n", GetDeviceCaps(hdc, LOGPIXELSY));

I get the magic number 96.

- Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080807/734b84fd/attachment-0002.html>

From jayk123 at hotmail.com  Fri Aug  8 01:33:09 2008
From: jayk123 at hotmail.com (Jay)
Date: Thu, 7 Aug 2008 23:33:09 +0000
Subject: [M3devel] pixmap problem
In-Reply-To: <489B4B79.1E75.00D7.1@scires.com>
References: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>
	<489B4B79.1E75.00D7.1@scires.com>
Message-ID: <COL101-W61DE171DBB93FC8E684658E6750@phx.gbl>


Randy, this might be useful, or it might be yanking your chain and wasting your time. I don't know.


Please try this:

Run my C code on "both" machines/settings, one that looks right, one that looks wrong.
Actually I'm not going to use that data as far as I can figure now, but I am curious.
Look at the Modula-3 code I showed, like where GetDeviceCaps is called.
Try out some hardcoded values.
See what the effect is on the display.
Bigger numbers look better?
Small numbers look better?
No difference?


Then again..I don't think the Modula-3 code any "scaling" ever, not of pixmaps,
probably not of text.
What it could do is pick different fonts, scale squares and other polygons, and
scale the location of pixmaps. It could perhaps scale their dimensions and let
underlying code scale. I have to look into this. But it'll be a bit.

If you see any calls to GetSystemMetrics in the Modula-3, dork around with those too.


 - Jay



________________________________

Date: Thu, 7 Aug 2008 19:22:39 -0400
From: rcoleburn at scires.com
To: m3devel at elegosoft.com; jayk123 at hotmail.com
Subject: Re: [M3devel] pixmap problem



Jay, I ran your program on a Lenovo/IBM ThinkPad T60 running at 1280x1024 resolution.  Here are the results:



horizonal pixels 1280
veritical pixels SM_CYSCREEN 1024
horizontal millimeters 375
veritical millimeters 300
horizontal pixels per millimeter 3.413333
vertical pixels per millimeter 3.413333
horizontal pixels per inch 86.698667
vertical pixels per inch 86.698667



I tried to run this program on the Dell M4300 system at 1920x1200, but I'm running into some stupid Microsoft problem.  I installed the VC_Redist, but it still doesn't work on this system.  Not sure what is wrong yet.



Regards,

Randy

>>> Jay  8/5/2008 9:01 AM>>>


Randy, I'm pretty clueless here.
I don't do gui or graphics.
If anyone has a clue, please stand up.
If you can get us code to run, please do.
But I think I need multiple particularly configured machines too.

I'm curious what this code prints on the systems:

#include
#include

int main()
{
int pix_ver = { 0 };
int pix_hor = { 0 };
int mm_hor = { 0 };
int mm_ver = { 0 };
HWND hwnd = { 0 };
HDC hdc = { 0 };

hwnd = GetDesktopWindow();
hdc = GetDC(hwnd);
mm_hor = GetDeviceCaps(hdc, HORZSIZE);
mm_ver = GetDeviceCaps(hdc, VERTSIZE);
pix_hor = GetSystemMetrics(SM_CXSCREEN);
pix_ver = GetSystemMetrics(SM_CYSCREEN);

printf("horizonal pixels %d\n", pix_hor);
printf("veritical pixels SM_CYSCREEN %d\n", pix_ver);
printf("horizontal millimeters %d\n", mm_hor);
printf("veritical millimeters %d\n", mm_ver);

printf("horizontal pixels per millimeter %f\n", (((float) pix_hor) / ((float) mm_hor)));
printf("vertical pixels per millimeter %f\n", (((float) pix_ver) / ((float) mm_ver)));

printf("horizontal pixels per inch %f\n", (((float) pix_hor) / ((float) mm_hor) * 10.0 * 2.54));
printf("vertical pixels per inch %f\n", (((float) pix_ver) / ((float) mm_ver) * 10.0 * 2.54));

return 0;
}


for me:

$ gcc dpi.c -luser32 -lgdi32

jay at jay-win9 /dev2/j/dpi
$ ./a
horizonal pixels 1280
veritical pixels SM_CYSCREEN 800
horizontal millimeters 384
veritical millimeters 240
horizontal pixels per millimeter 3.333333
vertical pixels per millimeter 3.333333
horizontal pixels per inch 84.666667
vertical pixels per inch 84.666667

(Visual C++ is fine:
cl dpi.c user32.lib gdi32.lib
.\dpi
)

I wonder if lying in this code:

Searching for 'GetDeviceCaps'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(25): VAR res := NEW(T); n_colors := GetDeviceCaps (WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(32): res.depth := GetDeviceCaps(WinGDI.BITSPIXEL); (* John Karnak 8/3/98 *)
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(68): mm_hor = GetDeviceCaps (WinGDI.HORZSIZE),
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(69): mm_ver = GetDeviceCaps (WinGDI.VERTSIZE) DO

Searching for 'res.res[Axis.T.'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(71): res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(72): res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);


D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(89):PROCEDURE GetDeviceCaps (cap: Ctypes.int): INTEGER =
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(93): res := WinGDI.GetDeviceCaps (hdc, cap);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(98): END GetDeviceCaps;
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnColorMap.m3(268): cnt := WinGDI.GetDeviceCaps (hdc, WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnFont.m3(316): LogicalPixelsPerVertInch := WinGDI.GetDeviceCaps(er.hdc, WinGDI.LOGPIXELSY);
9 occurrence(s) have been found.


Searching for '1000.0'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(463): bmih.biXPelsPerMeter := ROUND (st.res[Axis.T.Hor] * 1000.0);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(464): bmih.biYPelsPerMeter := ROUND (st.res[Axis.T.Ver] * 1000.0);


and just claiming 96dpi is the way to go.
Can you try that??


Specifically try setting res.res[Axis.T.Hor] and .Ver to 3.779527559055118.
Or heck to 3.3333 like my laptop has.


Or maybe claiming ignorance and setting biXPelsPerMeter and biYPelsPerMeter to 0???
Claiming ignorance feels better than lying of course. :)

Hm, so throw in also:

printf("LogicalPixelsX %u\n", GetDeviceCaps(hdc, LOGPIXELSX));
printf("LogicalPixelsY %u\n", GetDeviceCaps(hdc, LOGPIXELSY));

I get the magic number 96.

- Jay


From rcoleburn at scires.com  Fri Aug  8 01:42:33 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Thu, 07 Aug 2008 19:42:33 -0400
Subject: [M3devel] pixmap problem (some success)
In-Reply-To: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>
References: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>
Message-ID: <489B5023.1E75.00D7.1@scires.com>

Ok, I solved the Microsoft problem.
 
Here are the results on Dell M4300 at 1920x1200:
 
horizonal pixels 1920
veritical pixels SM_CYSCREEN 1200
horizontal millimeters 330
veritical millimeters 206
horizontal pixels per millimeter 5.818182
vertical pixels per millimeter 5.825243
horizontal pixels per inch 147.781818
vertical pixels per inch 147.961165
Wow!  these numbers are radically different than the IBM T60 at 1280x1024:
 
horizonal pixels 1280
veritical pixels SM_CYSCREEN 1024
horizontal millimeters 375
veritical millimeters 300
horizontal pixels per millimeter 3.413333
vertical pixels per millimeter 3.413333
horizontal pixels per inch 86.698667
vertical pixels per inch 86.698667
Now, if you look at the Windows dpi setting for the 1920x1200 machine, it says 96dpi, but this is in the General tab of the Display properties Advanced settings.  I suspect this is just the dpi setting applied to fonts.
 
I tried plugging the numbers into Image.i3 as suggested by Daniel:
TYPE
  Raw = OBJECT
      width, height: INTEGER;
      xres: REAL := 147.781818; (* in pixels per inch *)
      yres: REAL := 147.961165; (* in pixels per inch *)
    METHODS
      get (h, v: INTEGER): Pixel;
      set (h, v: INTEGER; pixel: Pixel);
    END;
When I do this, my pixmaps look correct on the 1920x1200 display!!!!!
 
Now, the problem I am faced with is how to come up with a way that the code will work on any type of monitor.  I can't edit Image.i3 for every resolution and produce a different binary.  Any ideas?
 
Regards,
Randy

>>> Jay <jayk123 at hotmail.com> 8/5/2008 9:01 AM >>>


Randy, I'm pretty clueless here.
I don't do gui or graphics.
If anyone has a clue, please stand up.
If you can get us code to run, please do.
But I think I need multiple particularly configured machines too.

I'm curious what this code prints on the systems:

#include
#include

int main()
{
int pix_ver = { 0 };
int pix_hor = { 0 };
int mm_hor = { 0 };
int mm_ver = { 0 };
HWND hwnd = { 0 };
HDC hdc = { 0 };

hwnd = GetDesktopWindow();
hdc = GetDC(hwnd);
mm_hor = GetDeviceCaps(hdc, HORZSIZE);
mm_ver = GetDeviceCaps(hdc, VERTSIZE);
pix_hor = GetSystemMetrics(SM_CXSCREEN);
pix_ver = GetSystemMetrics(SM_CYSCREEN);

printf("horizonal pixels %d\n", pix_hor);
printf("veritical pixels SM_CYSCREEN %d\n", pix_ver);
printf("horizontal millimeters %d\n", mm_hor);
printf("veritical millimeters %d\n", mm_ver);

printf("horizontal pixels per millimeter %f\n", (((float) pix_hor) / ((float) mm_hor)));
printf("vertical pixels per millimeter %f\n", (((float) pix_ver) / ((float) mm_ver)));

printf("horizontal pixels per inch %f\n", (((float) pix_hor) / ((float) mm_hor) * 10.0 * 2.54));
printf("vertical pixels per inch %f\n", (((float) pix_ver) / ((float) mm_ver) * 10.0 * 2.54));

return 0;
}


for me:

$ gcc dpi.c -luser32 -lgdi32

jay at jay-win9 /dev2/j/dpi
$ ./a
horizonal pixels 1280
veritical pixels SM_CYSCREEN 800
horizontal millimeters 384
veritical millimeters 240
horizontal pixels per millimeter 3.333333
vertical pixels per millimeter 3.333333
horizontal pixels per inch 84.666667
vertical pixels per inch 84.666667

(Visual C++ is fine:
cl dpi.c user32.lib gdi32.lib
.\dpi
)

I wonder if lying in this code:

Searching for 'GetDeviceCaps'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(25): VAR res := NEW(T); n_colors := GetDeviceCaps (WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(32): res.depth := GetDeviceCaps(WinGDI.BITSPIXEL); (* John Karnak 8/3/98 *)
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(68): mm_hor = GetDeviceCaps (WinGDI.HORZSIZE),
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(69): mm_ver = GetDeviceCaps (WinGDI.VERTSIZE) DO

Searching for 'res.res[Axis.T.'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(71): res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(72): res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);


D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(89):PROCEDURE GetDeviceCaps (cap: Ctypes.int): INTEGER =
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(93): res := WinGDI.GetDeviceCaps (hdc, cap);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(98): END GetDeviceCaps;
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnColorMap.m3(268): cnt := WinGDI.GetDeviceCaps (hdc, WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnFont.m3(316): LogicalPixelsPerVertInch := WinGDI.GetDeviceCaps(er.hdc, WinGDI.LOGPIXELSY);
9 occurrence(s) have been found.


Searching for '1000.0'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(463): bmih.biXPelsPerMeter := ROUND (st.res[Axis.T.Hor] * 1000.0);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(464): bmih.biYPelsPerMeter := ROUND (st.res[Axis.T.Ver] * 1000.0);


and just claiming 96dpi is the way to go.
Can you try that??


Specifically try setting res.res[Axis.T.Hor] and .Ver to 3.779527559055118.
Or heck to 3.3333 like my laptop has.


Or maybe claiming ignorance and setting biXPelsPerMeter and biYPelsPerMeter to 0???
Claiming ignorance feels better than lying of course. :)

Hm, so throw in also:

printf("LogicalPixelsX %u\n", GetDeviceCaps(hdc, LOGPIXELSX));
printf("LogicalPixelsY %u\n", GetDeviceCaps(hdc, LOGPIXELSY));

I get the magic number 96.

- Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080807/86bd50b5/attachment-0002.html>

From jayk123 at hotmail.com  Fri Aug  8 02:12:24 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 8 Aug 2008 00:12:24 +0000
Subject: [M3devel] pixmap problem
In-Reply-To: <489B4B79.1E75.00D7.1@scires.com>
References: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>
	<489B4B79.1E75.00D7.1@scires.com> 
Message-ID: <COL101-W9A274E937044BF90CB8B0E6740@phx.gbl>


 > Then again..I don't think the Modula-3 code any "scaling" ever, not of pixmaps, 
False.
 
m3-ui\vbtkit\src\lego\Image.m3 is very much in the business of scalling.
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080808/982de9d6/attachment-0002.html>

From jayk123 at hotmail.com  Fri Aug  8 02:16:49 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 8 Aug 2008 00:16:49 +0000
Subject: [M3devel] pixmap problem (some success)
In-Reply-To: <489B5023.1E75.00D7.1@scires.com>
References: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>
	<489B5023.1E75.00D7.1@scires.com>
Message-ID: <COL101-W279710F3EF9B814B1DA853E6740@phx.gbl>


Awesome. I expect it is easy from here. Thanks David!

I *assume* the 75 should have been 86 in the one case,
but close enough that nobody noticed.
So these numbers come pretty directly from the GetDeviceCaps / GetSystemMetrics.

And then X Windows too.
Does anyone have a high DPI monitor running X Windows?
Probably easy enough to do this blind.

I'm trying to ignore the fact that systems have multiple
monitors, with varying dpi. You are supposed to loop your
drawing over monitors and compute what it looks like per-monitor.
I'm just making that up, right? :)

 - Jay

________________________________

Date: Thu, 7 Aug 2008 19:42:33 -0400
From: rcoleburn at scires.com
To: m3devel at elegosoft.com; jayk123 at hotmail.com; dabenavidesd at yahoo.es
Subject: Re: [M3devel] pixmap problem (some success)



Ok, I solved the Microsoft problem.



Here are the results on Dell M4300 at 1920x1200:



horizonal pixels 1920
veritical pixels SM_CYSCREEN 1200
horizontal millimeters 330
veritical millimeters 206
horizontal pixels per millimeter 5.818182
vertical pixels per millimeter 5.825243
horizontal pixels per inch 147.781818
vertical pixels per inch 147.961165

Wow!  these numbers are radically different than the IBM T60 at 1280x1024:



horizonal pixels 1280
veritical pixels SM_CYSCREEN 1024
horizontal millimeters 375
veritical millimeters 300
horizontal pixels per millimeter 3.413333
vertical pixels per millimeter 3.413333
horizontal pixels per inch 86.698667
vertical pixels per inch 86.698667

Now, if you look at the Windows dpi setting for the 1920x1200 machine, it says 96dpi, but this is in the General tab of the Display properties Advanced settings.  I suspect this is just the dpi setting applied to fonts.



I tried plugging the numbers into Image.i3 as suggested by Daniel:

TYPE
  Raw = OBJECT
      width, height: INTEGER;
      xres: REAL := 147.781818; (* in pixels per inch *)
      yres: REAL := 147.961165; (* in pixels per inch *)
    METHODS
      get (h, v: INTEGER): Pixel;
      set (h, v: INTEGER; pixel: Pixel);
    END;

When I do this, my pixmaps look correct on the 1920x1200 display!!!!!



Now, the problem I am faced with is how to come up with a way that the code will work on any type of monitor.  I can't edit Image.i3 for every resolution and produce a different binary.  Any ideas?



Regards,

Randy


>>> Jay  8/5/2008 9:01 AM>>>


Randy, I'm pretty clueless here.
I don't do gui or graphics.
If anyone has a clue, please stand up.
If you can get us code to run, please do.
But I think I need multiple particularly configured machines too.

I'm curious what this code prints on the systems:

#include
#include

int main()
{
int pix_ver = { 0 };
int pix_hor = { 0 };
int mm_hor = { 0 };
int mm_ver = { 0 };
HWND hwnd = { 0 };
HDC hdc = { 0 };

hwnd = GetDesktopWindow();
hdc = GetDC(hwnd);
mm_hor = GetDeviceCaps(hdc, HORZSIZE);
mm_ver = GetDeviceCaps(hdc, VERTSIZE);
pix_hor = GetSystemMetrics(SM_CXSCREEN);
pix_ver = GetSystemMetrics(SM_CYSCREEN);

printf("horizonal pixels %d\n", pix_hor);
printf("veritical pixels SM_CYSCREEN %d\n", pix_ver);
printf("horizontal millimeters %d\n", mm_hor);
printf("veritical millimeters %d\n", mm_ver);

printf("horizontal pixels per millimeter %f\n", (((float) pix_hor) / ((float) mm_hor)));
printf("vertical pixels per millimeter %f\n", (((float) pix_ver) / ((float) mm_ver)));

printf("horizontal pixels per inch %f\n", (((float) pix_hor) / ((float) mm_hor) * 10.0 * 2.54));
printf("vertical pixels per inch %f\n", (((float) pix_ver) / ((float) mm_ver) * 10.0 * 2.54));

return 0;
}


for me:

$ gcc dpi.c -luser32 -lgdi32

jay at jay-win9 /dev2/j/dpi
$ ./a
horizonal pixels 1280
veritical pixels SM_CYSCREEN 800
horizontal millimeters 384
veritical millimeters 240
horizontal pixels per millimeter 3.333333
vertical pixels per millimeter 3.333333
horizontal pixels per inch 84.666667
vertical pixels per inch 84.666667

(Visual C++ is fine:
cl dpi.c user32.lib gdi32.lib
.\dpi
)

I wonder if lying in this code:

Searching for 'GetDeviceCaps'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(25): VAR res := NEW(T); n_colors := GetDeviceCaps (WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(32): res.depth := GetDeviceCaps(WinGDI.BITSPIXEL); (* John Karnak 8/3/98 *)
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(68): mm_hor = GetDeviceCaps (WinGDI.HORZSIZE),
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(69): mm_ver = GetDeviceCaps (WinGDI.VERTSIZE) DO

Searching for 'res.res[Axis.T.'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(71): res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(72): res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);


D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(89):PROCEDURE GetDeviceCaps (cap: Ctypes.int): INTEGER =
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(93): res := WinGDI.GetDeviceCaps (hdc, cap);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(98): END GetDeviceCaps;
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnColorMap.m3(268): cnt := WinGDI.GetDeviceCaps (hdc, WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnFont.m3(316): LogicalPixelsPerVertInch := WinGDI.GetDeviceCaps(er.hdc, WinGDI.LOGPIXELSY);
9 occurrence(s) have been found.


Searching for '1000.0'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(463): bmih.biXPelsPerMeter := ROUND (st.res[Axis.T.Hor] * 1000.0);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(464): bmih.biYPelsPerMeter := ROUND (st.res[Axis.T.Ver] * 1000.0);


and just claiming 96dpi is the way to go.
Can you try that??


Specifically try setting res.res[Axis.T.Hor] and .Ver to 3.779527559055118.
Or heck to 3.3333 like my laptop has.


Or maybe claiming ignorance and setting biXPelsPerMeter and biYPelsPerMeter to 0???
Claiming ignorance feels better than lying of course. :)

Hm, so throw in also:

printf("LogicalPixelsX %u\n", GetDeviceCaps(hdc, LOGPIXELSX));
printf("LogicalPixelsY %u\n", GetDeviceCaps(hdc, LOGPIXELSY));

I get the magic number 96.

- Jay


From rcoleburn at scires.com  Fri Aug  8 02:26:13 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Thu, 07 Aug 2008 20:26:13 -0400
Subject: [M3devel] pixmap problem (some success)
In-Reply-To: <COL101-W279710F3EF9B814B1DA853E6740@phx.gbl>
References: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>
	<489B5023.1E75.00D7.1@scires.com>
	<COL101-W279710F3EF9B814B1DA853E6740@phx.gbl>
Message-ID: <489B5A5F.1E75.00D7.1@scires.com>

Well, I hope to soon share your optimism for "easy".  
 
Since these numbers wind up being default values for the xres/yres and since changing the defaults has made a big difference in the results, it would seem that most code must not be computing these, but relying on the default values to be correct.  
 
Since these numbers may be different for every program run on a different monitor (potentially), the question becomes how to effect a change that will work in all cases without having to recompile vbtkit.
 
Does this mean we have to track down each use of Image.Raw and put in code to compute the dpi?  Or is there some way we can do this during an initialization sequence? but alas, how to deal with the defaults supplied in the declaration?
 
Regards,
Randy

>>> Jay <jayk123 at hotmail.com> 8/7/2008 8:16 PM >>>

Awesome. I expect it is easy from here. Thanks David!

I *assume* the 75 should have been 86 in the one case,
but close enough that nobody noticed.
So these numbers come pretty directly from the GetDeviceCaps / GetSystemMetrics.

And then X Windows too.
Does anyone have a high DPI monitor running X Windows?
Probably easy enough to do this blind.

I'm trying to ignore the fact that systems have multiple
monitors, with varying dpi. You are supposed to loop your
drawing over monitors and compute what it looks like per-monitor.
I'm just making that up, right? :)

- Jay

________________________________

Date: Thu, 7 Aug 2008 19:42:33 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com; jayk123 at hotmail.com; dabenavidesd at yahoo.es 
Subject: Re: [M3devel] pixmap problem (some success)



Ok, I solved the Microsoft problem.



Here are the results on Dell M4300 at 1920x1200:



horizonal pixels 1920
veritical pixels SM_CYSCREEN 1200
horizontal millimeters 330
veritical millimeters 206
horizontal pixels per millimeter 5.818182
vertical pixels per millimeter 5.825243
horizontal pixels per inch 147.781818
vertical pixels per inch 147.961165

Wow!  these numbers are radically different than the IBM T60 at 1280x1024:



horizonal pixels 1280
veritical pixels SM_CYSCREEN 1024
horizontal millimeters 375
veritical millimeters 300
horizontal pixels per millimeter 3.413333
vertical pixels per millimeter 3.413333
horizontal pixels per inch 86.698667
vertical pixels per inch 86.698667

Now, if you look at the Windows dpi setting for the 1920x1200 machine, it says 96dpi, but this is in the General tab of the Display properties Advanced settings.  I suspect this is just the dpi setting applied to fonts.



I tried plugging the numbers into Image.i3 as suggested by Daniel:

TYPE
  Raw = OBJECT
      width, height: INTEGER;
      xres: REAL := 147.781818; (* in pixels per inch *)
      yres: REAL := 147.961165; (* in pixels per inch *)
    METHODS
      get (h, v: INTEGER): Pixel;
      set (h, v: INTEGER; pixel: Pixel);
    END;

When I do this, my pixmaps look correct on the 1920x1200 display!!!!!



Now, the problem I am faced with is how to come up with a way that the code will work on any type of monitor.  I can't edit Image.i3 for every resolution and produce a different binary.  Any ideas?



Regards,

Randy


>>> Jay  8/5/2008 9:01 AM>>>


Randy, I'm pretty clueless here.
I don't do gui or graphics.
If anyone has a clue, please stand up.
If you can get us code to run, please do.
But I think I need multiple particularly configured machines too.

I'm curious what this code prints on the systems:

#include
#include

int main()
{
int pix_ver = { 0 };
int pix_hor = { 0 };
int mm_hor = { 0 };
int mm_ver = { 0 };
HWND hwnd = { 0 };
HDC hdc = { 0 };

hwnd = GetDesktopWindow();
hdc = GetDC(hwnd);
mm_hor = GetDeviceCaps(hdc, HORZSIZE);
mm_ver = GetDeviceCaps(hdc, VERTSIZE);
pix_hor = GetSystemMetrics(SM_CXSCREEN);
pix_ver = GetSystemMetrics(SM_CYSCREEN);

printf("horizonal pixels %d\n", pix_hor);
printf("veritical pixels SM_CYSCREEN %d\n", pix_ver);
printf("horizontal millimeters %d\n", mm_hor);
printf("veritical millimeters %d\n", mm_ver);

printf("horizontal pixels per millimeter %f\n", (((float) pix_hor) / ((float) mm_hor)));
printf("vertical pixels per millimeter %f\n", (((float) pix_ver) / ((float) mm_ver)));

printf("horizontal pixels per inch %f\n", (((float) pix_hor) / ((float) mm_hor) * 10.0 * 2.54));
printf("vertical pixels per inch %f\n", (((float) pix_ver) / ((float) mm_ver) * 10.0 * 2.54));

return 0;
}


for me:

$ gcc dpi.c -luser32 -lgdi32

jay at jay-win9 /dev2/j/dpi
$ ./a
horizonal pixels 1280
veritical pixels SM_CYSCREEN 800
horizontal millimeters 384
veritical millimeters 240
horizontal pixels per millimeter 3.333333
vertical pixels per millimeter 3.333333
horizontal pixels per inch 84.666667
vertical pixels per inch 84.666667

(Visual C++ is fine:
cl dpi.c user32.lib gdi32.lib
.\dpi
)

I wonder if lying in this code:

Searching for 'GetDeviceCaps'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(25): VAR res := NEW(T); n_colors := GetDeviceCaps (WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(32): res.depth := GetDeviceCaps(WinGDI.BITSPIXEL); (* John Karnak 8/3/98 *)
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(68): mm_hor = GetDeviceCaps (WinGDI.HORZSIZE),
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(69): mm_ver = GetDeviceCaps (WinGDI.VERTSIZE) DO

Searching for 'res.res[Axis.T.'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(71): res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(72): res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);


D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(89):PROCEDURE GetDeviceCaps (cap: Ctypes.int): INTEGER =
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(93): res := WinGDI.GetDeviceCaps (hdc, cap);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(98): END GetDeviceCaps;
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnColorMap.m3(268): cnt := WinGDI.GetDeviceCaps (hdc, WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnFont.m3(316): LogicalPixelsPerVertInch := WinGDI.GetDeviceCaps(er.hdc, WinGDI.LOGPIXELSY);
9 occurrence(s) have been found.


Searching for '1000.0'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(463): bmih.biXPelsPerMeter := ROUND (st.res[Axis.T.Hor] * 1000.0);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(464): bmih.biYPelsPerMeter := ROUND (st.res[Axis.T.Ver] * 1000.0);


and just claiming 96dpi is the way to go.
Can you try that??


Specifically try setting res.res[Axis.T.Hor] and .Ver to 3.779527559055118.
Or heck to 3.3333 like my laptop has.


Or maybe claiming ignorance and setting biXPelsPerMeter and biYPelsPerMeter to 0???
Claiming ignorance feels better than lying of course. :)

Hm, so throw in also:

printf("LogicalPixelsX %u\n", GetDeviceCaps(hdc, LOGPIXELSX));
printf("LogicalPixelsY %u\n", GetDeviceCaps(hdc, LOGPIXELSY));

I get the magic number 96.

- Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080807/576a96e4/attachment-0002.html>

From jayk123 at hotmail.com  Fri Aug  8 03:35:10 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 8 Aug 2008 01:35:10 +0000
Subject: [M3devel] pixmap problem (some success)
In-Reply-To: <489B5A5F.1E75.00D7.1@scires.com>
References: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>
	<489B5023.1E75.00D7.1@scires.com>
	<COL101-W279710F3EF9B814B1DA853E6740@phx.gbl> 
	<489B5A5F.1E75.00D7.1@scires.com>
Message-ID: <COL101-W76DCEA23FC2EA0FD299A3DE6740@phx.gbl>


Computing the values is probably easy. It appears we already have the code to do that -- the program I had you run and report the numbers.

It is true there is a *small* problem of computing them early enough, but..yeah, I expect that's just done in the module initializer. I really don't like "global initialization" code ala C++ global constructors/destructors, but Modula-3 is rife with them and they aren't going away, so I'll just pile in a few more bits.

I don't know if is legal Modula-3 code, but if fields can be initialized from globals, that's about all it takes.

SOMETHING LIKE (don't castigate me where I am wrong)
In the platform-independent code, add two private globals:
DefaultXRes : INTEGER;
DefaultYRes : INTEGER;

heck, default them to 75, for the Posix case.

In the platform independent interface, functions to set them:
PROCEDURE SetDefaultXRes(a: INTEGER);
PROCEDURE SetDefaultYRes(a: INTEGER);

Nothing else on Posix, for now.

On Windows, add another module WinImage.m3 that imports Image and just has a module initializer:

BEGIN
  Image.SetDefaultXRes(ComputedSomehowNotDifficult());
  Image.SetDefaultYRes(ComputedSomehowNotDifficult());
END.

If fields cannot be initialized from globals (or function calls..heh, that has a niceness!), then you have to search out all the uses and change them to function calls, possibly a lot, possibly tedious, definitely a "breaking change", but probably just fine, really.

And then, if fields can be initialized from functions, that'd be better -- that way no module initializer.


Module initializers are "bad" in that they cause a startup cost for "everyone", even if they aren't needed for a particular scenario. It is "best" imho to have constant initialization as much as possible, and where values must be computed, use an explicit function call when needed. You can still cache the values upon first computation.


> would seem that most code must not be computing these, but relying on the default values to be correct.

Or that "most code" doesn't care what the values are, doesn't use them at all.
Like, maybe they are only used for pixmaps and not text or lines?

Anyway, I can't look into this now, but hopefully "soon".
If your customer is antsy, "the problem is mostly understood and a fix will definitely be available soon".
I think "patch Tuesday" is coming up. Let's make it by then? :)


Really, I can't believe they'd call for a rewrite over this small issue.
Presumably they really want the rewrite and are looking for any excuse they can find.
Also, if you removed the "advertising" from the splash screen, they might not have even noticed?
Or, I guess if this is Windows only, the odd look could not be noticed.
But if they also want it on X and you showed it there, and it looked the same on Windows, well...
(Really this is just a general dilemna -- app looks the same as app on all platforms, or app looks like the platform on all platforms.)


 - Jay

________________________________

Date: Thu, 7 Aug 2008 20:26:13 -0400
From: rcoleburn at scires.com
To: m3devel at elegosoft.com; jayk123 at hotmail.com; dabenavidesd at yahoo.es
Subject: RE: [M3devel] pixmap problem (some success)



Well, I hope to soon share your optimism for "easy".



Since these numbers wind up being default values for the xres/yres and since changing the defaults has made a big difference in the results, it would seem that most code must not be computing these, but relying on the default values to be correct.



Since these numbers may be different for every program run on a different monitor (potentially), the question becomes how to effect a change that will work in all cases without having to recompile vbtkit.



Does this mean we have to track down each use of Image.Raw and put in code to compute the dpi?  Or is there some way we can do this during an initialization sequence? but alas, how to deal with the defaults supplied in the declaration?



Regards,

Randy

>>> Jay  8/7/2008 8:16 PM>>>

Awesome. I expect it is easy from here. Thanks David!

I *assume* the 75 should have been 86 in the one case,
but close enough that nobody noticed.
So these numbers come pretty directly from the GetDeviceCaps / GetSystemMetrics.

And then X Windows too.
Does anyone have a high DPI monitor running X Windows?
Probably easy enough to do this blind.

I'm trying to ignore the fact that systems have multiple
monitors, with varying dpi. You are supposed to loop your
drawing over monitors and compute what it looks like per-monitor.
I'm just making that up, right? :)

- Jay

________________________________

Date: Thu, 7 Aug 2008 19:42:33 -0400
From: rcoleburn at scires.com
To: m3devel at elegosoft.com; jayk123 at hotmail.com; dabenavidesd at yahoo.es
Subject: Re: [M3devel] pixmap problem (some success)



Ok, I solved the Microsoft problem.



Here are the results on Dell M4300 at 1920x1200:



horizonal pixels 1920
veritical pixels SM_CYSCREEN 1200
horizontal millimeters 330
veritical millimeters 206
horizontal pixels per millimeter 5.818182
vertical pixels per millimeter 5.825243
horizontal pixels per inch 147.781818
vertical pixels per inch 147.961165

Wow!  these numbers are radically different than the IBM T60 at 1280x1024:



horizonal pixels 1280
veritical pixels SM_CYSCREEN 1024
horizontal millimeters 375
veritical millimeters 300
horizontal pixels per millimeter 3.413333
vertical pixels per millimeter 3.413333
horizontal pixels per inch 86.698667
vertical pixels per inch 86.698667

Now, if you look at the Windows dpi setting for the 1920x1200 machine, it says 96dpi, but this is in the General tab of the Display properties Advanced settings.  I suspect this is just the dpi setting applied to fonts.



I tried plugging the numbers into Image.i3 as suggested by Daniel:

TYPE
  Raw = OBJECT
      width, height: INTEGER;
      xres: REAL := 147.781818; (* in pixels per inch *)
      yres: REAL := 147.961165; (* in pixels per inch *)
    METHODS
      get (h, v: INTEGER): Pixel;
      set (h, v: INTEGER; pixel: Pixel);
    END;

When I do this, my pixmaps look correct on the 1920x1200 display!!!!!



Now, the problem I am faced with is how to come up with a way that the code will work on any type of monitor.  I can't edit Image.i3 for every resolution and produce a different binary.  Any ideas?



Regards,

Randy


>>> Jay  8/5/2008 9:01 AM>>>


Randy, I'm pretty clueless here.
I don't do gui or graphics.
If anyone has a clue, please stand up.
If you can get us code to run, please do.
But I think I need multiple particularly configured machines too.

I'm curious what this code prints on the systems:

#include
#include

int main()
{
int pix_ver = { 0 };
int pix_hor = { 0 };
int mm_hor = { 0 };
int mm_ver = { 0 };
HWND hwnd = { 0 };
HDC hdc = { 0 };

hwnd = GetDesktopWindow();
hdc = GetDC(hwnd);
mm_hor = GetDeviceCaps(hdc, HORZSIZE);
mm_ver = GetDeviceCaps(hdc, VERTSIZE);
pix_hor = GetSystemMetrics(SM_CXSCREEN);
pix_ver = GetSystemMetrics(SM_CYSCREEN);

printf("horizonal pixels %d\n", pix_hor);
printf("veritical pixels SM_CYSCREEN %d\n", pix_ver);
printf("horizontal millimeters %d\n", mm_hor);
printf("veritical millimeters %d\n", mm_ver);

printf("horizontal pixels per millimeter %f\n", (((float) pix_hor) / ((float) mm_hor)));
printf("vertical pixels per millimeter %f\n", (((float) pix_ver) / ((float) mm_ver)));

printf("horizontal pixels per inch %f\n", (((float) pix_hor) / ((float) mm_hor) * 10.0 * 2.54));
printf("vertical pixels per inch %f\n", (((float) pix_ver) / ((float) mm_ver) * 10.0 * 2.54));

return 0;
}


for me:

$ gcc dpi.c -luser32 -lgdi32

jay at jay-win9 /dev2/j/dpi
$ ./a
horizonal pixels 1280
veritical pixels SM_CYSCREEN 800
horizontal millimeters 384
veritical millimeters 240
horizontal pixels per millimeter 3.333333
vertical pixels per millimeter 3.333333
horizontal pixels per inch 84.666667
vertical pixels per inch 84.666667

(Visual C++ is fine:
cl dpi.c user32.lib gdi32.lib
.\dpi
)

I wonder if lying in this code:

Searching for 'GetDeviceCaps'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(25): VAR res := NEW(T); n_colors := GetDeviceCaps (WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(32): res.depth := GetDeviceCaps(WinGDI.BITSPIXEL); (* John Karnak 8/3/98 *)
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(68): mm_hor = GetDeviceCaps (WinGDI.HORZSIZE),
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(69): mm_ver = GetDeviceCaps (WinGDI.VERTSIZE) DO

Searching for 'res.res[Axis.T.'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(71): res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(72): res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);


D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(89):PROCEDURE GetDeviceCaps (cap: Ctypes.int): INTEGER =
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(93): res := WinGDI.GetDeviceCaps (hdc, cap);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(98): END GetDeviceCaps;
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnColorMap.m3(268): cnt := WinGDI.GetDeviceCaps (hdc, WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnFont.m3(316): LogicalPixelsPerVertInch := WinGDI.GetDeviceCaps(er.hdc, WinGDI.LOGPIXELSY);
9 occurrence(s) have been found.


Searching for '1000.0'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(463): bmih.biXPelsPerMeter := ROUND (st.res[Axis.T.Hor] * 1000.0);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(464): bmih.biYPelsPerMeter := ROUND (st.res[Axis.T.Ver] * 1000.0);


and just claiming 96dpi is the way to go.
Can you try that??


Specifically try setting res.res[Axis.T.Hor] and .Ver to 3.779527559055118.
Or heck to 3.3333 like my laptop has.


Or maybe claiming ignorance and setting biXPelsPerMeter and biYPelsPerMeter to 0???
Claiming ignorance feels better than lying of course. :)

Hm, so throw in also:

printf("LogicalPixelsX %u\n", GetDeviceCaps(hdc, LOGPIXELSX));
printf("LogicalPixelsY %u\n", GetDeviceCaps(hdc, LOGPIXELSY));

I get the magic number 96.

- Jay



From rcoleburn at scires.com  Fri Aug  8 03:59:07 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Thu, 07 Aug 2008 21:59:07 -0400
Subject: [M3devel] pixmap problem (some success)
In-Reply-To: <COL101-W76DCEA23FC2EA0FD299A3DE6740@phx.gbl>
References: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>
	<489B5023.1E75.00D7.1@scires.com>
	<COL101-W279710F3EF9B814B1DA853E6740@phx.gbl>
	<489B5A5F.1E75.00D7.1@scires.com>
	<COL101-W76DCEA23FC2EA0FD299A3DE6740@phx.gbl>
Message-ID: <489B7025.1E75.00D7.1@scires.com>

Jay,
 
The splash screen is not the major issue.  The pixmaps used for boolean choices, radio choices, numerics, etc. get enlarged to the point that some windows won't fit on the screen.  Also, it looks really bad--like both a first-grader with a big marker and a college-student with a fine tip pencil worked on the same window.
 
I've tried very hard to make Trestle/FormsVBT look and act like Windows GUI, but it is indeed different.  For example, on menus, you have to hold down the mouse to keep the menu open.  All these were small issues 10 years ago, but now they seem to be looming large in the customer's mind.
 
So, bottom line is that if I can't fix what they deem to be functional problems, they will indeed call for a rewrite.
 
Now that we've got the typein problem solved (thanks Olaf) and are on track for the pixmap issue, I feel better.  I have recently discovered that the numeric keys on the numeric keypad aren't accepted, so I have yet to track that problem down.
 
As for your idea of using a variable as the default initializer for xres/yres, this is not legal Modula-3.  You will get a compile error that the default is not constant.  Otherwise, it was a good idea.
 
Since Raw is an object and objects are created dynamically and new subtypes can be created (inheritance), I think the problem of how to properly set xres/yres is complicated.
 
Seems like what we need is some way to adjust these fields when the object is created initially.  Alas, Raw does not have an init() method!
 
Regards,
Randy

>>> Jay <jayk123 at hotmail.com> 8/7/2008 9:35 PM >>>

Computing the values is probably easy. It appears we already have the code to do that -- the program I had you run and report the numbers.

It is true there is a *small* problem of computing them early enough, but..yeah, I expect that's just done in the module initializer. I really don't like "global initialization" code ala C++ global constructors/destructors, but Modula-3 is rife with them and they aren't going away, so I'll just pile in a few more bits.

I don't know if is legal Modula-3 code, but if fields can be initialized from globals, that's about all it takes.

SOMETHING LIKE (don't castigate me where I am wrong)
In the platform-independent code, add two private globals:
DefaultXRes : INTEGER;
DefaultYRes : INTEGER;

heck, default them to 75, for the Posix case.

In the platform independent interface, functions to set them:
PROCEDURE SetDefaultXRes(a: INTEGER);
PROCEDURE SetDefaultYRes(a: INTEGER);

Nothing else on Posix, for now.

On Windows, add another module WinImage.m3 that imports Image and just has a module initializer:

BEGIN
  Image.SetDefaultXRes(ComputedSomehowNotDifficult());
  Image.SetDefaultYRes(ComputedSomehowNotDifficult());
END.

If fields cannot be initialized from globals (or function calls..heh, that has a niceness!), then you have to search out all the uses and change them to function calls, possibly a lot, possibly tedious, definitely a "breaking change", but probably just fine, really.

And then, if fields can be initialized from functions, that'd be better -- that way no module initializer.


Module initializers are "bad" in that they cause a startup cost for "everyone", even if they aren't needed for a particular scenario. It is "best" imho to have constant initialization as much as possible, and where values must be computed, use an explicit function call when needed. You can still cache the values upon first computation.


> would seem that most code must not be computing these, but relying on the default values to be correct.

Or that "most code" doesn't care what the values are, doesn't use them at all.
Like, maybe they are only used for pixmaps and not text or lines?

Anyway, I can't look into this now, but hopefully "soon".
If your customer is antsy, "the problem is mostly understood and a fix will definitely be available soon".
I think "patch Tuesday" is coming up. Let's make it by then? :)


Really, I can't believe they'd call for a rewrite over this small issue.
Presumably they really want the rewrite and are looking for any excuse they can find.
Also, if you removed the "advertising" from the splash screen, they might not have even noticed?
Or, I guess if this is Windows only, the odd look could not be noticed.
But if they also want it on X and you showed it there, and it looked the same on Windows, well...
(Really this is just a general dilemna -- app looks the same as app on all platforms, or app looks like the platform on all platforms.)


- Jay

________________________________

Date: Thu, 7 Aug 2008 20:26:13 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com; jayk123 at hotmail.com; dabenavidesd at yahoo.es 
Subject: RE: [M3devel] pixmap problem (some success)



Well, I hope to soon share your optimism for "easy".



Since these numbers wind up being default values for the xres/yres and since changing the defaults has made a big difference in the results, it would seem that most code must not be computing these, but relying on the default values to be correct.



Since these numbers may be different for every program run on a different monitor (potentially), the question becomes how to effect a change that will work in all cases without having to recompile vbtkit.



Does this mean we have to track down each use of Image.Raw and put in code to compute the dpi?  Or is there some way we can do this during an initialization sequence? but alas, how to deal with the defaults supplied in the declaration?



Regards,

Randy

>>> Jay  8/7/2008 8:16 PM>>>

Awesome. I expect it is easy from here. Thanks David!

I *assume* the 75 should have been 86 in the one case,
but close enough that nobody noticed.
So these numbers come pretty directly from the GetDeviceCaps / GetSystemMetrics.

And then X Windows too.
Does anyone have a high DPI monitor running X Windows?
Probably easy enough to do this blind.

I'm trying to ignore the fact that systems have multiple
monitors, with varying dpi. You are supposed to loop your
drawing over monitors and compute what it looks like per-monitor.
I'm just making that up, right? :)

- Jay

________________________________

Date: Thu, 7 Aug 2008 19:42:33 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com; jayk123 at hotmail.com; dabenavidesd at yahoo.es 
Subject: Re: [M3devel] pixmap problem (some success)



Ok, I solved the Microsoft problem.



Here are the results on Dell M4300 at 1920x1200:



horizonal pixels 1920
veritical pixels SM_CYSCREEN 1200
horizontal millimeters 330
veritical millimeters 206
horizontal pixels per millimeter 5.818182
vertical pixels per millimeter 5.825243
horizontal pixels per inch 147.781818
vertical pixels per inch 147.961165

Wow!  these numbers are radically different than the IBM T60 at 1280x1024:



horizonal pixels 1280
veritical pixels SM_CYSCREEN 1024
horizontal millimeters 375
veritical millimeters 300
horizontal pixels per millimeter 3.413333
vertical pixels per millimeter 3.413333
horizontal pixels per inch 86.698667
vertical pixels per inch 86.698667

Now, if you look at the Windows dpi setting for the 1920x1200 machine, it says 96dpi, but this is in the General tab of the Display properties Advanced settings.  I suspect this is just the dpi setting applied to fonts.



I tried plugging the numbers into Image.i3 as suggested by Daniel:

TYPE
  Raw = OBJECT
      width, height: INTEGER;
      xres: REAL := 147.781818; (* in pixels per inch *)
      yres: REAL := 147.961165; (* in pixels per inch *)
    METHODS
      get (h, v: INTEGER): Pixel;
      set (h, v: INTEGER; pixel: Pixel);
    END;

When I do this, my pixmaps look correct on the 1920x1200 display!!!!!



Now, the problem I am faced with is how to come up with a way that the code will work on any type of monitor.  I can't edit Image.i3 for every resolution and produce a different binary.  Any ideas?



Regards,

Randy


>>> Jay  8/5/2008 9:01 AM>>>


Randy, I'm pretty clueless here.
I don't do gui or graphics.
If anyone has a clue, please stand up.
If you can get us code to run, please do.
But I think I need multiple particularly configured machines too.

I'm curious what this code prints on the systems:

#include
#include

int main()
{
int pix_ver = { 0 };
int pix_hor = { 0 };
int mm_hor = { 0 };
int mm_ver = { 0 };
HWND hwnd = { 0 };
HDC hdc = { 0 };

hwnd = GetDesktopWindow();
hdc = GetDC(hwnd);
mm_hor = GetDeviceCaps(hdc, HORZSIZE);
mm_ver = GetDeviceCaps(hdc, VERTSIZE);
pix_hor = GetSystemMetrics(SM_CXSCREEN);
pix_ver = GetSystemMetrics(SM_CYSCREEN);

printf("horizonal pixels %d\n", pix_hor);
printf("veritical pixels SM_CYSCREEN %d\n", pix_ver);
printf("horizontal millimeters %d\n", mm_hor);
printf("veritical millimeters %d\n", mm_ver);

printf("horizontal pixels per millimeter %f\n", (((float) pix_hor) / ((float) mm_hor)));
printf("vertical pixels per millimeter %f\n", (((float) pix_ver) / ((float) mm_ver)));

printf("horizontal pixels per inch %f\n", (((float) pix_hor) / ((float) mm_hor) * 10.0 * 2.54));
printf("vertical pixels per inch %f\n", (((float) pix_ver) / ((float) mm_ver) * 10.0 * 2.54));

return 0;
}


for me:

$ gcc dpi.c -luser32 -lgdi32

jay at jay-win9 /dev2/j/dpi
$ ./a
horizonal pixels 1280
veritical pixels SM_CYSCREEN 800
horizontal millimeters 384
veritical millimeters 240
horizontal pixels per millimeter 3.333333
vertical pixels per millimeter 3.333333
horizontal pixels per inch 84.666667
vertical pixels per inch 84.666667

(Visual C++ is fine:
cl dpi.c user32.lib gdi32.lib
.\dpi
)

I wonder if lying in this code:

Searching for 'GetDeviceCaps'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(25): VAR res := NEW(T); n_colors := GetDeviceCaps (WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(32): res.depth := GetDeviceCaps(WinGDI.BITSPIXEL); (* John Karnak 8/3/98 *)
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(68): mm_hor = GetDeviceCaps (WinGDI.HORZSIZE),
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(69): mm_ver = GetDeviceCaps (WinGDI.VERTSIZE) DO

Searching for 'res.res[Axis.T.'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(71): res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(72): res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);


D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(89):PROCEDURE GetDeviceCaps (cap: Ctypes.int): INTEGER =
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(93): res := WinGDI.GetDeviceCaps (hdc, cap);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(98): END GetDeviceCaps;
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnColorMap.m3(268): cnt := WinGDI.GetDeviceCaps (hdc, WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnFont.m3(316): LogicalPixelsPerVertInch := WinGDI.GetDeviceCaps(er.hdc, WinGDI.LOGPIXELSY);
9 occurrence(s) have been found.


Searching for '1000.0'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(463): bmih.biXPelsPerMeter := ROUND (st.res[Axis.T.Hor] * 1000.0);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(464): bmih.biYPelsPerMeter := ROUND (st.res[Axis.T.Ver] * 1000.0);


and just claiming 96dpi is the way to go.
Can you try that??


Specifically try setting res.res[Axis.T.Hor] and .Ver to 3.779527559055118.
Or heck to 3.3333 like my laptop has.


Or maybe claiming ignorance and setting biXPelsPerMeter and biYPelsPerMeter to 0???
Claiming ignorance feels better than lying of course. :)

Hm, so throw in also:

printf("LogicalPixelsX %u\n", GetDeviceCaps(hdc, LOGPIXELSX));
printf("LogicalPixelsY %u\n", GetDeviceCaps(hdc, LOGPIXELSY));

I get the magic number 96.

- Jay


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080807/9548b783/attachment-0002.html>

From jayk123 at hotmail.com  Fri Aug  8 16:05:15 2008
From: jayk123 at hotmail.com (Jay)
Date: Fri, 8 Aug 2008 14:05:15 +0000
Subject: [M3devel] pixmap problem (some success)
In-Reply-To: <489B7025.1E75.00D7.1@scires.com>
References: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>
	<489B5023.1E75.00D7.1@scires.com>
	<COL101-W279710F3EF9B814B1DA853E6740@phx.gbl>
	<489B5A5F.1E75.00D7.1@scires.com>
	<COL101-W76DCEA23FC2EA0FD299A3DE6740@phx.gbl> 
	<489B7025.1E75.00D7.1@scires.com>
Message-ID: <COL101-W49AB1574C557B5343D724DE6740@phx.gbl>


I committed a possible fix here.
Please see how it fairs.

I have a few Modula-3 questions related to the fix.

 - Did I have to expose the functions in the .i3 file
  that implement the methods? That seems "wrong".


   - Could I have used "stronger language opacity" instead
    of "informal privacy"? That is, could I have used an
    opaque type?

   - Will the change break pickles?
     "Both" due to the addition of data "or" methods?
     ie: What breaks pickles?
     Do I need to think in the mindset of
      C:
       typedef struct {
         int a,b;
       } foo_t;

       foo_t f;
       fwrite(&f, sizeof(f), 1, file);

      and not breaking such code? 
     Only if the type is "branded"? Or if types derived from it are branded?
        There could be derived types not in the cm3 tree though.
        How much do we care about breaking code outside the cm3 tree?
        e.g. in this change, I had to change every use of .xres and .yres.
       I did that, but only in the code "we have". There could be more out there.
       Personally, I get quite frustrated by this issue. I'm very willng to "fix"
        and maybe test pretty large amounts of code -- pay the price for fixing things with
        "breaking" changes, or else not make the change, but if I don't have the code, I can't.

  If this breaks pickles, I can restate the fix in a slightly "weaker" way,
    that has some risk of missing code paths, but will likely suffice.

    That is, initialize to a distinguished value like 0 or -1
     and get rid of the booleans. And, i necessary for pickling,
     put the fields back out in "public".


 The name of the ImageInit module, I wonder what it should be.


   - Jay
     


________________________________

Date: Thu, 7 Aug 2008 21:59:07 -0400
From: rcoleburn at scires.com
To: m3devel at elegosoft.com; jayk123 at hotmail.com; dabenavidesd at yahoo.es
Subject: RE: [M3devel] pixmap problem (some success)



Jay,



The splash screen is not the major issue.  The pixmaps used for boolean choices, radio choices, numerics, etc. get enlarged to the point that some windows won't fit on the screen.  Also, it looks really bad--like both a first-grader with a big marker and a college-student with a fine tip pencil worked on the same window.



I've tried very hard to make Trestle/FormsVBT look and act like Windows GUI, but it is indeed different.  For example, on menus, you have to hold down the mouse to keep the menu open.  All these were small issues 10 years ago, but now they seem to be looming large in the customer's mind.



So, bottom line is that if I can't fix what they deem to be functional problems, they will indeed call for a rewrite.



Now that we've got the typein problem solved (thanks Olaf) and are on track for the pixmap issue, I feel better.  I have recently discovered that the numeric keys on the numeric keypad aren't accepted, so I have yet to track that problem down.



As for your idea of using a variable as the default initializer for xres/yres, this is not legal Modula-3.  You will get a compile error that the default is not constant.  Otherwise, it was a good idea.



Since Raw is an object and objects are created dynamically and new subtypes can be created (inheritance), I think the problem of how to properly set xres/yres is complicated.



Seems like what we need is some way to adjust these fields when the object is created initially.  Alas, Raw does not have an init() method!



Regards,

Randy

>>> Jay  8/7/2008 9:35 PM>>>

Computing the values is probably easy. It appears we already have the code to do that -- the program I had you run and report the numbers.

It is true there is a *small* problem of computing them early enough, but..yeah, I expect that's just done in the module initializer. I really don't like "global initialization" code ala C++ global constructors/destructors, but Modula-3 is rife with them and they aren't going away, so I'll just pile in a few more bits.

I don't know if is legal Modula-3 code, but if fields can be initialized from globals, that's about all it takes.

SOMETHING LIKE (don't castigate me where I am wrong)
In the platform-independent code, add two private globals:
DefaultXRes : INTEGER;
DefaultYRes : INTEGER;

heck, default them to 75, for the Posix case.

In the platform independent interface, functions to set them:
PROCEDURE SetDefaultXRes(a: INTEGER);
PROCEDURE SetDefaultYRes(a: INTEGER);

Nothing else on Posix, for now.

On Windows, add another module WinImage.m3 that imports Image and just has a module initializer:

BEGIN
  Image.SetDefaultXRes(ComputedSomehowNotDifficult());
  Image.SetDefaultYRes(ComputedSomehowNotDifficult());
END.

If fields cannot be initialized from globals (or function calls..heh, that has a niceness!), then you have to search out all the uses and change them to function calls, possibly a lot, possibly tedious, definitely a "breaking change", but probably just fine, really.

And then, if fields can be initialized from functions, that'd be better -- that way no module initializer.


Module initializers are "bad" in that they cause a startup cost for "everyone", even if they aren't needed for a particular scenario. It is "best" imho to have constant initialization as much as possible, and where values must be computed, use an explicit function call when needed. You can still cache the values upon first computation.


> would seem that most code must not be computing these, but relying on the default values to be correct.

Or that "most code" doesn't care what the values are, doesn't use them at all.
Like, maybe they are only used for pixmaps and not text or lines?

Anyway, I can't look into this now, but hopefully "soon".
If your customer is antsy, "the problem is mostly understood and a fix will definitely be available soon".
I think "patch Tuesday" is coming up. Let's make it by then? :)


Really, I can't believe they'd call for a rewrite over this small issue.
Presumably they really want the rewrite and are looking for any excuse they can find.
Also, if you removed the "advertising" from the splash screen, they might not have even noticed?
Or, I guess if this is Windows only, the odd look could not be noticed.
But if they also want it on X and you showed it there, and it looked the same on Windows, well...
(Really this is just a general dilemna -- app looks the same as app on all platforms, or app looks like the platform on all platforms.)


- Jay

________________________________

Date: Thu, 7 Aug 2008 20:26:13 -0400
From: rcoleburn at scires.com
To: m3devel at elegosoft.com; jayk123 at hotmail.com; dabenavidesd at yahoo.es
Subject: RE: [M3devel] pixmap problem (some success)



Well, I hope to soon share your optimism for "easy".



Since these numbers wind up being default values for the xres/yres and since changing the defaults has made a big difference in the results, it would seem that most code must not be computing these, but relying on the default values to be correct.



Since these numbers may be different for every program run on a different monitor (potentially), the question becomes how to effect a change that will work in all cases without having to recompile vbtkit.



Does this mean we have to track down each use of Image.Raw and put in code to compute the dpi?  Or is there some way we can do this during an initialization sequence? but alas, how to deal with the defaults supplied in the declaration?



Regards,

Randy

>>> Jay  8/7/2008 8:16 PM>>>

Awesome. I expect it is easy from here. Thanks David!

I *assume* the 75 should have been 86 in the one case,
but close enough that nobody noticed.
So these numbers come pretty directly from the GetDeviceCaps / GetSystemMetrics.

And then X Windows too.
Does anyone have a high DPI monitor running X Windows?
Probably easy enough to do this blind.

I'm trying to ignore the fact that systems have multiple
monitors, with varying dpi. You are supposed to loop your
drawing over monitors and compute what it looks like per-monitor.
I'm just making that up, right? :)

- Jay

________________________________

Date: Thu, 7 Aug 2008 19:42:33 -0400
From: rcoleburn at scires.com
To: m3devel at elegosoft.com; jayk123 at hotmail.com; dabenavidesd at yahoo.es
Subject: Re: [M3devel] pixmap problem (some success)



Ok, I solved the Microsoft problem.



Here are the results on Dell M4300 at 1920x1200:



horizonal pixels 1920
veritical pixels SM_CYSCREEN 1200
horizontal millimeters 330
veritical millimeters 206
horizontal pixels per millimeter 5.818182
vertical pixels per millimeter 5.825243
horizontal pixels per inch 147.781818
vertical pixels per inch 147.961165

Wow!  these numbers are radically different than the IBM T60 at 1280x1024:



horizonal pixels 1280
veritical pixels SM_CYSCREEN 1024
horizontal millimeters 375
veritical millimeters 300
horizontal pixels per millimeter 3.413333
vertical pixels per millimeter 3.413333
horizontal pixels per inch 86.698667
vertical pixels per inch 86.698667

Now, if you look at the Windows dpi setting for the 1920x1200 machine, it says 96dpi, but this is in the General tab of the Display properties Advanced settings.  I suspect this is just the dpi setting applied to fonts.



I tried plugging the numbers into Image.i3 as suggested by Daniel:

TYPE
  Raw = OBJECT
      width, height: INTEGER;
      xres: REAL := 147.781818; (* in pixels per inch *)
      yres: REAL := 147.961165; (* in pixels per inch *)
    METHODS
      get (h, v: INTEGER): Pixel;
      set (h, v: INTEGER; pixel: Pixel);
    END;

When I do this, my pixmaps look correct on the 1920x1200 display!!!!!



Now, the problem I am faced with is how to come up with a way that the code will work on any type of monitor.  I can't edit Image.i3 for every resolution and produce a different binary.  Any ideas?



Regards,

Randy


>>> Jay  8/5/2008 9:01 AM>>>


Randy, I'm pretty clueless here.
I don't do gui or graphics.
If anyone has a clue, please stand up.
If you can get us code to run, please do.
But I think I need multiple particularly configured machines too.

I'm curious what this code prints on the systems:

#include
#include

int main()
{
int pix_ver = { 0 };
int pix_hor = { 0 };
int mm_hor = { 0 };
int mm_ver = { 0 };
HWND hwnd = { 0 };
HDC hdc = { 0 };

hwnd = GetDesktopWindow();
hdc = GetDC(hwnd);
mm_hor = GetDeviceCaps(hdc, HORZSIZE);
mm_ver = GetDeviceCaps(hdc, VERTSIZE);
pix_hor = GetSystemMetrics(SM_CXSCREEN);
pix_ver = GetSystemMetrics(SM_CYSCREEN);

printf("horizonal pixels %d\n", pix_hor);
printf("veritical pixels SM_CYSCREEN %d\n", pix_ver);
printf("horizontal millimeters %d\n", mm_hor);
printf("veritical millimeters %d\n", mm_ver);

printf("horizontal pixels per millimeter %f\n", (((float) pix_hor) / ((float) mm_hor)));
printf("vertical pixels per millimeter %f\n", (((float) pix_ver) / ((float) mm_ver)));

printf("horizontal pixels per inch %f\n", (((float) pix_hor) / ((float) mm_hor) * 10.0 * 2.54));
printf("vertical pixels per inch %f\n", (((float) pix_ver) / ((float) mm_ver) * 10.0 * 2.54));

return 0;
}


for me:

$ gcc dpi.c -luser32 -lgdi32

jay at jay-win9 /dev2/j/dpi
$ ./a
horizonal pixels 1280
veritical pixels SM_CYSCREEN 800
horizontal millimeters 384
veritical millimeters 240
horizontal pixels per millimeter 3.333333
vertical pixels per millimeter 3.333333
horizontal pixels per inch 84.666667
vertical pixels per inch 84.666667

(Visual C++ is fine:
cl dpi.c user32.lib gdi32.lib
.\dpi
)

I wonder if lying in this code:

Searching for 'GetDeviceCaps'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(25): VAR res := NEW(T); n_colors := GetDeviceCaps (WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(32): res.depth := GetDeviceCaps(WinGDI.BITSPIXEL); (* John Karnak 8/3/98 *)
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(68): mm_hor = GetDeviceCaps (WinGDI.HORZSIZE),
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(69): mm_ver = GetDeviceCaps (WinGDI.VERTSIZE) DO

Searching for 'res.res[Axis.T.'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(71): res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(72): res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);


D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(89):PROCEDURE GetDeviceCaps (cap: Ctypes.int): INTEGER =
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(93): res := WinGDI.GetDeviceCaps (hdc, cap);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(98): END GetDeviceCaps;
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnColorMap.m3(268): cnt := WinGDI.GetDeviceCaps (hdc, WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnFont.m3(316): LogicalPixelsPerVertInch := WinGDI.GetDeviceCaps(er.hdc, WinGDI.LOGPIXELSY);
9 occurrence(s) have been found.


Searching for '1000.0'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(463): bmih.biXPelsPerMeter := ROUND (st.res[Axis.T.Hor] * 1000.0);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(464): bmih.biYPelsPerMeter := ROUND (st.res[Axis.T.Ver] * 1000.0);


and just claiming 96dpi is the way to go.
Can you try that??


Specifically try setting res.res[Axis.T.Hor] and .Ver to 3.779527559055118.
Or heck to 3.3333 like my laptop has.


Or maybe claiming ignorance and setting biXPelsPerMeter and biYPelsPerMeter to 0???
Claiming ignorance feels better than lying of course. :)

Hm, so throw in also:

printf("LogicalPixelsX %u\n", GetDeviceCaps(hdc, LOGPIXELSX));
printf("LogicalPixelsY %u\n", GetDeviceCaps(hdc, LOGPIXELSY));

I get the magic number 96.

- Jay




From rcoleburn at scires.com  Sat Aug  9 07:48:15 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Sat, 09 Aug 2008 01:48:15 -0400
Subject: [M3devel] pixmap problem (! big success !)
In-Reply-To: <COL101-W49AB1574C557B5343D724DE6740@phx.gbl>
References: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>
	<489B5023.1E75.00D7.1@scires.com>
	<COL101-W279710F3EF9B814B1DA853E6740@phx.gbl>
	<489B5A5F.1E75.00D7.1@scires.com>
	<COL101-W76DCEA23FC2EA0FD299A3DE6740@phx.gbl>
	<489B7025.1E75.00D7.1@scires.com>
	<COL101-W49AB1574C557B5343D724DE6740@phx.gbl>
Message-ID: <489CF759.1E75.00D7.1@scires.com>

Jay:
 
Thanks so much for your work on this issue!!!  In my sleep-deprived state I didn't think of switching these fields to be "accessor-based."
 
I've tested your changes and they seem to work fine for me.  I've rebuilt all of cm3 just to make sure there were no compile-time errors.
 
I also had to adjust my scroll bar implementation on Windows to scale the scroll bar slider.  (The slider was not a pixmap and was being drawn based on a default size in millimeters.  Since the arrow buttons at the top and bottom of the scroll bar are pixmaps, I had to ensure the slider and margins didn't exceed the width of these pixmaps.)  Your procedures in ImageInit made this easy for me.  The revised code is now checked into the repository.
 
I probably need to make the same fix to the slider in the Posix implementation, but since we aren't yet dealing with resolution differences on Posix, maybe it doesn't matter for now.  Also, there are no arrow buttons on the Posix scroll bar, so it will probably be okay to just let the slider be the default width in millimeters.  The reason I had trouble on Windows was that the slider was wider than the arrow pixmaps when rendered on the hi-res display.
 
After reflecting on your comments and discussion, I will volunteer with your kind permission to adjust your Image.i3/Image.m3 implementation to be "more in the spirit of Modula-3".  Namely, I do think it makes sense to make these fields truly opaque so that access must be governed by the methods.  I feel pretty good about the fact that your change didn't break any of the rest of the code in the cm3 tree, so I think there will be few, if any, code breaks in other client code.
 
Also, I did notice that in ImageInit.m3 you declare a global var "init" but never assign the default value of "FALSE" to this variable before it is tested in the two procedures.  Shouldn't this be set to FALSE, or are you relying on something of which I'm unaware?  
 
Also, in ImageInit.m3 you call WinNT.MemoryBarrier().  I looked in the WinNT.i3 file, but there is no comment describing this function.  I'm unfamiliar with this function, so I would welcome any explanation you can offer as to what it does.
 
As for pickles, I don't see how any of your changes would break pickles.  The pickler should still be able to pickle these types.  Of course, anyone who is using pickles will need to recompile to see the new format, but there should not be any source code changes required.
 
I also need to thank Daniel for cluing us into the pixmap scaling problem in the first place by pointing out the xres/yres constants of 75.0.
 
At some point, I do think it makes sense to make a similar set of fixes on Posix because I'm sure that the 75 dpi is not going to be accurate for most modern displays.  Of course, we will need to find a way to come up with the right value in a platform-independent way.
 
Regards,
Randy

>>> Jay <jayk123 at hotmail.com> 8/8/2008 10:05 AM >>>

I committed a possible fix here.
Please see how it fairs.

I have a few Modula-3 questions related to the fix.

- Did I have to expose the functions in the .i3 file
  that implement the methods? That seems "wrong".


   - Could I have used "stronger language opacity" instead
    of "informal privacy"? That is, could I have used an
    opaque type?

   - Will the change break pickles?
     "Both" due to the addition of data "or" methods?
     ie: What breaks pickles?
     Do I need to think in the mindset of
      C:
       typedef struct {
         int a,b;
       } foo_t;

       foo_t f;
       fwrite(&f, sizeof(f), 1, file);

      and not breaking such code? 
     Only if the type is "branded"? Or if types derived from it are branded?
        There could be derived types not in the cm3 tree though.
        How much do we care about breaking code outside the cm3 tree?
        e.g. in this change, I had to change every use of .xres and .yres.
       I did that, but only in the code "we have". There could be more out there.
       Personally, I get quite frustrated by this issue. I'm very willng to "fix"
        and maybe test pretty large amounts of code -- pay the price for fixing things with
        "breaking" changes, or else not make the change, but if I don't have the code, I can't.

  If this breaks pickles, I can restate the fix in a slightly "weaker" way,
    that has some risk of missing code paths, but will likely suffice.

    That is, initialize to a distinguished value like 0 or -1
     and get rid of the booleans. And, i necessary for pickling,
     put the fields back out in "public".


The name of the ImageInit module, I wonder what it should be.


   - Jay
     


________________________________

Date: Thu, 7 Aug 2008 21:59:07 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com; jayk123 at hotmail.com; dabenavidesd at yahoo.es 
Subject: RE: [M3devel] pixmap problem (some success)



Jay,



The splash screen is not the major issue.  The pixmaps used for boolean choices, radio choices, numerics, etc. get enlarged to the point that some windows won't fit on the screen.  Also, it looks really bad--like both a first-grader with a big marker and a college-student with a fine tip pencil worked on the same window.



I've tried very hard to make Trestle/FormsVBT look and act like Windows GUI, but it is indeed different.  For example, on menus, you have to hold down the mouse to keep the menu open.  All these were small issues 10 years ago, but now they seem to be looming large in the customer's mind.



So, bottom line is that if I can't fix what they deem to be functional problems, they will indeed call for a rewrite.



Now that we've got the typein problem solved (thanks Olaf) and are on track for the pixmap issue, I feel better.  I have recently discovered that the numeric keys on the numeric keypad aren't accepted, so I have yet to track that problem down.



As for your idea of using a variable as the default initializer for xres/yres, this is not legal Modula-3.  You will get a compile error that the default is not constant.  Otherwise, it was a good idea.



Since Raw is an object and objects are created dynamically and new subtypes can be created (inheritance), I think the problem of how to properly set xres/yres is complicated.



Seems like what we need is some way to adjust these fields when the object is created initially.  Alas, Raw does not have an init() method!



Regards,

Randy

>>> Jay  8/7/2008 9:35 PM>>>

Computing the values is probably easy. It appears we already have the code to do that -- the program I had you run and report the numbers.

It is true there is a *small* problem of computing them early enough, but..yeah, I expect that's just done in the module initializer. I really don't like "global initialization" code ala C++ global constructors/destructors, but Modula-3 is rife with them and they aren't going away, so I'll just pile in a few more bits.

I don't know if is legal Modula-3 code, but if fields can be initialized from globals, that's about all it takes.

SOMETHING LIKE (don't castigate me where I am wrong)
In the platform-independent code, add two private globals:
DefaultXRes : INTEGER;
DefaultYRes : INTEGER;

heck, default them to 75, for the Posix case.

In the platform independent interface, functions to set them:
PROCEDURE SetDefaultXRes(a: INTEGER);
PROCEDURE SetDefaultYRes(a: INTEGER);

Nothing else on Posix, for now.

On Windows, add another module WinImage.m3 that imports Image and just has a module initializer:

BEGIN
  Image.SetDefaultXRes(ComputedSomehowNotDifficult());
  Image.SetDefaultYRes(ComputedSomehowNotDifficult());
END.

If fields cannot be initialized from globals (or function calls..heh, that has a niceness!), then you have to search out all the uses and change them to function calls, possibly a lot, possibly tedious, definitely a "breaking change", but probably just fine, really.

And then, if fields can be initialized from functions, that'd be better -- that way no module initializer.


Module initializers are "bad" in that they cause a startup cost for "everyone", even if they aren't needed for a particular scenario. It is "best" imho to have constant initialization as much as possible, and where values must be computed, use an explicit function call when needed. You can still cache the values upon first computation.


> would seem that most code must not be computing these, but relying on the default values to be correct.

Or that "most code" doesn't care what the values are, doesn't use them at all.
Like, maybe they are only used for pixmaps and not text or lines?

Anyway, I can't look into this now, but hopefully "soon".
If your customer is antsy, "the problem is mostly understood and a fix will definitely be available soon".
I think "patch Tuesday" is coming up. Let's make it by then? :)


Really, I can't believe they'd call for a rewrite over this small issue.
Presumably they really want the rewrite and are looking for any excuse they can find.
Also, if you removed the "advertising" from the splash screen, they might not have even noticed?
Or, I guess if this is Windows only, the odd look could not be noticed.
But if they also want it on X and you showed it there, and it looked the same on Windows, well...
(Really this is just a general dilemna -- app looks the same as app on all platforms, or app looks like the platform on all platforms.)


- Jay

________________________________

Date: Thu, 7 Aug 2008 20:26:13 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com; jayk123 at hotmail.com; dabenavidesd at yahoo.es 
Subject: RE: [M3devel] pixmap problem (some success)



Well, I hope to soon share your optimism for "easy".



Since these numbers wind up being default values for the xres/yres and since changing the defaults has made a big difference in the results, it would seem that most code must not be computing these, but relying on the default values to be correct.



Since these numbers may be different for every program run on a different monitor (potentially), the question becomes how to effect a change that will work in all cases without having to recompile vbtkit.



Does this mean we have to track down each use of Image.Raw and put in code to compute the dpi?  Or is there some way we can do this during an initialization sequence? but alas, how to deal with the defaults supplied in the declaration?



Regards,

Randy

>>> Jay  8/7/2008 8:16 PM>>>

Awesome. I expect it is easy from here. Thanks David!

I *assume* the 75 should have been 86 in the one case,
but close enough that nobody noticed.
So these numbers come pretty directly from the GetDeviceCaps / GetSystemMetrics.

And then X Windows too.
Does anyone have a high DPI monitor running X Windows?
Probably easy enough to do this blind.

I'm trying to ignore the fact that systems have multiple
monitors, with varying dpi. You are supposed to loop your
drawing over monitors and compute what it looks like per-monitor.
I'm just making that up, right? :)

- Jay

________________________________

Date: Thu, 7 Aug 2008 19:42:33 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com; jayk123 at hotmail.com; dabenavidesd at yahoo.es 
Subject: Re: [M3devel] pixmap problem (some success)



Ok, I solved the Microsoft problem.



Here are the results on Dell M4300 at 1920x1200:



horizonal pixels 1920
veritical pixels SM_CYSCREEN 1200
horizontal millimeters 330
veritical millimeters 206
horizontal pixels per millimeter 5.818182
vertical pixels per millimeter 5.825243
horizontal pixels per inch 147.781818
vertical pixels per inch 147.961165

Wow!  these numbers are radically different than the IBM T60 at 1280x1024:



horizonal pixels 1280
veritical pixels SM_CYSCREEN 1024
horizontal millimeters 375
veritical millimeters 300
horizontal pixels per millimeter 3.413333
vertical pixels per millimeter 3.413333
horizontal pixels per inch 86.698667
vertical pixels per inch 86.698667

Now, if you look at the Windows dpi setting for the 1920x1200 machine, it says 96dpi, but this is in the General tab of the Display properties Advanced settings.  I suspect this is just the dpi setting applied to fonts.



I tried plugging the numbers into Image.i3 as suggested by Daniel:

TYPE
  Raw = OBJECT
      width, height: INTEGER;
      xres: REAL := 147.781818; (* in pixels per inch *)
      yres: REAL := 147.961165; (* in pixels per inch *)
    METHODS
      get (h, v: INTEGER): Pixel;
      set (h, v: INTEGER; pixel: Pixel);
    END;

When I do this, my pixmaps look correct on the 1920x1200 display!!!!!



Now, the problem I am faced with is how to come up with a way that the code will work on any type of monitor.  I can't edit Image.i3 for every resolution and produce a different binary.  Any ideas?



Regards,

Randy


>>> Jay  8/5/2008 9:01 AM>>>


Randy, I'm pretty clueless here.
I don't do gui or graphics.
If anyone has a clue, please stand up.
If you can get us code to run, please do.
But I think I need multiple particularly configured machines too.

I'm curious what this code prints on the systems:

#include
#include

int main()
{
int pix_ver = { 0 };
int pix_hor = { 0 };
int mm_hor = { 0 };
int mm_ver = { 0 };
HWND hwnd = { 0 };
HDC hdc = { 0 };

hwnd = GetDesktopWindow();
hdc = GetDC(hwnd);
mm_hor = GetDeviceCaps(hdc, HORZSIZE);
mm_ver = GetDeviceCaps(hdc, VERTSIZE);
pix_hor = GetSystemMetrics(SM_CXSCREEN);
pix_ver = GetSystemMetrics(SM_CYSCREEN);

printf("horizonal pixels %d\n", pix_hor);
printf("veritical pixels SM_CYSCREEN %d\n", pix_ver);
printf("horizontal millimeters %d\n", mm_hor);
printf("veritical millimeters %d\n", mm_ver);

printf("horizontal pixels per millimeter %f\n", (((float) pix_hor) / ((float) mm_hor)));
printf("vertical pixels per millimeter %f\n", (((float) pix_ver) / ((float) mm_ver)));

printf("horizontal pixels per inch %f\n", (((float) pix_hor) / ((float) mm_hor) * 10.0 * 2.54));
printf("vertical pixels per inch %f\n", (((float) pix_ver) / ((float) mm_ver) * 10.0 * 2.54));

return 0;
}


for me:

$ gcc dpi.c -luser32 -lgdi32

jay at jay-win9 /dev2/j/dpi
$ ./a
horizonal pixels 1280
veritical pixels SM_CYSCREEN 800
horizontal millimeters 384
veritical millimeters 240
horizontal pixels per millimeter 3.333333
vertical pixels per millimeter 3.333333
horizontal pixels per inch 84.666667
vertical pixels per inch 84.666667

(Visual C++ is fine:
cl dpi.c user32.lib gdi32.lib
.\dpi
)

I wonder if lying in this code:

Searching for 'GetDeviceCaps'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(25): VAR res := NEW(T); n_colors := GetDeviceCaps (WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(32): res.depth := GetDeviceCaps(WinGDI.BITSPIXEL); (* John Karnak 8/3/98 *)
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(68): mm_hor = GetDeviceCaps (WinGDI.HORZSIZE),
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(69): mm_ver = GetDeviceCaps (WinGDI.VERTSIZE) DO

Searching for 'res.res[Axis.T.'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(71): res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(72): res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);


D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(89):PROCEDURE GetDeviceCaps (cap: Ctypes.int): INTEGER =
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(93): res := WinGDI.GetDeviceCaps (hdc, cap);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScreenType.m3(98): END GetDeviceCaps;
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnColorMap.m3(268): cnt := WinGDI.GetDeviceCaps (hdc, WinGDI.NUMCOLORS);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnFont.m3(316): LogicalPixelsPerVertInch := WinGDI.GetDeviceCaps(er.hdc, WinGDI.LOGPIXELSY);
9 occurrence(s) have been found.


Searching for '1000.0'...
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(463): bmih.biXPelsPerMeter := ROUND (st.res[Axis.T.Hor] * 1000.0);
D:\dev2\cm3.2\m3-ui\ui\src\winvbt\WinScrnPixmap.m3(464): bmih.biYPelsPerMeter := ROUND (st.res[Axis.T.Ver] * 1000.0);


and just claiming 96dpi is the way to go.
Can you try that??


Specifically try setting res.res[Axis.T.Hor] and .Ver to 3.779527559055118.
Or heck to 3.3333 like my laptop has.


Or maybe claiming ignorance and setting biXPelsPerMeter and biYPelsPerMeter to 0???
Claiming ignorance feels better than lying of course. :)

Hm, so throw in also:

printf("LogicalPixelsX %u\n", GetDeviceCaps(hdc, LOGPIXELSX));
printf("LogicalPixelsY %u\n", GetDeviceCaps(hdc, LOGPIXELSY));

I get the magic number 96.

- Jay



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080809/00e22eca/attachment-0002.html>

From rodney.bates at wichita.edu  Sat Aug  9 17:45:45 2008
From: rodney.bates at wichita.edu (Rodney M. Bates)
Date: Sat, 09 Aug 2008 10:45:45 -0500
Subject: [M3devel] pixmap problem (some success)
In-Reply-To: <COL101-W49AB1574C557B5343D724DE6740@phx.gbl>
References: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>
	<489B5023.1E75.00D7.1@scires.com>
	<COL101-W279710F3EF9B814B1DA853E6740@phx.gbl>
	<489B5A5F.1E75.00D7.1@scires.com>
	<COL101-W76DCEA23FC2EA0FD299A3DE6740@phx.gbl>
	<489B7025.1E75.00D7.1@scires.com>
	<COL101-W49AB1574C557B5343D724DE6740@phx.gbl>
Message-ID: <489DBBA9.8020109@wichita.edu>



Jay wrote:
> I committed a possible fix here.
> Please see how it fairs.
> 
> I have a few Modula-3 questions related to the fix.
> 
>  - Did I have to expose the functions in the .i3 file
>   that implement the methods? That seems "wrong".
> 
> 
>    - Could I have used "stronger language opacity" instead
>     of "informal privacy"? That is, could I have used an
>     opaque type?

I have a number of comments on this.
Here are 3 examples of different styles of coding in Modula-3.

---------------------------------------------------------------------------------
INTERFACE M1
; TYPE T <: REFANY
; PROCEDURE Op ( Arg : T )
; END M1 .

MODULE M1
; REVEAL T = BRANDED REF RECORD (
                * Fields of T, hidden from clients. *)
              END (* T *)
; PROCEDURE Op ( Arg : T ) = (* A body that uses the fields of T. *)
; BEGIN END M1 .

; MODULE Client1 EXPORTS Main
; IMPORT M1
; VAR Obj := NEW ( M1 . T )
; BEGIN
     M1 . Op ( Obj )
   END Client1 .

I would call this the _abstract data type_ style.  It uses a plain procedure Op,
not a method.  The type T is opaque in the interface, so clients can manipulate
values of it only by calling Op (and, presumably, other procedures whose signatures
would also be given in the interface).

-------------------------------------------------------------------------------
INTERFACE M2
; TYPE T <: Public
; TYPE Public = OBJECT METHODS op ( ) (* No default method body given here. *)
                 END (* Public *)
; END M2 .

MODULE M2
; REVEAL T = Public BRANDED OBJECT (* Same fields as M1.T. *)
                     OVERRIDES op := Op (* Provide the method body for op. *)
                     END (* T *)
; PROCEDURE Op ( Arg : T ) = (* Pretty much the same as M1.Op, maybe even exactly. *)
; BEGIN END M2 .

; MODULE Client2 EXPORTS Main
; IMPORT M2
; VAR Obj : M2 . T := NEW ( M2 . T )
; BEGIN
     Obj . op ( )
   END Client2 .

This is the OO style.  The operation is an overridable method.  Clients can still
manipulate objects of type T only by using the operation op, but here, op is a
method, not a procedure, so they must use a method call.  It will dispatch, but
without further code, it will always dispatch to M2.Op.

But, if client code were to:
1) declare a subtype Sub, of M2.T,
2) which has a method override for op, say procedure OpSub,
3) provide OpSub,
4) then allocate an object of type Sub,
5) but assign this object to variable Client2.Obj (whose type is M2.T, not Sub),
then the method call Obj.op() would dispatch to OpSub.

-------------------------------------------------------------------------------
Here is a side point that I think is confusing about Modula-3 opaque types.  At least
it took me years to fully understand.  The same subtype mechanism is used in Modula-3
in two different ways.  One is for creating a hierarchy of dynamically typed objects.
This is the usual OO use.  The other is in opaque types.  When used in the usual way,
actual objects of opaque type Public are never allocated.  Public is only a static
structure to hold the subset of the properties of type T that are known everywhere.

When you execute NEW(M2.T), you get a complete object of type T, with all its fields and
method overrides, even though you are in a context where these are not known.  In a
sense, these things are hidden only from the programmer of this client code.  But the
compiler may have to know at least some of the hidden information at the site of the
NEW call.

(Actually, through clever implementation techniques, I think the compiler needs to
know at most the size of fully revealed type T and could probably do without that.
The messages about recompiling modules because of new opaque info are, I am sure,
the compiler generating better code by using revelations it didn't have the first time.)

-------------------------------------------------------------------------------
INTERFACE M3
; TYPE T <: Public
; TYPE Public = OBJECT METHODS op ( )
                                := Op (* Specify the body of op, here in the interface. *)
                 END (* Public *)
; PROCEDURE Op ( Arg : T ) = (* A body that uses the fields of T. *)
; END M3 .

MODULE M3
; REVEAL T = Public BRANDED OBJECT (* Same fields as M1.T and M2.T. *)
                     (* No override for op needed. Its body was already
                        given in type Public. *)
                     END T
; PROCEDURE Op ( Arg : T ) = (* Pretty much the same as M1.Op. *)
; BEGIN END M3 .

; MODULE Client3 EXPORTS Main
; IMPORT M3
; VAR Obj := NEW ( M3 . T )
; BEGIN
     Obj . op ( )
   ; M3 . Op ( Obj )
   END Client3 .

This is a hybrid.  Still opaque, as before.  But a client can either call plain
procedure M3.Op, which will be statically known to always invoke Op, or a method
call on op, which might  dispatch to Op or OpSub, if the latter exists.

------------------------------------------------------------------------------------
An OO purist would say that every programmer-defined type should be opaque, hiding its
fields, and that every operation should always be a method, in case some later code
has a need to create a subtype and override the methods.

The problem with (dispatching) methods is it makes tracking down bugs a nightmare.  The
whole abstraction idea works great when designing one layer at a time, or even testing
one layer at a time.  But when you have a specific bug, you can't do it a layer at a time.
You often have to trace, mentally or with actual execution, in and out of the calls and
returns, through the layers.

If you see a procedure call, it is statically known and quite direct, at least in a
modular language, to find the code that is called.  Every time you see a method call,
there is a big tangential process to try to figure out if there are overrides, what
subtype the object might be, etc., and the results may be dynamic.  This can make an
otherwise sstraightforward process extremely tedious.

I am a strong believer in using methods when there is a good reason, i.e., you know
or reasonably suspect there will be a need to actually create overrides and have
nontrivial dispatching happen.  Otherwise, stick to static procedure calls.  The
pickle code, for example, uses methods all over the place.  Nearly all of them always
dispatch to exactly one place, but for each such, it takes a lot of work to ascertain
this.  It is very hard code to vet.

-------------------------------------------------------------------------------------
The hybrid approach, perhaps surprisingly, is sometimes very useful.  For example,
you have a complex tree with several node types that are different subtypes of a
common parent node type.  In some places, you have a node pointer that could be
any of the subtypes.  Then you would want to make a method call.  In other places,
you already know exactly what type node you have, perhaps because you are inside
a TYPECASE or a procedure that was already dispatched-to.  Here, I prefer to use
a non-dispatching call.  Aside from saving a tiny bit of runtime overhead for the
dispatch (which is minor), you avoid the debug problem above.


> 
>    - Will the change break pickles?
>      "Both" due to the addition of data "or" methods?
>      ie: What breaks pickles?
>      Do I need to think in the mindset of
>       C:
>        typedef struct {
>          int a,b;
>        } foo_t;
> 
>        foo_t f;
>        fwrite(&f, sizeof(f), 1, file);
> 
>       and not breaking such code? 
>      Only if the type is "branded"? Or if types derived from it are branded?
>         There could be derived types not in the cm3 tree though.
>         How much do we care about breaking code outside the cm3 tree?
>         e.g. in this change, I had to change every use of .xres and .yres

If by "break pickles" you mean invalidating existing pickle _data_ that was written
before the change, then yes.  When reading an object from a pickle, the reading
program must contain a type that is exactly the same type as was used to write
the object.  So if the program that reads the pickle is recompiled after the change,
then existing pickle data will have to be rewritten.

A change to anything that is a property of a type, according to the rules of
the language, will cause this.  For example, changes in brandedness, changes in
the string value of the brand, or, probably, the use of an anonymous brand would
all change the type.  Note that the full revelation of any opaque type is required
by the language to be branded, though not necessarily with a string value.

Also, note that the names of fields are part of a record or object type, so
changing .xres to a different name will invalidate existing pickle data.  This
does not necessarily mean it's a bad idea.

On the other hand, if you are willing/able to recompile and rerun both the program
that writes and the program that reads the pickle data, such changes will work fine.
Neither the source code in the Pickle library nor its client code will break.

We definitely do care about breaking code outside the cm3 tree.  Randy's application
would be a good example.  So removing functions, constants, etc. just because they
are unused in cm3 would not be good.  Nor would merging differently-named things,
just because they always have the same properties in cm3, because they could have
different properties in other code.


-- 
-------------------------------------------------------------
Rodney M. Bates, retired assistant professor
Dept. of Computer Science, Wichita State University
Wichita, KS 67260-0083
316-978-3922
rodney.bates at wichita.edu


From jayk123 at hotmail.com  Sat Aug  9 20:41:36 2008
From: jayk123 at hotmail.com (Jay)
Date: Sat, 9 Aug 2008 18:41:36 +0000
Subject: [M3devel] pixmap problem (some success)
In-Reply-To: <489DBBA9.8020109@wichita.edu>
References: <COL101-W60D19878475331A6E0160EE67B0@phx.gbl>
	<489B5023.1E75.00D7.1@scires.com>
	<COL101-W279710F3EF9B814B1DA853E6740@phx.gbl>
	<489B5A5F.1E75.00D7.1@scires.com>
	<COL101-W76DCEA23FC2EA0FD299A3DE6740@phx.gbl>
	<489B7025.1E75.00D7.1@scires.com>
	<COL101-W49AB1574C557B5343D724DE6740@phx.gbl> 
	<489DBBA9.8020109@wichita.edu>
Message-ID: <COL101-W25A5930EE4E6CFB7E6BA7AE6770@phx.gbl>


Thanks Rodney, good summary. I have been "almost aware" of much of this.I didn't think you could derive from opaque types for some reason.
So I instead relied on "gentleman's agreement", naming things "private".
Like how Modula-3 doesn't have constructors, but relies on people to call "init".Randy, go ahead and change what you want. I don't like red tape myself.
  You're welcome and definitely thanks to David.
Regarding pickles, are we to consider all types as likely to be pickled?
And therefore we are very stuck unable to change?Or only branded types? Or ...?
Or we don't believe people build up significant investment in pickle files
and can throw them all away upon rebuilding their code from current source?
 
This change could be restarted without breaking pickles.
As it is currently stated, it deliberately breaks existing code in order to
be certain the fix works, to be absolutely sure the wrong values aren't used.
That is, I didn't want to rely on any particular preexisting function call
being made before the values are read. There is no way to do that
given the "fully unprotected" form that was there before.
 
Agreed -- layering is great for design, and "agility" (ability to change),
but more code = more bugs, more code = more code to read when debugging,
more code = more code to understand when maintaining.
 
I don't think you need to know the size of things at the NEW site.
In a general "if I were designing the system" sense, not in the
"I know how Modula-3 works" (I don't yet).
NEW(T) could include within it a function call, or global read, to get the size of T.
Or heck, NEW(T) could call a function that passes the size on to
the next level down.
That is, in C, it could look like one of:
 
original code:
client:
 T* t = NEW(T) 
 
option 1 - function call
client:
T* t = (T*) malloc(GetSizeOfT());
 
implementation:
size_T GetSizeOfT() { return 42; }
 
option 2 - global read 
client:
T* t = (T*) malloc(SizeOfT);
 
implementation:
extern const SizeOfT = 42;
 
option 3 - 
client:
T* t = NewT();
 
implementation:
T* NewT(void) { return (T*) malloc(sizeof(T)); }
 
The compiler could go back later and recompile things to
client, or sometimes it could do this the first time:
t = (T*) malloc(sizeof(T));
 
Though option 3 potentially generates smaller code, if there are
many places that make a T.
This is just the usual "inlining can bloat code size" point.
"Make functions out of frequently occuring blocks of code
to reduce code size".
 
Option 3 becomes "better" as there are more used default
field initializers.
That is:
T = RECORD
  a := 1; b:= 2; c:=3; d:=4;e:=5;f:=6;
END;
 
If there are lots of NEW(T), without
replacements for the initial values (not sure you can do that,
but I think so), then one function to call malloc and fill in
all the values could be a win over inlining the initialization
everywhere, due to code size.
 
Code size is usually important for performance.
You want the code to be small to fit in cache.
And to reduce the cost of paging it in.
 
 - Jay> Date: Sat, 9 Aug 2008 10:45:45 -0500> From: rodney.bates at wichita.edu> To: m3devel at elegosoft.com> Subject: Re: [M3devel] pixmap problem (some success)> > > > Jay wrote:> > I committed a possible fix here.> > Please see how it fairs.> > > > I have a few Modula-3 questions related to the fix.> > > > - Did I have to expose the functions in the .i3 file> > that implement the methods? That seems "wrong".> > > > > > - Could I have used "stronger language opacity" instead> > of "informal privacy"? That is, could I have used an> > opaque type?> > I have a number of comments on this.> Here are 3 examples of different styles of coding in Modula-3.> > ---------------------------------------------------------------------------------> INTERFACE M1> ; TYPE T <: REFANY> ; PROCEDURE Op ( Arg : T )> ; END M1 .> > MODULE M1> ; REVEAL T = BRANDED REF RECORD (> * Fields of T, hidden from clients. *)> END (* T *)> ; PROCEDURE Op ( Arg : T ) = (* A body that uses the fields of T. *)> ; BEGIN END M1 .> > ; MODULE Client1 EXPORTS Main> ; IMPORT M1> ; VAR Obj := NEW ( M1 . T )> ; BEGIN> M1 . Op ( Obj )> END Client1 .> > I would call this the _abstract data type_ style. It uses a plain procedure Op,> not a method. The type T is opaque in the interface, so clients can manipulate> values of it only by calling Op (and, presumably, other procedures whose signatures> would also be given in the interface).> > -------------------------------------------------------------------------------> INTERFACE M2> ; TYPE T <: Public> ; TYPE Public = OBJECT METHODS op ( ) (* No default method body given here. *)> END (* Public *)> ; END M2 .> > MODULE M2> ; REVEAL T = Public BRANDED OBJECT (* Same fields as M1.T. *)> OVERRIDES op := Op (* Provide the method body for op. *)> END (* T *)> ; PROCEDURE Op ( Arg : T ) = (* Pretty much the same as M1.Op, maybe even exactly. *)> ; BEGIN END M2 .> > ; MODULE Client2 EXPORTS Main> ; IMPORT M2> ; VAR Obj : M2 . T := NEW ( M2 . T )> ; BEGIN> Obj . op ( )> END Client2 .> > This is the OO style. The operation is an overridable method. Clients can still> manipulate objects of type T only by using the operation op, but here, op is a> method, not a procedure, so they must use a method call. It will dispatch, but> without further code, it will always dispatch to M2.Op.> > But, if client code were to:> 1) declare a subtype Sub, of M2.T,> 2) which has a method override for op, say procedure OpSub,> 3) provide OpSub,> 4) then allocate an object of type Sub,> 5) but assign this object to variable Client2.Obj (whose type is M2.T, not Sub),> then the method call Obj.op() would dispatch to OpSub.> > -------------------------------------------------------------------------------> Here is a side point that I think is confusing about Modula-3 opaque types. At least> it took me years to fully understand. The same subtype mechanism is used in Modula-3> in two different ways. One is for creating a hierarchy of dynamically typed objects.> This is the usual OO use. The other is in opaque types. When used in the usual way,> actual objects of opaque type Public are never allocated. Public is only a static> structure to hold the subset of the properties of type T that are known everywhere.> > When you execute NEW(M2.T), you get a complete object of type T, with all its fields and> method overrides, even though you are in a context where these are not known. In a> sense, these things are hidden only from the programmer of this client code. But the> compiler may have to know at least some of the hidden information at the site of the> NEW call.> > (Actually, through clever implementation techniques, I think the compiler needs to> know at most the size of fully revealed type T and could probably do without that.> The messages about recompiling modules because of new opaque info are, I am sure,> the compiler generating better code by using revelations it didn't have the first time.)> > -------------------------------------------------------------------------------> INTERFACE M3> ; TYPE T <: Public> ; TYPE Public = OBJECT METHODS op ( )> := Op (* Specify the body of op, here in the interface. *)> END (* Public *)> ; PROCEDURE Op ( Arg : T ) = (* A body that uses the fields of T. *)> ; END M3 .> > MODULE M3> ; REVEAL T = Public BRANDED OBJECT (* Same fields as M1.T and M2.T. *)> (* No override for op needed. Its body was already> given in type Public. *)> END T> ; PROCEDURE Op ( Arg : T ) = (* Pretty much the same as M1.Op. *)> ; BEGIN END M3 .> > ; MODULE Client3 EXPORTS Main> ; IMPORT M3> ; VAR Obj := NEW ( M3 . T )> ; BEGIN> Obj . op ( )> ; M3 . Op ( Obj )> END Client3 .> > This is a hybrid. Still opaque, as before. But a client can either call plain> procedure M3.Op, which will be statically known to always invoke Op, or a method> call on op, which might dispatch to Op or OpSub, if the latter exists.> > ------------------------------------------------------------------------------------> An OO purist would say that every programmer-defined type should be opaque, hiding its> fields, and that every operation should always be a method, in case some later code> has a need to create a subtype and override the methods.> > The problem with (dispatching) methods is it makes tracking down bugs a nightmare. The> whole abstraction idea works great when designing one layer at a time, or even testing> one layer at a time. But when you have a specific bug, you can't do it a layer at a time.> You often have to trace, mentally or with actual execution, in and out of the calls and> returns, through the layers.> > If you see a procedure call, it is statically known and quite direct, at least in a> modular language, to find the code that is called. Every time you see a method call,> there is a big tangential process to try to figure out if there are overrides, what> subtype the object might be, etc., and the results may be dynamic. This can make an> otherwise sstraightforward process extremely tedious.> > I am a strong believer in using methods when there is a good reason, i.e., you know> or reasonably suspect there will be a need to actually create overrides and have> nontrivial dispatching happen. Otherwise, stick to static procedure calls. The> pickle code, for example, uses methods all over the place. Nearly all of them always> dispatch to exactly one place, but for each such, it takes a lot of work to ascertain> this. It is very hard code to vet.> > -------------------------------------------------------------------------------------> The hybrid approach, perhaps surprisingly, is sometimes very useful. For example,> you have a complex tree with several node types that are different subtypes of a> common parent node type. In some places, you have a node pointer that could be> any of the subtypes. Then you would want to make a method call. In other places,> you already know exactly what type node you have, perhaps because you are inside> a TYPECASE or a procedure that was already dispatched-to. Here, I prefer to use> a non-dispatching call. Aside from saving a tiny bit of runtime overhead for the> dispatch (which is minor), you avoid the debug problem above.> > > > > > - Will the change break pickles?> > "Both" due to the addition of data "or" methods?> > ie: What breaks pickles?> > Do I need to think in the mindset of> > C:> > typedef struct {> > int a,b;> > } foo_t;> > > > foo_t f;> > fwrite(&f, sizeof(f), 1, file);> > > > and not breaking such code? > > Only if the type is "branded"? Or if types derived from it are branded?> > There could be derived types not in the cm3 tree though.> > How much do we care about breaking code outside the cm3 tree?> > e.g. in this change, I had to change every use of .xres and .yres> > If by "break pickles" you mean invalidating existing pickle _data_ that was written> before the change, then yes. When reading an object from a pickle, the reading> program must contain a type that is exactly the same type as was used to write> the object. So if the program that reads the pickle is recompiled after the change,> then existing pickle data will have to be rewritten.> > A change to anything that is a property of a type, according to the rules of> the language, will cause this. For example, changes in brandedness, changes in> the string value of the brand, or, probably, the use of an anonymous brand would> all change the type. Note that the full revelation of any opaque type is required> by the language to be branded, though not necessarily with a string value.> > Also, note that the names of fields are part of a record or object type, so> changing .xres to a different name will invalidate existing pickle data. This> does not necessarily mean it's a bad idea.> > On the other hand, if you are willing/able to recompile and rerun both the program> that writes and the program that reads the pickle data, such changes will work fine.> Neither the source code in the Pickle library nor its client code will break.> > We definitely do care about breaking code outside the cm3 tree. Randy's application> would be a good example. So removing functions, constants, etc. just because they> are unused in cm3 would not be good. Nor would merging differently-named things,> just because they always have the same properties in cm3, because they could have> different properties in other code.> > > -- > -------------------------------------------------------------> Rodney M. Bates, retired assistant professor> Dept. of Computer Science, Wichita State University> Wichita, KS 67260-0083> 316-978-3922> rodney.bates at wichita.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080809/86c51ed0/attachment-0002.html>

From rcoleburn at scires.com  Mon Aug 11 21:23:17 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Mon, 11 Aug 2008 15:23:17 -0400
Subject: [M3devel] strange problem w/new Image/ImageInit
In-Reply-To: <COL101-W13606B4823978F6670D3C9E6710@phx.gbl>
References: <489FAA38.1E75.00D7.1@scires.com>
	<COL101-W158F68823847D036260F0FE6710@phx.gbl>
	<48A02D67.1E75.00D7.1@scires.com>
	<COL101-W13606B4823978F6670D3C9E6710@phx.gbl>
Message-ID: <48A05960.1E75.00D7.1@scires.com>

Jay:
 
I have been experimenting quite a bit and I've come up with some "new old" information.
 
I say "new old" because, after spending the time to read some of the comments in the original code (before we modified it), I think I now have a better idea of what the designers intended and why I had/have a problem.
 
If you read carefully, the xres/yres fields in Image.Raw are supposed to represent the resolution at which the pixmap was originally DEVELOPED, not the resolution of the current screen.  It seems the designers went to great lengths to represent everything as screen-independent until it is actually rendered.  
 
The Image interface gives 3 ways of dealing with pixmaps:  (1) unscaled, (2) scaled, and (3) scaled to "most appropriate".  The change you and I conspired actually changes this behavior to make #2 (scaled) work as #1 (unscaled).  (It probably also changes #3.)  This is the behavior I want for my current program, but it changes the intent of the original interface, so I'm afraid we are going to have to revert all those changes.
 
Digging deeper into Image.m3, I've discovered that it is smart-enough already to deduce the screen resolution.  If you look into the ApplyScaled1 procedure, you see that it converts the current screen resolution in millimeters to pixels in order to scale the pixmap.  The change we introduced, namely making Raw.xres/yres equal to the current screen resolution, effectively caused the Scaled procedure to do nothing since (ScreenDPI / ImageDPI) = 1.
 
The problem that brought all this on in the first place is that my GUI was looking bad on the 1920x1200 screen.  The reason I have discovered *now* is that FormsVBT apparently uses the #2 (scaled) version for pixmaps.  In the old code, the interface defaulted the developed resolution of the pixmaps to be 75 dpi.  At my 147+ dpi screen, the scaled implementation would effectively double the size of the pixmap when rendered on the screen in an effort to make the pixmap look the same size on the 147dpi screen that it appeared on a 75 dpi screen.
 
All of this to say that the changes to Image.i3/m3 need to be undone in order to get back the original intent of the developers.
 
Of course, once these changes are undone, my problem returns with the GUI looking bad on 1920x1200 at 147+ dpi.  So, how to solve it properly now requires more thought.
 
I need to do some more reading of the code I guess to see if there is a way already to cause FormsVBT to use unscaled for all pixmaps.  Otherwise, a quick fix would be to add a new procedure to the interface that would force use of the unscaled implementation.
 
Now, back to the problem of not being able to drag the subwindows, I'm still puzzled.  To test my "understanding" as related above, I went back to the original Image.i3/m3, but this time changed the Scaled procedure to effectively do the same thing as Unscaled.  The pixmaps render fine on the 1920x1200 monitor, but the subwindows still can't be dragged.  If I back out my change to Scaled (effectively, revert to the original Image.m3), the subwindows drag with ease on the 1920x1200 monitor, but of course the pixmaps look bad.  I can't explain this behavior yet.  Any ideas?
 
Regards,
Randy

>>> Jay <jay.krell at cornell.edu> 8/11/2008 2:41 PM >>>

MemoryBarrier ensures that all the reads and writes before it finish before any reads and writes after it.
Look at winnt.h or MSDN, as well the comment I put in explains it.
It probably has no effect, since our compiler is not aggressive.
What is confusing in these cases is the compiler and processor both need to be informed.
There is a concurrency issue and the barrier should make extra certain to solve it.

Multiple monitors are not considered.
Do you have them?

Randy, please experiment.
Change the code to return hard coded numbers -- like the old 75.
   Either without the globals, or initialize the globals.
And then add in the the various calls one at a time, ignoring their return values.  

Furthermore, I guess you could just say:

    IF xres = 0 THEN Init() END;

and

    IF yres = 0 THEN Init() END;

and maybe change the globals to INTEGER.
Though REAL should be 32 bits and be written atomatically.

The idea is, even if the code does run multiple times concurrently, it should always return the same information.

Anyway, like I said, try various or every combination between the two and find
out which part triggers the difference, then we can think more about just that.

I might be able to get an expert friend to give me some help, later.

- Jay


________________________________

Date: Mon, 11 Aug 2008 12:15:40 -0400
From: rcoleburn at scires.com 
To: jay.krell at cornell.edu 
CC: wagner at elegosoft.com 
Subject: RE: strange problem w/new Image/ImageInit



Jay:



I tested your change, but it has no effect on the problem I am having.  I also tried having the accessor functions just return a hardcoded number, but again, no effect on the problem.  This is real strange to me, because if I remove ImageInit and revert Image.i3/m3 back to the way it was before, the problem disappears.



Questions,

1.  What does the WinNT.MemoryBarrier() call do?

2.  What would happen if this code was run by multiple threads?  Are there any concurrency issues that need to be guarded?

3.  What would happen in the case of multiple monitors at different resolutions?



Regards,

Randy

>>> Jay  8/11/2008 6:46 AM>>>

Also try the change I just commited with ReleaseDC.

- Jay


> From: jayk123 at hotmail.com 
> To: rcoleburn at scires.com 
> CC: wagner at elegosoft.com 
> Subject: RE: strange problem w/new Image/ImageInit
> Date: Mon, 11 Aug 2008 07:51:52 +0000
>
>
> Randy, this makes no sense to me.
> What happens if you just hardcode the numbers instead of computing them?
>
>
> - Jay
>
>
>
>
>
>
> ________________________________
>
>
>
> Date: Mon, 11 Aug 2008 02:55:56 -0400
> From: rcoleburn at scires.com 
> To: jayk123 at hotmail.com 
> CC: Olaf Wagner


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080811/ead5acd5/attachment-0002.html>

From jay.krell at cornell.edu  Mon Aug 11 21:52:52 2008
From: jay.krell at cornell.edu (Jay)
Date: Mon, 11 Aug 2008 19:52:52 +0000
Subject: [M3devel] strange problem w/new Image/ImageInit
In-Reply-To: <48A05960.1E75.00D7.1@scires.com>
References: <489FAA38.1E75.00D7.1@scires.com>
	<COL101-W158F68823847D036260F0FE6710@phx.gbl>
	<48A02D67.1E75.00D7.1@scires.com>
	<COL101-W13606B4823978F6670D3C9E6710@phx.gbl> 
	<48A05960.1E75.00D7.1@scires.com>
Message-ID: <COL101-W65ECE9C2B48E275288EAF0E6710@phx.gbl>


Hm. Ok then, where does it get the screen resolution from?

Probably here?

WinScreenType.m3:

PROCEDURE InnerNew ((* IN-OUT *) res: T) =
  BEGIN
    WITH pix_hor = WinUser.GetSystemMetrics(WinUser.SM_CXSCREEN),
         pix_ver = WinUser.GetSystemMetrics(WinUser.SM_CYSCREEN),
         mm_hor  = GetDeviceCaps (WinGDI.HORZSIZE),
         mm_ver  = GetDeviceCaps (WinGDI.VERTSIZE) DO
      res.rootDom := Rect.FromSize(pix_hor, pix_ver);
      res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
      res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);

ok.

Perhaps we should accept the numbers that Windows makes up instead?

GetDeviceCaps(LOGPIXELSX)
and GetDeviceCaps(LOGPIXELSY)

Please try that, in the WinScreenType.m3 code.
With removing ImageInit (or just have it hardcoded at 75).

This will most likely be 96 even on your high dpi system, unless you are on Vista
and tell the system you are high dpi aware.

I think there is disagreement in drawing vs. hit test as to where you are clicking.
Try making ImageInit always 75.
Try making the above convert from a hardcoded 96.
And then try GetDeviceCaps(LOGPIXELSX and Y) -- which I expect always returns 96 for you.
You can plug that into my dpi.c to see what it prints.

I think part of what is happening is that Modula-3 was very rare in doing the right thing for high dpi
monitors. But so much code is wrong that Windows has to counteract the wrongness,
which means Modula-3 needs to go along and do things wrong in order for the counteraction
to leave it doing the right thing also.
I'm not sure.
Oh, and presumably other places in Modula-3 are wrong, and the counteraction works for them.
That's a bit of a mystery -- drawing of pixmaps vs. drawing of everything else.

 - Jay


________________________________

Date: Mon, 11 Aug 2008 15:23:17 -0400
From: rcoleburn at scires.com
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com; wagner at elegosoft.com
Subject: RE: strange problem w/new Image/ImageInit



Jay:



I have been experimenting quite a bit and I've come up with some "new old" information.



I say "new old" because, after spending the time to read some of the comments in the original code (before we modified it), I think I now have a better idea of what the designers intended and why I had/have a problem.



If you read carefully, the xres/yres fields in Image.Raw are supposed to represent the resolution at which the pixmap was originally DEVELOPED, not the resolution of the current screen.  It seems the designers went to great lengths to represent everything as screen-independent until it is actually rendered.



The Image interface gives 3 ways of dealing with pixmaps:  (1) unscaled, (2) scaled, and (3) scaled to "most appropriate".  The change you and I conspired actually changes this behavior to make #2 (scaled) work as #1 (unscaled).  (It probably also changes #3.)  This is the behavior I want for my current program, but it changes the intent of the original interface, so I'm afraid we are going to have to revert all those changes.



Digging deeper into Image.m3, I've discovered that it is smart-enough already to deduce the screen resolution.  If you look into the ApplyScaled1 procedure, you see that it converts the current screen resolution in millimeters to pixels in order to scale the pixmap.  The change we introduced, namely making Raw.xres/yres equal to the current screen resolution, effectively caused the Scaled procedure to do nothing since (ScreenDPI / ImageDPI) = 1.



The problem that brought all this on in the first place is that my GUI was looking bad on the 1920x1200 screen.  The reason I have discovered *now* is that FormsVBT apparently uses the #2 (scaled) version for pixmaps.  In the old code, the interface defaulted the developed resolution of the pixmaps to be 75 dpi.  At my 147+ dpi screen, the scaled implementation would effectively double the size of the pixmap when rendered on the screen in an effort to make the pixmap look the same size on the 147dpi screen that it appeared on a 75 dpi screen.



All of this to say that the changes to Image.i3/m3 need to be undone in order to get back the original intent of the developers.



Of course, once these changes are undone, my problem returns with the GUI looking bad on 1920x1200 at 147+ dpi.  So, how to solve it properly now requires more thought.



I need to do some more reading of the code I guess to see if there is a way already to cause FormsVBT to use unscaled for all pixmaps.  Otherwise, a quick fix would be to add a new procedure to the interface that would force use of the unscaled implementation.



Now, back to the problem of not being able to drag the subwindows, I'm still puzzled.  To test my "understanding" as related above, I went back to the original Image.i3/m3, but this time changed the Scaled procedure to effectively do the same thing as Unscaled.  The pixmaps render fine on the 1920x1200 monitor, but the subwindows still can't be dragged.  If I back out my change to Scaled (effectively, revert to the original Image.m3), the subwindows drag with ease on the 1920x1200 monitor, but of course the pixmaps look bad.  I can't explain this behavior yet.  Any ideas?



Regards,

Randy

>>> Jay  8/11/2008 2:41 PM>>>

MemoryBarrier ensures that all the reads and writes before it finish before any reads and writes after it.
Look at winnt.h or MSDN, as well the comment I put in explains it.
It probably has no effect, since our compiler is not aggressive.
What is confusing in these cases is the compiler and processor both need to be informed.
There is a concurrency issue and the barrier should make extra certain to solve it.

Multiple monitors are not considered.
Do you have them?

Randy, please experiment.
Change the code to return hard coded numbers -- like the old 75.
   Either without the globals, or initialize the globals.
And then add in the the various calls one at a time, ignoring their return values.

Furthermore, I guess you could just say:

    IF xres = 0 THEN Init() END;

and

    IF yres = 0 THEN Init() END;

and maybe change the globals to INTEGER.
Though REAL should be 32 bits and be written atomatically.

The idea is, even if the code does run multiple times concurrently, it should always return the same information.

Anyway, like I said, try various or every combination between the two and find
out which part triggers the difference, then we can think more about just that.

I might be able to get an expert friend to give me some help, later.

- Jay


________________________________

Date: Mon, 11 Aug 2008 12:15:40 -0400
From: rcoleburn at scires.com
To: jay.krell at cornell.edu
CC: wagner at elegosoft.com
Subject: RE: strange problem w/new Image/ImageInit



Jay:



I tested your change, but it has no effect on the problem I am having.  I also tried having the accessor functions just return a hardcoded number, but again, no effect on the problem.  This is real strange to me, because if I remove ImageInit and revert Image.i3/m3 back to the way it was before, the problem disappears.



Questions,

1.  What does the WinNT.MemoryBarrier() call do?

2.  What would happen if this code was run by multiple threads?  Are there any concurrency issues that need to be guarded?

3.  What would happen in the case of multiple monitors at different resolutions?



Regards,

Randy

>>> Jay  8/11/2008 6:46 AM>>>

Also try the change I just commited with ReleaseDC.

- Jay


> From: jayk123 at hotmail.com
> To: rcoleburn at scires.com
> CC: wagner at elegosoft.com
> Subject: RE: strange problem w/new Image/ImageInit
> Date: Mon, 11 Aug 2008 07:51:52 +0000
>
>
> Randy, this makes no sense to me.
> What happens if you just hardcode the numbers instead of computing them?
>
>
> - Jay
>
>
>
>
>
>
> ________________________________
>
>
>
> Date: Mon, 11 Aug 2008 02:55:56 -0400
> From: rcoleburn at scires.com
> To: jayk123 at hotmail.com
> CC: Olaf Wagner




From rcoleburn at scires.com  Tue Aug 12 10:25:11 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Tue, 12 Aug 2008 04:25:11 -0400
Subject: [M3devel] strange problem w/new Image/ImageInit
In-Reply-To: <COL101-W65ECE9C2B48E275288EAF0E6710@phx.gbl>
References: <489FAA38.1E75.00D7.1@scires.com>
	<COL101-W158F68823847D036260F0FE6710@phx.gbl>
	<48A02D67.1E75.00D7.1@scires.com>
	<COL101-W13606B4823978F6670D3C9E6710@phx.gbl>
	<48A05960.1E75.00D7.1@scires.com>
	<COL101-W65ECE9C2B48E275288EAF0E6710@phx.gbl>
Message-ID: <48A110A3.1E75.00D7.1@scires.com>

Jay:
 
For LOGPIXELS X & Y, I get 96 on the hi-res Dell M4300 system and also on my ThinkPad T60.
 
I've put together revised versions of Image.i3/m3 and my ScrollerVBTClass.m3.  The good news is that I've managed to get the scroll bar to look correct in both scaled and unscaled modes.  
 
I've added a new procedure to Image.i3/m3 that will force subsequent calls to Scaled() to behave like Unscaled().  Using this, I can get the appearance I need on the hi-res monitor without resorting to changes in the original intent of the Image interface.  The advantage of this procedure is that it does not change the Image interface (except for addition of the procedure) and it therefore won't have any affect on pickles or anyone else's code.  Plus, it lets the programmer override use of Scaled() in all library modules without having to modify any source code.
 
Before I commit any of these changes, I want to do some more testing and to fix the problem with subwindows (ZChassisVBT) not being able to move.
 
Alas, my problem of the ZChassisVBTs not being able to move on the hi-res monitor persists with these changes, even though I left the xres/yres at 75.  Of course, these numbers are ignored for Unscaled images anyway.
 
I'm at a loss to explain this behavior.  Here is what I know based on testing:
1.  Using Scaled images and Image.Raw.xres/yres = 75.0, ZChassisVBT movement works on the hi-res monitor.
2.  Using Scaled images and Image.Raw.xres/yres set to 86.xxx or to 147.xxx, ZChassisVBT movement does not work on the hi-res 147.xxx dpi monitor, but it still works on my 86.xxx dpi monitor
3.  Using Unscaled images, ZChassisVBT movement does not work on the hi-res 147.xxx dpi monitor, but it still works on my 86.xxx dpi monitor
 
So, there seems to be something in the implementation somewhere of ZChassisVBT, or maybe ZMoveVBT, that doesn't like 147.xxx dpi monitors unless you scale all images assuming they were designed at 75 dpi.  At the 147 dpi, the 75 dpi pixmaps will be scaled by a factor of 2, which corresponds to what I am seeing on the screen.
 
I'm too sleepy to make any more progress for now.  If anyone has an idea on what to do next, please let me know.  I'm stumped at this point.
 
Regards,
Randy

>>> Jay <jay.krell at cornell.edu> 8/11/2008 3:52 PM >>>

Hm. Ok then, where does it get the screen resolution from?

Probably here?

WinScreenType.m3:

PROCEDURE InnerNew ((* IN-OUT *) res: T) =
  BEGIN
    WITH pix_hor = WinUser.GetSystemMetrics(WinUser.SM_CXSCREEN),
         pix_ver = WinUser.GetSystemMetrics(WinUser.SM_CYSCREEN),
         mm_hor  = GetDeviceCaps (WinGDI.HORZSIZE),
         mm_ver  = GetDeviceCaps (WinGDI.VERTSIZE) DO
      res.rootDom := Rect.FromSize(pix_hor, pix_ver);
      res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
      res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);

ok.

Perhaps we should accept the numbers that Windows makes up instead?

GetDeviceCaps(LOGPIXELSX)
and GetDeviceCaps(LOGPIXELSY)

Please try that, in the WinScreenType.m3 code.
With removing ImageInit (or just have it hardcoded at 75).

This will most likely be 96 even on your high dpi system, unless you are on Vista
and tell the system you are high dpi aware.

I think there is disagreement in drawing vs. hit test as to where you are clicking.
Try making ImageInit always 75.
Try making the above convert from a hardcoded 96.
And then try GetDeviceCaps(LOGPIXELSX and Y) -- which I expect always returns 96 for you.
You can plug that into my dpi.c to see what it prints.

I think part of what is happening is that Modula-3 was very rare in doing the right thing for high dpi
monitors. But so much code is wrong that Windows has to counteract the wrongness,
which means Modula-3 needs to go along and do things wrong in order for the counteraction
to leave it doing the right thing also.
I'm not sure.
Oh, and presumably other places in Modula-3 are wrong, and the counteraction works for them.
That's a bit of a mystery -- drawing of pixmaps vs. drawing of everything else.

- Jay


________________________________

Date: Mon, 11 Aug 2008 15:23:17 -0400
From: rcoleburn at scires.com 
To: jay.krell at cornell.edu 
CC: m3devel at elegosoft.com; wagner at elegosoft.com 
Subject: RE: strange problem w/new Image/ImageInit



Jay:



I have been experimenting quite a bit and I've come up with some "new old" information.



I say "new old" because, after spending the time to read some of the comments in the original code (before we modified it), I think I now have a better idea of what the designers intended and why I had/have a problem.



If you read carefully, the xres/yres fields in Image.Raw are supposed to represent the resolution at which the pixmap was originally DEVELOPED, not the resolution of the current screen.  It seems the designers went to great lengths to represent everything as screen-independent until it is actually rendered.



The Image interface gives 3 ways of dealing with pixmaps:  (1) unscaled, (2) scaled, and (3) scaled to "most appropriate".  The change you and I conspired actually changes this behavior to make #2 (scaled) work as #1 (unscaled).  (It probably also changes #3.)  This is the behavior I want for my current program, but it changes the intent of the original interface, so I'm afraid we are going to have to revert all those changes.



Digging deeper into Image.m3, I've discovered that it is smart-enough already to deduce the screen resolution.  If you look into the ApplyScaled1 procedure, you see that it converts the current screen resolution in millimeters to pixels in order to scale the pixmap.  The change we introduced, namely making Raw.xres/yres equal to the current screen resolution, effectively caused the Scaled procedure to do nothing since (ScreenDPI / ImageDPI) = 1.



The problem that brought all this on in the first place is that my GUI was looking bad on the 1920x1200 screen.  The reason I have discovered *now* is that FormsVBT apparently uses the #2 (scaled) version for pixmaps.  In the old code, the interface defaulted the developed resolution of the pixmaps to be 75 dpi.  At my 147+ dpi screen, the scaled implementation would effectively double the size of the pixmap when rendered on the screen in an effort to make the pixmap look the same size on the 147dpi screen that it appeared on a 75 dpi screen.



All of this to say that the changes to Image.i3/m3 need to be undone in order to get back the original intent of the developers.



Of course, once these changes are undone, my problem returns with the GUI looking bad on 1920x1200 at 147+ dpi.  So, how to solve it properly now requires more thought.



I need to do some more reading of the code I guess to see if there is a way already to cause FormsVBT to use unscaled for all pixmaps.  Otherwise, a quick fix would be to add a new procedure to the interface that would force use of the unscaled implementation.



Now, back to the problem of not being able to drag the subwindows, I'm still puzzled.  To test my "understanding" as related above, I went back to the original Image.i3/m3, but this time changed the Scaled procedure to effectively do the same thing as Unscaled.  The pixmaps render fine on the 1920x1200 monitor, but the subwindows still can't be dragged.  If I back out my change to Scaled (effectively, revert to the original Image.m3), the subwindows drag with ease on the 1920x1200 monitor, but of course the pixmaps look bad.  I can't explain this behavior yet.  Any ideas?



Regards,

Randy

>>> Jay  8/11/2008 2:41 PM>>>

MemoryBarrier ensures that all the reads and writes before it finish before any reads and writes after it.
Look at winnt.h or MSDN, as well the comment I put in explains it.
It probably has no effect, since our compiler is not aggressive.
What is confusing in these cases is the compiler and processor both need to be informed.
There is a concurrency issue and the barrier should make extra certain to solve it.

Multiple monitors are not considered.
Do you have them?

Randy, please experiment.
Change the code to return hard coded numbers -- like the old 75.
   Either without the globals, or initialize the globals.
And then add in the the various calls one at a time, ignoring their return values.

Furthermore, I guess you could just say:

    IF xres = 0 THEN Init() END;

and

    IF yres = 0 THEN Init() END;

and maybe change the globals to INTEGER.
Though REAL should be 32 bits and be written atomatically.

The idea is, even if the code does run multiple times concurrently, it should always return the same information.

Anyway, like I said, try various or every combination between the two and find
out which part triggers the difference, then we can think more about just that.

I might be able to get an expert friend to give me some help, later.

- Jay


________________________________

Date: Mon, 11 Aug 2008 12:15:40 -0400
From: rcoleburn at scires.com 
To: jay.krell at cornell.edu 
CC: wagner at elegosoft.com 
Subject: RE: strange problem w/new Image/ImageInit



Jay:



I tested your change, but it has no effect on the problem I am having.  I also tried having the accessor functions just return a hardcoded number, but again, no effect on the problem.  This is real strange to me, because if I remove ImageInit and revert Image.i3/m3 back to the way it was before, the problem disappears.



Questions,

1.  What does the WinNT.MemoryBarrier() call do?

2.  What would happen if this code was run by multiple threads?  Are there any concurrency issues that need to be guarded?

3.  What would happen in the case of multiple monitors at different resolutions?



Regards,

Randy

>>> Jay  8/11/2008 6:46 AM>>>

Also try the change I just commited with ReleaseDC.

- Jay


> From: jayk123 at hotmail.com 
> To: rcoleburn at scires.com 
> CC: wagner at elegosoft.com 
> Subject: RE: strange problem w/new Image/ImageInit
> Date: Mon, 11 Aug 2008 07:51:52 +0000
>
>
> Randy, this makes no sense to me.
> What happens if you just hardcode the numbers instead of computing them?
>
>
> - Jay
>
>
>
>
>
>
> ________________________________
>
>
>
> Date: Mon, 11 Aug 2008 02:55:56 -0400
> From: rcoleburn at scires.com 
> To: jayk123 at hotmail.com 
> CC: Olaf Wagner



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080812/e2ceef31/attachment-0002.html>

From jay.krell at cornell.edu  Tue Aug 12 12:49:18 2008
From: jay.krell at cornell.edu (Jay)
Date: Tue, 12 Aug 2008 10:49:18 +0000
Subject: [M3devel] strange problem w/new Image/ImageInit
In-Reply-To: <48A110A3.1E75.00D7.1@scires.com>
References: <489FAA38.1E75.00D7.1@scires.com>
	<COL101-W158F68823847D036260F0FE6710@phx.gbl>
	<48A02D67.1E75.00D7.1@scires.com>
	<COL101-W13606B4823978F6670D3C9E6710@phx.gbl>
	<48A05960.1E75.00D7.1@scires.com>
	<COL101-W65ECE9C2B48E275288EAF0E6710@phx.gbl> 
	<48A110A3.1E75.00D7.1@scires.com>
Message-ID: <COL101-W48D58C2FBDE5BCD3163650E6700@phx.gbl>


Randy I don't think you need to add a way to use the unscaled data.
I think the fix is
a) go back to Image hardcoding 75
b) Have WinScreenType hardcode 96 or use GetDeviceCaps(LOGPIXELSX Y) -- same thing really.
And then see what happens.

Basically, the scale of pixmaps and the scale of screens has always been close to 1:1.
75:96, close enough.
Therefore, unscaled has been the norm.

Most GUI code uses GetDeviceCaps(LOGPIXELSX Y) I believe.
However, most code is not prepared to get back anything other than 96 from it.

Modula-3, at least for the pixmap code, was computing LOGPIXELSX and Y via a seemingly redundant equivalent way.
However, my believe is that LOGPIXELSX and Y is forced to lie, but the other route is not.
It seems an arbitrary discprecancy, but not beyond imagination.

By switching to the lying method, we will get back the nearly unscaled 75:96 behavior.

Vista adds a way for an application to declare that it is "high dpi aware", which then makes GetDeviceCaps(LOGPIXELX and Y) report the truth presumably. You can see, by the very existance of this ability to declare that you are high dpi aware -- to declare that your code is merely correct -- that most code is not correct.

What remains to be determined is why Modula-3 pixmaps behave "differently" than Modula-3 buttons, text, etc.

I also think there is a likely disconnect between painting and hit testing, but this is gross speculation.
I should fiddle with the numbers myself.

I will go ahead with a+b fairly soon.
I will verify the numbers computed in #b before and after.
I don't have any high dpi systems, so I expect the numbers to be roughly the same either way.
I think the only systems that will see a change are high dpi, and they will see an improvement.

Sorry for the back and forth regarding ImageInit -- a medium size change is going to be completely undone.

 - Jay

________________________________

Date: Tue, 12 Aug 2008 04:25:11 -0400
From: rcoleburn at scires.com
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] strange problem w/new Image/ImageInit



Jay:



For LOGPIXELS X & Y, I get 96 on the hi-res Dell M4300 system and also on my ThinkPad T60.



I've put together revised versions of Image.i3/m3 and my ScrollerVBTClass.m3.  The good news is that I've managed to get the scroll bar to look correct in both scaled and unscaled modes.



I've added a new procedure to Image.i3/m3 that will force subsequent calls to Scaled() to behave like Unscaled().  Using this, I can get the appearance I need on the hi-res monitor without resorting to changes in the original intent of the Image interface.  The advantage of this procedure is that it does not change the Image interface (except for addition of the procedure) and it therefore won't have any affect on pickles or anyone else's code.  Plus, it lets the programmer override use of Scaled() in all library modules without having to modify any source code.



Before I commit any of these changes, I want to do some more testing and to fix the problem with subwindows (ZChassisVBT) not being able to move.



Alas, my problem of the ZChassisVBTs not being able to move on the hi-res monitor persists with these changes, even though I left the xres/yres at 75.  Of course, these numbers are ignored for Unscaled images anyway.



I'm at a loss to explain this behavior.  Here is what I know based on testing:

1.  Using Scaled images and Image.Raw.xres/yres = 75.0, ZChassisVBT movement works on the hi-res monitor.

2.  Using Scaled images and Image.Raw.xres/yres set to 86.xxx or to 147.xxx, ZChassisVBT movement does not work on the hi-res 147.xxx dpi monitor, but it still works on my 86.xxx dpi monitor

3.  Using Unscaled images, ZChassisVBT movement does not work on the hi-res 147.xxx dpi monitor, but it still works on my 86.xxx dpi monitor



So, there seems to be something in the implementation somewhere of ZChassisVBT, or maybe ZMoveVBT, that doesn't like 147.xxx dpi monitors unless you scale all images assuming they were designed at 75 dpi.  At the 147 dpi, the 75 dpi pixmaps will be scaled by a factor of 2, which corresponds to what I am seeing on the screen.



I'm too sleepy to make any more progress for now.  If anyone has an idea on what to do next, please let me know.  I'm stumped at this point.



Regards,

Randy

>>> Jay  8/11/2008 3:52 PM>>>

Hm. Ok then, where does it get the screen resolution from?

Probably here?

WinScreenType.m3:

PROCEDURE InnerNew ((* IN-OUT *) res: T) =
  BEGIN
    WITH pix_hor = WinUser.GetSystemMetrics(WinUser.SM_CXSCREEN),
         pix_ver = WinUser.GetSystemMetrics(WinUser.SM_CYSCREEN),
         mm_hor  = GetDeviceCaps (WinGDI.HORZSIZE),
         mm_ver  = GetDeviceCaps (WinGDI.VERTSIZE) DO
      res.rootDom := Rect.FromSize(pix_hor, pix_ver);
      res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
      res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);

ok.

Perhaps we should accept the numbers that Windows makes up instead?

GetDeviceCaps(LOGPIXELSX)
and GetDeviceCaps(LOGPIXELSY)

Please try that, in the WinScreenType.m3 code.
With removing ImageInit (or just have it hardcoded at 75).

This will most likely be 96 even on your high dpi system, unless you are on Vista
and tell the system you are high dpi aware.

I think there is disagreement in drawing vs. hit test as to where you are clicking.
Try making ImageInit always 75.
Try making the above convert from a hardcoded 96.
And then try GetDeviceCaps(LOGPIXELSX and Y) -- which I expect always returns 96 for you.
You can plug that into my dpi.c to see what it prints.

I think part of what is happening is that Modula-3 was very rare in doing the right thing for high dpi
monitors. But so much code is wrong that Windows has to counteract the wrongness,
which means Modula-3 needs to go along and do things wrong in order for the counteraction
to leave it doing the right thing also.
I'm not sure.
Oh, and presumably other places in Modula-3 are wrong, and the counteraction works for them.
That's a bit of a mystery -- drawing of pixmaps vs. drawing of everything else.

- Jay


________________________________

Date: Mon, 11 Aug 2008 15:23:17 -0400
From: rcoleburn at scires.com
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com; wagner at elegosoft.com
Subject: RE: strange problem w/new Image/ImageInit



Jay:



I have been experimenting quite a bit and I've come up with some "new old" information.



I say "new old" because, after spending the time to read some of the comments in the original code (before we modified it), I think I now have a better idea of what the designers intended and why I had/have a problem.



If you read carefully, the xres/yres fields in Image.Raw are supposed to represent the resolution at which the pixmap was originally DEVELOPED, not the resolution of the current screen.  It seems the designers went to great lengths to represent everything as screen-independent until it is actually rendered.



The Image interface gives 3 ways of dealing with pixmaps:  (1) unscaled, (2) scaled, and (3) scaled to "most appropriate".  The change you and I conspired actually changes this behavior to make #2 (scaled) work as #1 (unscaled).  (It probably also changes #3.)  This is the behavior I want for my current program, but it changes the intent of the original interface, so I'm afraid we are going to have to revert all those changes.



Digging deeper into Image.m3, I've discovered that it is smart-enough already to deduce the screen resolution.  If you look into the ApplyScaled1 procedure, you see that it converts the current screen resolution in millimeters to pixels in order to scale the pixmap.  The change we introduced, namely making Raw.xres/yres equal to the current screen resolution, effectively caused the Scaled procedure to do nothing since (ScreenDPI / ImageDPI) = 1.



The problem that brought all this on in the first place is that my GUI was looking bad on the 1920x1200 screen.  The reason I have discovered *now* is that FormsVBT apparently uses the #2 (scaled) version for pixmaps.  In the old code, the interface defaulted the developed resolution of the pixmaps to be 75 dpi.  At my 147+ dpi screen, the scaled implementation would effectively double the size of the pixmap when rendered on the screen in an effort to make the pixmap look the same size on the 147dpi screen that it appeared on a 75 dpi screen.



All of this to say that the changes to Image.i3/m3 need to be undone in order to get back the original intent of the developers.



Of course, once these changes are undone, my problem returns with the GUI looking bad on 1920x1200 at 147+ dpi.  So, how to solve it properly now requires more thought.



I need to do some more reading of the code I guess to see if there is a way already to cause FormsVBT to use unscaled for all pixmaps.  Otherwise, a quick fix would be to add a new procedure to the interface that would force use of the unscaled implementation.



Now, back to the problem of not being able to drag the subwindows, I'm still puzzled.  To test my "understanding" as related above, I went back to the original Image.i3/m3, but this time changed the Scaled procedure to effectively do the same thing as Unscaled.  The pixmaps render fine on the 1920x1200 monitor, but the subwindows still can't be dragged.  If I back out my change to Scaled (effectively, revert to the original Image.m3), the subwindows drag with ease on the 1920x1200 monitor, but of course the pixmaps look bad.  I can't explain this behavior yet.  Any ideas?



Regards,

Randy

>>> Jay  8/11/2008 2:41 PM>>>

MemoryBarrier ensures that all the reads and writes before it finish before any reads and writes after it.
Look at winnt.h or MSDN, as well the comment I put in explains it.
It probably has no effect, since our compiler is not aggressive.
What is confusing in these cases is the compiler and processor both need to be informed.
There is a concurrency issue and the barrier should make extra certain to solve it.

Multiple monitors are not considered.
Do you have them?

Randy, please experiment.
Change the code to return hard coded numbers -- like the old 75.
   Either without the globals, or initialize the globals.
And then add in the the various calls one at a time, ignoring their return values.

Furthermore, I guess you could just say:

    IF xres = 0 THEN Init() END;

and

    IF yres = 0 THEN Init() END;

and maybe change the globals to INTEGER.
Though REAL should be 32 bits and be written atomatically.

The idea is, even if the code does run multiple times concurrently, it should always return the same information.

Anyway, like I said, try various or every combination between the two and find
out which part triggers the difference, then we can think more about just that.

I might be able to get an expert friend to give me some help, later.

- Jay


________________________________

Date: Mon, 11 Aug 2008 12:15:40 -0400
From: rcoleburn at scires.com
To: jay.krell at cornell.edu
CC: wagner at elegosoft.com
Subject: RE: strange problem w/new Image/ImageInit



Jay:



I tested your change, but it has no effect on the problem I am having.  I also tried having the accessor functions just return a hardcoded number, but again, no effect on the problem.  This is real strange to me, because if I remove ImageInit and revert Image.i3/m3 back to the way it was before, the problem disappears.



Questions,

1.  What does the WinNT.MemoryBarrier() call do?

2.  What would happen if this code was run by multiple threads?  Are there any concurrency issues that need to be guarded?

3.  What would happen in the case of multiple monitors at different resolutions?



Regards,

Randy

>>> Jay  8/11/2008 6:46 AM>>>

Also try the change I just commited with ReleaseDC.

- Jay


> From: jayk123 at hotmail.com
> To: rcoleburn at scires.com
> CC: wagner at elegosoft.com
> Subject: RE: strange problem w/new Image/ImageInit
> Date: Mon, 11 Aug 2008 07:51:52 +0000
>
>
> Randy, this makes no sense to me.
> What happens if you just hardcode the numbers instead of computing them?
>
>
> - Jay
>
>
>
>
>
>
> ________________________________
>
>
>
> Date: Mon, 11 Aug 2008 02:55:56 -0400
> From: rcoleburn at scires.com
> To: jayk123 at hotmail.com
> CC: Olaf Wagner





From jay.krell at cornell.edu  Tue Aug 12 12:54:27 2008
From: jay.krell at cornell.edu (Jay)
Date: Tue, 12 Aug 2008 10:54:27 +0000
Subject: [M3devel] strange problem w/new Image/ImageInit
In-Reply-To: <48A110A3.1E75.00D7.1@scires.com>
References: <489FAA38.1E75.00D7.1@scires.com>
	<COL101-W158F68823847D036260F0FE6710@phx.gbl>
	<48A02D67.1E75.00D7.1@scires.com>
	<COL101-W13606B4823978F6670D3C9E6710@phx.gbl>
	<48A05960.1E75.00D7.1@scires.com>
	<COL101-W65ECE9C2B48E275288EAF0E6710@phx.gbl> 
	<48A110A3.1E75.00D7.1@scires.com> 
Message-ID: <COL101-W731093036BEC825D730370E6700@phx.gbl>


ps: Randy, does the high dpi system run XP or Vista?
I suppose I should try to acquire a high dpi system but I'd rather not waste the money.

(I'd rather waste on getting HP-UX/IA64/AIX/VMS systems to bring Modula-3 back up on them
and put out current releases. : )) (I have an Irix system, haven't powered it up yet.)

On Vista there is a way to get the "real" dpi via this same api.
You have to declare you are high dpi "aware".

 - Jay


From rcoleburn at scires.com  Tue Aug 12 17:01:23 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Tue, 12 Aug 2008 11:01:23 -0400
Subject: [M3devel] strange problem w/new Image/ImageInit
In-Reply-To: <COL101-W731093036BEC825D730370E6700@phx.gbl>
References: <489FAA38.1E75.00D7.1@scires.com>
	<COL101-W158F68823847D036260F0FE6710@phx.gbl>
	<48A02D67.1E75.00D7.1@scires.com>
	<COL101-W13606B4823978F6670D3C9E6710@phx.gbl>
	<48A05960.1E75.00D7.1@scires.com>
	<COL101-W65ECE9C2B48E275288EAF0E6710@phx.gbl>
	<48A110A3.1E75.00D7.1@scires.com>
	<COL101-W731093036BEC825D730370E6700@phx.gbl>
Message-ID: <48A16D7B.1E75.00D7.1@scires.com>

Jay:
 
I am running XP, not Vista.
 
Regards,
Randy

>>> Jay <jay.krell at cornell.edu> 8/12/2008 6:54 AM >>>

ps: Randy, does the high dpi system run XP or Vista?
I suppose I should try to acquire a high dpi system but I'd rather not waste the money.

(I'd rather waste on getting HP-UX/IA64/AIX/VMS systems to bring Modula-3 back up on them
and put out current releases. : )) (I have an Irix system, haven't powered it up yet.)

On Vista there is a way to get the "real" dpi via this same api.
You have to declare you are high dpi "aware".

- Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080812/d17ec5bd/attachment-0002.html>

From rcoleburn at scires.com  Tue Aug 12 17:51:25 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Tue, 12 Aug 2008 11:51:25 -0400
Subject: [M3devel] strange problem w/new Image/ImageInit
In-Reply-To: <COL101-W48D58C2FBDE5BCD3163650E6700@phx.gbl>
References: <489FAA38.1E75.00D7.1@scires.com>
	<COL101-W158F68823847D036260F0FE6710@phx.gbl>
	<48A02D67.1E75.00D7.1@scires.com>
	<COL101-W13606B4823978F6670D3C9E6710@phx.gbl>
	<48A05960.1E75.00D7.1@scires.com>
	<COL101-W65ECE9C2B48E275288EAF0E6710@phx.gbl>
	<48A110A3.1E75.00D7.1@scires.com>
	<COL101-W48D58C2FBDE5BCD3163650E6700@phx.gbl>
Message-ID: <48A17936.1E75.00D7.1@scires.com>

Jay:
 
Thanks for your insights here.  I'll try some more tests and see what I come up with.  I've attached my current Image.i3/Image.m3 and Win32/ScrollerVBTClass.m3 for your reference.  I've removed use of ImageInit from all of these.  And yes, I have reverted to the 75.0 hardcoded value.
 
Based on my limited understanding of the code, I still think I will get scaled behavior even if Modula-3 thinks the dpi is 96, because 147 / 96 =  1.53125, which rounds to 2.  So my pixmaps will still appear double-size.
 
In actuality, I think Modula-3 is trying to do the right thing with the scaling.  At some point on a high-enough dpi monitor, the pixmaps will be so tiny that you can't really see them if they are unscaled.  I've already observed this with some of my boolean and choice indicators--I had to reduce the shadowsize in order to tell whether the boolean/choice was TRUE or FALSE.  From the way Trestle/FormsVBT are set up, it appears that the designers wanted to get approximately the same size rendering on different dpi screens.  That's why you see millimeters everywhere in the code being converted to pixels.  Indeed, VBT has a procedure MMToPixels that is dependent on getting the screen type of the underlying VBT.T so it can get the ppm setting for this screen and do the computation.  Provided that the underlying implementation gives correct ppm info to Modula-3 for each screen, the current Trestle/FormsVBT should do the right thing even in multiple monitor situations.  I haven't tested this, but I should be able to drag a window from a monitor at one dpi onto a monitor at a different dpi and have everything scale to look correct on the new monitor.
 
The problem in my case with the 1920x1200 monitor is that the scaled pixmaps look huge in proportion to the text and other features of the window.  Maybe this other stuff isn't being scaled the same way pixmaps are scaled.
 
Does LOGPIXELSX stand for Logical Pixels X-Axis ?  I know that Windows has a dpi setting for fonts.  If set to normal, fonts are supposed to render at 96 dpi, but you can switch to large mode and have them rendered at 120 dpi, or you can make up a custom number.  This Windows setting applies only to fonts, not graphical elements.
 
You say that Modula-3 is computing LOGPIXELS via a "seemingly redundant equivalent way."  In my reading of the code in WinScreenType, it appears that Modula-3 is requesting from Windows the actual number of pixels in both axes and also the number of millimeters in both axes.  It uses these to compute the resolution in pixels per millimeter (ppm).  The ppm is what is stored and used internally when scaling pixmaps.  When necessary, ppm is converted to dpi using the formula (dpi = ppm x 25.4).
 
On my 4:3 aspect ratio IBM T60 at 1280x1024, the ppm is 3.41333 in both axes yielding a dpi of 86.698667.
 
On the widescreen (16:10 aspect ratio) Dell 4300 at 1920x1200 the ppm is slightly different in each axis, but is close to 5.8xxx yielding at dpi of 147.xxx  (again, the fractional part is different in each axis).
 
I don't mind running a test program for you on the hi-res system here--just send it to me via email.  I have the VC++ 2008 redistributables installed.
 
I think you are on the west coast and I'm on the east coast, so we have a time difference of 3 hours, but lately I've been working round the clock seemingly, so I'll try to respond with test results as soon as I can.
 
Regards,
Randy

>>> Jay <jay.krell at cornell.edu> 8/12/2008 6:49 AM >>>

Randy I don't think you need to add a way to use the unscaled data.
I think the fix is
a) go back to Image hardcoding 75
b) Have WinScreenType hardcode 96 or use GetDeviceCaps(LOGPIXELSX Y) -- same thing really.
And then see what happens.

Basically, the scale of pixmaps and the scale of screens has always been close to 1:1.
75:96, close enough.
Therefore, unscaled has been the norm.

Most GUI code uses GetDeviceCaps(LOGPIXELSX Y) I believe.
However, most code is not prepared to get back anything other than 96 from it.

Modula-3, at least for the pixmap code, was computing LOGPIXELSX and Y via a seemingly redundant equivalent way.
However, my believe is that LOGPIXELSX and Y is forced to lie, but the other route is not.
It seems an arbitrary discprecancy, but not beyond imagination.

By switching to the lying method, we will get back the nearly unscaled 75:96 behavior.

Vista adds a way for an application to declare that it is "high dpi aware", which then makes GetDeviceCaps(LOGPIXELX and Y) report the truth presumably. You can see, by the very existance of this ability to declare that you are high dpi aware -- to declare that your code is merely correct -- that most code is not correct.

What remains to be determined is why Modula-3 pixmaps behave "differently" than Modula-3 buttons, text, etc.

I also think there is a likely disconnect between painting and hit testing, but this is gross speculation.
I should fiddle with the numbers myself.

I will go ahead with a+b fairly soon.
I will verify the numbers computed in #b before and after.
I don't have any high dpi systems, so I expect the numbers to be roughly the same either way.
I think the only systems that will see a change are high dpi, and they will see an improvement.

Sorry for the back and forth regarding ImageInit -- a medium size change is going to be completely undone.

- Jay

________________________________

Date: Tue, 12 Aug 2008 04:25:11 -0400
From: rcoleburn at scires.com 
To: jay.krell at cornell.edu 
CC: m3devel at elegosoft.com 
Subject: Re: [M3devel] strange problem w/new Image/ImageInit



Jay:



For LOGPIXELS X & Y, I get 96 on the hi-res Dell M4300 system and also on my ThinkPad T60.



I've put together revised versions of Image.i3/m3 and my ScrollerVBTClass.m3.  The good news is that I've managed to get the scroll bar to look correct in both scaled and unscaled modes.



I've added a new procedure to Image.i3/m3 that will force subsequent calls to Scaled() to behave like Unscaled().  Using this, I can get the appearance I need on the hi-res monitor without resorting to changes in the original intent of the Image interface.  The advantage of this procedure is that it does not change the Image interface (except for addition of the procedure) and it therefore won't have any affect on pickles or anyone else's code.  Plus, it lets the programmer override use of Scaled() in all library modules without having to modify any source code.



Before I commit any of these changes, I want to do some more testing and to fix the problem with subwindows (ZChassisVBT) not being able to move.



Alas, my problem of the ZChassisVBTs not being able to move on the hi-res monitor persists with these changes, even though I left the xres/yres at 75.  Of course, these numbers are ignored for Unscaled images anyway.



I'm at a loss to explain this behavior.  Here is what I know based on testing:

1.  Using Scaled images and Image.Raw.xres/yres = 75.0, ZChassisVBT movement works on the hi-res monitor.

2.  Using Scaled images and Image.Raw.xres/yres set to 86.xxx or to 147.xxx, ZChassisVBT movement does not work on the hi-res 147.xxx dpi monitor, but it still works on my 86.xxx dpi monitor

3.  Using Unscaled images, ZChassisVBT movement does not work on the hi-res 147.xxx dpi monitor, but it still works on my 86.xxx dpi monitor



So, there seems to be something in the implementation somewhere of ZChassisVBT, or maybe ZMoveVBT, that doesn't like 147.xxx dpi monitors unless you scale all images assuming they were designed at 75 dpi.  At the 147 dpi, the 75 dpi pixmaps will be scaled by a factor of 2, which corresponds to what I am seeing on the screen.



I'm too sleepy to make any more progress for now.  If anyone has an idea on what to do next, please let me know.  I'm stumped at this point.



Regards,

Randy

>>> Jay  8/11/2008 3:52 PM>>>

Hm. Ok then, where does it get the screen resolution from?

Probably here?

WinScreenType.m3:

PROCEDURE InnerNew ((* IN-OUT *) res: T) =
  BEGIN
    WITH pix_hor = WinUser.GetSystemMetrics(WinUser.SM_CXSCREEN),
         pix_ver = WinUser.GetSystemMetrics(WinUser.SM_CYSCREEN),
         mm_hor  = GetDeviceCaps (WinGDI.HORZSIZE),
         mm_ver  = GetDeviceCaps (WinGDI.VERTSIZE) DO
      res.rootDom := Rect.FromSize(pix_hor, pix_ver);
      res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
      res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);

ok.

Perhaps we should accept the numbers that Windows makes up instead?

GetDeviceCaps(LOGPIXELSX)
and GetDeviceCaps(LOGPIXELSY)

Please try that, in the WinScreenType.m3 code.
With removing ImageInit (or just have it hardcoded at 75).

This will most likely be 96 even on your high dpi system, unless you are on Vista
and tell the system you are high dpi aware.

I think there is disagreement in drawing vs. hit test as to where you are clicking.
Try making ImageInit always 75.
Try making the above convert from a hardcoded 96.
And then try GetDeviceCaps(LOGPIXELSX and Y) -- which I expect always returns 96 for you.
You can plug that into my dpi.c to see what it prints.

I think part of what is happening is that Modula-3 was very rare in doing the right thing for high dpi
monitors. But so much code is wrong that Windows has to counteract the wrongness,
which means Modula-3 needs to go along and do things wrong in order for the counteraction
to leave it doing the right thing also.
I'm not sure.
Oh, and presumably other places in Modula-3 are wrong, and the counteraction works for them.
That's a bit of a mystery -- drawing of pixmaps vs. drawing of everything else.

- Jay


________________________________

Date: Mon, 11 Aug 2008 15:23:17 -0400
From: rcoleburn at scires.com 
To: jay.krell at cornell.edu 
CC: m3devel at elegosoft.com; wagner at elegosoft.com 
Subject: RE: strange problem w/new Image/ImageInit



Jay:



I have been experimenting quite a bit and I've come up with some "new old" information.



I say "new old" because, after spending the time to read some of the comments in the original code (before we modified it), I think I now have a better idea of what the designers intended and why I had/have a problem.



If you read carefully, the xres/yres fields in Image.Raw are supposed to represent the resolution at which the pixmap was originally DEVELOPED, not the resolution of the current screen.  It seems the designers went to great lengths to represent everything as screen-independent until it is actually rendered.



The Image interface gives 3 ways of dealing with pixmaps:  (1) unscaled, (2) scaled, and (3) scaled to "most appropriate".  The change you and I conspired actually changes this behavior to make #2 (scaled) work as #1 (unscaled).  (It probably also changes #3.)  This is the behavior I want for my current program, but it changes the intent of the original interface, so I'm afraid we are going to have to revert all those changes.



Digging deeper into Image.m3, I've discovered that it is smart-enough already to deduce the screen resolution.  If you look into the ApplyScaled1 procedure, you see that it converts the current screen resolution in millimeters to pixels in order to scale the pixmap.  The change we introduced, namely making Raw.xres/yres equal to the current screen resolution, effectively caused the Scaled procedure to do nothing since (ScreenDPI / ImageDPI) = 1.



The problem that brought all this on in the first place is that my GUI was looking bad on the 1920x1200 screen.  The reason I have discovered *now* is that FormsVBT apparently uses the #2 (scaled) version for pixmaps.  In the old code, the interface defaulted the developed resolution of the pixmaps to be 75 dpi.  At my 147+ dpi screen, the scaled implementation would effectively double the size of the pixmap when rendered on the screen in an effort to make the pixmap look the same size on the 147dpi screen that it appeared on a 75 dpi screen.



All of this to say that the changes to Image.i3/m3 need to be undone in order to get back the original intent of the developers.



Of course, once these changes are undone, my problem returns with the GUI looking bad on 1920x1200 at 147+ dpi.  So, how to solve it properly now requires more thought.



I need to do some more reading of the code I guess to see if there is a way already to cause FormsVBT to use unscaled for all pixmaps.  Otherwise, a quick fix would be to add a new procedure to the interface that would force use of the unscaled implementation.



Now, back to the problem of not being able to drag the subwindows, I'm still puzzled.  To test my "understanding" as related above, I went back to the original Image.i3/m3, but this time changed the Scaled procedure to effectively do the same thing as Unscaled.  The pixmaps render fine on the 1920x1200 monitor, but the subwindows still can't be dragged.  If I back out my change to Scaled (effectively, revert to the original Image.m3), the subwindows drag with ease on the 1920x1200 monitor, but of course the pixmaps look bad.  I can't explain this behavior yet.  Any ideas?



Regards,

Randy

>>> Jay  8/11/2008 2:41 PM>>>

MemoryBarrier ensures that all the reads and writes before it finish before any reads and writes after it.
Look at winnt.h or MSDN, as well the comment I put in explains it.
It probably has no effect, since our compiler is not aggressive.
What is confusing in these cases is the compiler and processor both need to be informed.
There is a concurrency issue and the barrier should make extra certain to solve it.

Multiple monitors are not considered.
Do you have them?

Randy, please experiment.
Change the code to return hard coded numbers -- like the old 75.
   Either without the globals, or initialize the globals.
And then add in the the various calls one at a time, ignoring their return values.

Furthermore, I guess you could just say:

    IF xres = 0 THEN Init() END;

and

    IF yres = 0 THEN Init() END;

and maybe change the globals to INTEGER.
Though REAL should be 32 bits and be written atomatically.

The idea is, even if the code does run multiple times concurrently, it should always return the same information.

Anyway, like I said, try various or every combination between the two and find
out which part triggers the difference, then we can think more about just that.

I might be able to get an expert friend to give me some help, later.

- Jay


________________________________

Date: Mon, 11 Aug 2008 12:15:40 -0400
From: rcoleburn at scires.com 
To: jay.krell at cornell.edu 
CC: wagner at elegosoft.com 
Subject: RE: strange problem w/new Image/ImageInit



Jay:



I tested your change, but it has no effect on the problem I am having.  I also tried having the accessor functions just return a hardcoded number, but again, no effect on the problem.  This is real strange to me, because if I remove ImageInit and revert Image.i3/m3 back to the way it was before, the problem disappears.



Questions,

1.  What does the WinNT.MemoryBarrier() call do?

2.  What would happen if this code was run by multiple threads?  Are there any concurrency issues that need to be guarded?

3.  What would happen in the case of multiple monitors at different resolutions?



Regards,

Randy

>>> Jay  8/11/2008 6:46 AM>>>

Also try the change I just commited with ReleaseDC.

- Jay


> From: jayk123 at hotmail.com 
> To: rcoleburn at scires.com 
> CC: wagner at elegosoft.com 
> Subject: RE: strange problem w/new Image/ImageInit
> Date: Mon, 11 Aug 2008 07:51:52 +0000
>
>
> Randy, this makes no sense to me.
> What happens if you just hardcode the numbers instead of computing them?
>
>
> - Jay
>
>
>
>
>
>
> ________________________________
>
>
>
> Date: Mon, 11 Aug 2008 02:55:56 -0400
> From: rcoleburn at scires.com 
> To: jayk123 at hotmail.com 
> CC: Olaf Wagner




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080812/607eed9b/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ScrollerVBTClass.m3
Type: application/octet-stream
Size: 26638 bytes
Desc: not available
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080812/607eed9b/attachment-0006.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Image.m3
Type: application/octet-stream
Size: 29271 bytes
Desc: not available
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080812/607eed9b/attachment-0007.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Image.i3
Type: application/octet-stream
Size: 13111 bytes
Desc: not available
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080812/607eed9b/attachment-0008.obj>

From jay.krell at cornell.edu  Tue Aug 12 21:58:42 2008
From: jay.krell at cornell.edu (Jay)
Date: Tue, 12 Aug 2008 19:58:42 +0000
Subject: [M3devel] strange problem w/new Image/ImageInit
In-Reply-To: <48A17936.1E75.00D7.1@scires.com>
References: <489FAA38.1E75.00D7.1@scires.com>
	<COL101-W158F68823847D036260F0FE6710@phx.gbl>
	<48A02D67.1E75.00D7.1@scires.com>
	<COL101-W13606B4823978F6670D3C9E6710@phx.gbl>
	<48A05960.1E75.00D7.1@scires.com>
	<COL101-W65ECE9C2B48E275288EAF0E6710@phx.gbl>
	<48A110A3.1E75.00D7.1@scires.com>
	<COL101-W48D58C2FBDE5BCD3163650E6700@phx.gbl> 
	<48A17936.1E75.00D7.1@scires.com>
Message-ID: <COL101-W7934CC09223B996946776EE6700@phx.gbl>


Twice I've lost my message here, darnit.
LOGPIXELSX (look it up on MSDN/Google/LiveSearch) is pixels per inch on the x axis. It is stuck at 96 for compatibility. And the docs say it has just one value in a multimon situation.
So you can ask Windows for pixels per inch and get 96.
Or you can ask for pixels and millimeters and do the division and get the truth.
Or you can tell it you are "high dpi aware" on Vista and get the truth either way.
I understand the attempt to do the right thing, but it clearly doesn't work out -- the rest of the gui doesn't scale/move correctly with it.
What makes sense and is ideal is often at odds with the bulk of existing code. The bulk of existing code wins, and sometimes nobody can do the right thing in contradiction do it.
 
 - Jay



Date: Tue, 12 Aug 2008 11:51:25 -0400From: rcoleburn at scires.comTo: jay.krell at cornell.eduCC: m3devel at elegosoft.comSubject: Re: [M3devel] strange problem w/new Image/ImageInit

Jay:
 
Thanks for your insights here.  I'll try some more tests and see what I come up with.  I've attached my current Image.i3/Image.m3 and Win32/ScrollerVBTClass.m3 for your reference.  I've removed use of ImageInit from all of these.  And yes, I have reverted to the 75.0 hardcoded value.
 
Based on my limited understanding of the code, I still think I will get scaled behavior even if Modula-3 thinks the dpi is 96, because 147 / 96 =  1.53125, which rounds to 2.  So my pixmaps will still appear double-size.
 
In actuality, I think Modula-3 is trying to do the right thing with the scaling.  At some point on a high-enough dpi monitor, the pixmaps will be so tiny that you can't really see them if they are unscaled.  I've already observed this with some of my boolean and choice indicators--I had to reduce the shadowsize in order to tell whether the boolean/choice was TRUE or FALSE.  From the way Trestle/FormsVBT are set up, it appears that the designers wanted to get approximately the same size rendering on different dpi screens.  That's why you see millimeters everywhere in the code being converted to pixels.  Indeed, VBT has a procedure MMToPixels that is dependent on getting the screen type of the underlying VBT.T so it can get the ppm setting for this screen and do the computation.  Provided that the underlying implementation gives correct ppm info to Modula-3 for each screen, the current Trestle/FormsVBT should do the right thing even in multiple monitor situations.  I haven't tested this, but I should be able to drag a window from a monitor at one dpi onto a monitor at a different dpi and have everything scale to look correct on the new monitor.
 
The problem in my case with the 1920x1200 monitor is that the scaled pixmaps look huge in proportion to the text and other features of the window.  Maybe this other stuff isn't being scaled the same way pixmaps are scaled.
 
Does LOGPIXELSX stand for Logical Pixels X-Axis ?  I know that Windows has a dpi setting for fonts.  If set to normal, fonts are supposed to render at 96 dpi, but you can switch to large mode and have them rendered at 120 dpi, or you can make up a custom number.  This Windows setting applies only to fonts, not graphical elements.
 
You say that Modula-3 is computing LOGPIXELS via a "seemingly redundant equivalent way."  In my reading of the code in WinScreenType, it appears that Modula-3 is requesting from Windows the actual number of pixels in both axes and also the number of millimeters in both axes.  It uses these to compute the resolution in pixels per millimeter (ppm).  The ppm is what is stored and used internally when scaling pixmaps.  When necessary, ppm is converted to dpi using the formula (dpi = ppm x 25.4).
 
On my 4:3 aspect ratio IBM T60 at 1280x1024, the ppm is 3.41333 in both axes yielding a dpi of 86.698667.
 
On the widescreen (16:10 aspect ratio) Dell 4300 at 1920x1200 the ppm is slightly different in each axis, but is close to 5.8xxx yielding at dpi of 147.xxx  (again, the fractional part is different in each axis).
 
I don't mind running a test program for you on the hi-res system here--just send it to me via email.  I have the VC++ 2008 redistributables installed.
 
I think you are on the west coast and I'm on the east coast, so we have a time difference of 3 hours, but lately I've been working round the clock seemingly, so I'll try to respond with test results as soon as I can.
 
Regards,
Randy>>> Jay <jay.krell at cornell.edu> 8/12/2008 6:49 AM >>>Randy I don't think you need to add a way to use the unscaled data.I think the fix isa) go back to Image hardcoding 75b) Have WinScreenType hardcode 96 or use GetDeviceCaps(LOGPIXELSX Y) -- same thing really.And then see what happens.Basically, the scale of pixmaps and the scale of screens has always been close to 1:1.75:96, close enough.Therefore, unscaled has been the norm.Most GUI code uses GetDeviceCaps(LOGPIXELSX Y) I believe.However, most code is not prepared to get back anything other than 96 from it.Modula-3, at least for the pixmap code, was computing LOGPIXELSX and Y via a seemingly redundant equivalent way.However, my believe is that LOGPIXELSX and Y is forced to lie, but the other route is not.It seems an arbitrary discprecancy, but not beyond imagination.By switching to the lying method, we will get back the nearly unscaled 75:96 behavior.Vista adds a way for an application to declare that it is "high dpi aware", which then makes GetDeviceCaps(LOGPIXELX and Y) report the truth presumably. You can see, by the very existance of this ability to declare that you are high dpi aware -- to declare that your code is merely correct -- that most code is not correct.What remains to be determined is why Modula-3 pixmaps behave "differently" than Modula-3 buttons, text, etc.I also think there is a likely disconnect between painting and hit testing, but this is gross speculation.I should fiddle with the numbers myself.I will go ahead with a+b fairly soon.I will verify the numbers computed in #b before and after.I don't have any high dpi systems, so I expect the numbers to be roughly the same either way.I think the only systems that will see a change are high dpi, and they will see an improvement.Sorry for the back and forth regarding ImageInit -- a medium size change is going to be completely undone.- Jay________________________________Date: Tue, 12 Aug 2008 04:25:11 -0400From: rcoleburn at scires.comTo: jay.krell at cornell.eduCC: m3devel at elegosoft.comSubject: Re: [M3devel] strange problem w/new Image/ImageInitJay:For LOGPIXELS X & Y, I get 96 on the hi-res Dell M4300 system and also on my ThinkPad T60.I've put together revised versions of Image.i3/m3 and my ScrollerVBTClass.m3.  The good news is that I've managed to get the scroll bar to look correct in both scaled and unscaled modes.I've added a new procedure to Image.i3/m3 that will force subsequent calls to Scaled() to behave like Unscaled().  Using this, I can get the appearance I need on the hi-res monitor without resorting to changes in the original intent of the Image interface.  The advantage of this procedure is that it does not change the Image interface (except for addition of the procedure) and it therefore won't have any affect on pickles or anyone else's code.  Plus, it lets the programmer override use of Scaled() in all library modules without having to modify any source code.Before I commit any of these changes, I want to do some more testing and to fix the problem with subwindows (ZChassisVBT) not being able to move.Alas, my problem of the ZChassisVBTs not being able to move on the hi-res monitor persists with these changes, even though I left the xres/yres at 75.  Of course, these numbers are ignored for Unscaled images anyway.I'm at a loss to explain this behavior.  Here is what I know based on testing:1.  Using Scaled images and Image.Raw.xres/yres = 75.0, ZChassisVBT movement works on the hi-res monitor.2.  Using Scaled images and Image.Raw.xres/yres set to 86.xxx or to 147.xxx, ZChassisVBT movement does not work on the hi-res 147.xxx dpi monitor, but it still works on my 86.xxx dpi monitor3.  Using Unscaled images, ZChassisVBT movement does not work on the hi-res 147.xxx dpi monitor, but it still works on my 86.xxx dpi monitorSo, there seems to be something in the implementation somewhere of ZChassisVBT, or maybe ZMoveVBT, that doesn't like 147.xxx dpi monitors unless you scale all images assuming they were designed at 75 dpi.  At the 147 dpi, the 75 dpi pixmaps will be scaled by a factor of 2, which corresponds to what I am seeing on the screen.I'm too sleepy to make any more progress for now.  If anyone has an idea on what to do next, please let me know.  I'm stumped at this point.Regards,Randy>>> Jay  8/11/2008 3:52 PM>>>Hm. Ok then, where does it get the screen resolution from?Probably here?WinScreenType.m3:PROCEDURE InnerNew ((* IN-OUT *) res: T) =  BEGIN    WITH pix_hor = WinUser.GetSystemMetrics(WinUser.SM_CXSCREEN),         pix_ver = WinUser.GetSystemMetrics(WinUser.SM_CYSCREEN),         mm_hor  = GetDeviceCaps (WinGDI.HORZSIZE),         mm_ver  = GetDeviceCaps (WinGDI.VERTSIZE) DO      res.rootDom := Rect.FromSize(pix_hor, pix_ver);      res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);      res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);ok.Perhaps we should accept the numbers that Windows makes up instead?GetDeviceCaps(LOGPIXELSX)and GetDeviceCaps(LOGPIXELSY)Please try that, in the WinScreenType.m3 code.With removing ImageInit (or just have it hardcoded at 75).This will most likely be 96 even on your high dpi system, unless you are on Vistaand tell the system you are high dpi aware.I think there is disagreement in drawing vs. hit test as to where you are clicking.Try making ImageInit always 75.Try making the above convert from a hardcoded 96.And then try GetDeviceCaps(LOGPIXELSX and Y) -- which I expect always returns 96 for you.You can plug that into my dpi.c to see what it prints.I think part of what is happening is that Modula-3 was very rare in doing the right thing for high dpimonitors. But so much code is wrong that Windows has to counteract the wrongness,which means Modula-3 needs to go along and do things wrong in order for the counteractionto leave it doing the right thing also.I'm not sure.Oh, and presumably other places in Modula-3 are wrong, and the counteraction works for them.That's a bit of a mystery -- drawing of pixmaps vs. drawing of everything else.- Jay________________________________Date: Mon, 11 Aug 2008 15:23:17 -0400From: rcoleburn at scires.comTo: jay.krell at cornell.eduCC: m3devel at elegosoft.com; wagner at elegosoft.comSubject: RE: strange problem w/new Image/ImageInitJay:I have been experimenting quite a bit and I've come up with some "new old" information.I say "new old" because, after spending the time to read some of the comments in the original code (before we modified it), I think I now have a better idea of what the designers intended and why I had/have a problem.If you read carefully, the xres/yres fields in Image.Raw are supposed to represent the resolution at which the pixmap was originally DEVELOPED, not the resolution of the current screen.  It seems the designers went to great lengths to represent everything as screen-independent until it is actually rendered.The Image interface gives 3 ways of dealing with pixmaps:  (1) unscaled, (2) scaled, and (3) scaled to "most appropriate".  The change you and I conspired actually changes this behavior to make #2 (scaled) work as #1 (unscaled).  (It probably also changes #3.)  This is the behavior I want for my current program, but it changes the intent of the original interface, so I'm afraid we are going to have to revert all those changes.Digging deeper into Image.m3, I've discovered that it is smart-enough already to deduce the screen resolution.  If you look into the ApplyScaled1 procedure, you see that it converts the current screen resolution in millimeters to pixels in order to scale the pixmap.  The change we introduced, namely making Raw.xres/yres equal to the current screen resolution, effectively caused the Scaled procedure to do nothing since (ScreenDPI / ImageDPI) = 1.The problem that brought all this on in the first place is that my GUI was looking bad on the 1920x1200 screen.  The reason I have discovered *now* is that FormsVBT apparently uses the #2 (scaled) version for pixmaps.  In the old code, the interface defaulted the developed resolution of the pixmaps to be 75 dpi.  At my 147+ dpi screen, the scaled implementation would effectively double the size of the pixmap when rendered on the screen in an effort to make the pixmap look the same size on the 147dpi screen that it appeared on a 75 dpi screen.All of this to say that the changes to Image.i3/m3 need to be undone in order to get back the original intent of the developers.Of course, once these changes are undone, my problem returns with the GUI looking bad on 1920x1200 at 147+ dpi.  So, how to solve it properly now requires more thought.I need to do some more reading of the code I guess to see if there is a way already to cause FormsVBT to use unscaled for all pixmaps.  Otherwise, a quick fix would be to add a new procedure to the interface that would force use of the unscaled implementation.Now, back to the problem of not being able to drag the subwindows, I'm still puzzled.  To test my "understanding" as related above, I went back to the original Image.i3/m3, but this time changed the Scaled procedure to effectively do the same thing as Unscaled.  The pixmaps render fine on the 1920x1200 monitor, but the subwindows still can't be dragged.  If I back out my change to Scaled (effectively, revert to the original Image.m3), the subwindows drag with ease on the 1920x1200 monitor, but of course the pixmaps look bad.  I can't explain this behavior yet.  Any ideas?Regards,Randy>>> Jay  8/11/2008 2:41 PM>>>MemoryBarrier ensures that all the reads and writes before it finish before any reads and writes after it.Look at winnt.h or MSDN, as well the comment I put in explains it.It probably has no effect, since our compiler is not aggressive.What is confusing in these cases is the compiler and processor both need to be informed.There is a concurrency issue and the barrier should make extra certain to solve it.Multiple monitors are not considered.Do you have them?Randy, please experiment.Change the code to return hard coded numbers -- like the old 75.   Either without the globals, or initialize the globals.And then add in the the various calls one at a time, ignoring their return values.Furthermore, I guess you could just say:    IF xres = 0 THEN Init() END;and    IF yres = 0 THEN Init() END;and maybe change the globals to INTEGER.Though REAL should be 32 bits and be written atomatically.The idea is, even if the code does run multiple times concurrently, it should always return the same information.Anyway, like I said, try various or every combination between the two and findout which part triggers the difference, then we can think more about just that.I might be able to get an expert friend to give me some help, later.- Jay________________________________Date: Mon, 11 Aug 2008 12:15:40 -0400From: rcoleburn at scires.comTo: jay.krell at cornell.eduCC: wagner at elegosoft.comSubject: RE: strange problem w/new Image/ImageInitJay:I tested your change, but it has no effect on the problem I am having.  I also tried having the accessor functions just return a hardcoded number, but again, no effect on the problem.  This is real strange to me, because if I remove ImageInit and revert Image.i3/m3 back to the way it was before, the problem disappears.Questions,1.  What does the WinNT.MemoryBarrier() call do?2.  What would happen if this code was run by multiple threads?  Are there any concurrency issues that need to be guarded?3.  What would happen in the case of multiple monitors at different resolutions?Regards,Randy>>> Jay  8/11/2008 6:46 AM>>>Also try the change I just commited with ReleaseDC.- Jay> From: jayk123 at hotmail.com> To: rcoleburn at scires.com> CC: wagner at elegosoft.com> Subject: RE: strange problem w/new Image/ImageInit> Date: Mon, 11 Aug 2008 07:51:52 +0000>>> Randy, this makes no sense to me.> What happens if you just hardcode the numbers instead of computing them?>>> - Jay>>>>>>> ________________________________>>>> Date: Mon, 11 Aug 2008 02:55:56 -0400> From: rcoleburn at scires.com> To: jayk123 at hotmail.com> CC: Olaf Wagner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080812/41806d4a/attachment-0002.html>

From rcoleburn at scires.com  Wed Aug 13 03:04:58 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Tue, 12 Aug 2008 21:04:58 -0400
Subject: [M3devel] strange problem w/new Image/ImageInit
In-Reply-To: <COL101-W7934CC09223B996946776EE6700@phx.gbl>
References: <489FAA38.1E75.00D7.1@scires.com>
	<COL101-W158F68823847D036260F0FE6710@phx.gbl>
	<48A02D67.1E75.00D7.1@scires.com>
	<COL101-W13606B4823978F6670D3C9E6710@phx.gbl>
	<48A05960.1E75.00D7.1@scires.com>
	<COL101-W65ECE9C2B48E275288EAF0E6710@phx.gbl>
	<48A110A3.1E75.00D7.1@scires.com>
	<COL101-W48D58C2FBDE5BCD3163650E6700@phx.gbl>
	<48A17936.1E75.00D7.1@scires.com>
	<COL101-W7934CC09223B996946776EE6700@phx.gbl>
Message-ID: <48A1FAF3.1E75.00D7.1@scires.com>

Jay:
 
So, let me make sure I understand what you are suggesting.
1.  Change WinScreenType to use LOGPIXELS and therefore it will yield 96 dpi.
2.  Test with Image.Raw.res at 75.0, if it doesn't work out, try changing to 96.0.
 
I'll try the above and let you know how it fares.  Or, if I've misunderstood, please correct me.
 
I find it interesting that if you leave Image.Raw.res at 75.0 and use scaled pixmaps, the ZChassisVBT's ZMoveVBT works as expected regardless of what dpi setting Windows reports to Trestle, but if you switch to unscaled pixmaps or if you change the Image.Raw.res to 86 or 147 the ZMoveVBT stops working on the 1920x1200 system yet it continues to work on all other systems I've tested.
 
Regards,
Randy

>>> Jay <jay.krell at cornell.edu> 8/12/2008 3:58 PM >>>
Twice I've lost my message here, darnit.
LOGPIXELSX (look it up on MSDN/Google/LiveSearch) is pixels per inch on the x axis. It is stuck at 96 for compatibility. And the docs say it has just one value in a multimon situation.
So you can ask Windows for pixels per inch and get 96.
Or you can ask for pixels and millimeters and do the division and get the truth.
Or you can tell it you are "high dpi aware" on Vista and get the truth either way.
I understand the attempt to do the right thing, but it clearly doesn't work out -- the rest of the gui doesn't scale/move correctly with it.
What makes sense and is ideal is often at odds with the bulk of existing code. The bulk of existing code wins, and sometimes nobody can do the right thing in contradiction do it.
 
 - Jay



Date: Tue, 12 Aug 2008 11:51:25 -0400
From: rcoleburn at scires.com 
To: jay.krell at cornell.edu 
CC: m3devel at elegosoft.com 
Subject: Re: [M3devel] strange problem w/new Image/ImageInit


Jay:
 
Thanks for your insights here.  I'll try some more tests and see what I come up with.  I've attached my current Image.i3/Image.m3 and Win32/ScrollerVBTClass.m3 for your reference.  I've removed use of ImageInit from all of these.  And yes, I have reverted to the 75.0 hardcoded value.
 
Based on my limited understanding of the code, I still think I will get scaled behavior even if Modula-3 thinks the dpi is 96, because 147 / 96 =  1.53125, which rounds to 2.  So my pixmaps will still appear double-size.
 
In actuality, I think Modula-3 is trying to do the right thing with the scaling.  At some point on a high-enough dpi monitor, the pixmaps will be so tiny that you can't really see them if they are unscaled.  I've already observed this with some of my boolean and choice indicators--I had to reduce the shadowsize in order to tell whether the boolean/choice was TRUE or FALSE.  From the way Trestle/FormsVBT are set up, it appears that the designers wanted to get approximately the same size rendering on different dpi screens.  That's why you see millimeters everywhere in the code being converted to pixels.  Indeed, VBT has a procedure MMToPixels that is dependent on getting the screen type of the underlying VBT.T so it can get the ppm setting for this screen and do the computation.  Provided that the underlying implementation gives correct ppm info to Modula-3 for each screen, the current Trestle/FormsVBT should do the right thing even in multiple monitor situations.  I haven't tested this, but I should be able to drag a window from a monitor at one dpi onto a monitor at a different dpi and have everything scale to look correct on the new monitor.
 
The problem in my case with the 1920x1200 monitor is that the scaled pixmaps look huge in proportion to the text and other features of the window.  Maybe this other stuff isn't being scaled the same way pixmaps are scaled.
 
Does LOGPIXELSX stand for Logical Pixels X-Axis ?  I know that Windows has a dpi setting for fonts.  If set to normal, fonts are supposed to render at 96 dpi, but you can switch to large mode and have them rendered at 120 dpi, or you can make up a custom number.  This Windows setting applies only to fonts, not graphical elements.
 
You say that Modula-3 is computing LOGPIXELS via a "seemingly redundant equivalent way."  In my reading of the code in WinScreenType, it appears that Modula-3 is requesting from Windows the actual number of pixels in both axes and also the number of millimeters in both axes.  It uses these to compute the resolution in pixels per millimeter (ppm).  The ppm is what is stored and used internally when scaling pixmaps.  When necessary, ppm is converted to dpi using the formula (dpi = ppm x 25.4).
 
On my 4:3 aspect ratio IBM T60 at 1280x1024, the ppm is 3.41333 in both axes yielding a dpi of 86.698667.
 
On the widescreen (16:10 aspect ratio) Dell 4300 at 1920x1200 the ppm is slightly different in each axis, but is close to 5.8xxx yielding at dpi of 147.xxx  (again, the fractional part is different in each axis).
 
I don't mind running a test program for you on the hi-res system here--just send it to me via email.  I have the VC++ 2008 redistributables installed.
 
I think you are on the west coast and I'm on the east coast, so we have a time difference of 3 hours, but lately I've been working round the clock seemingly, so I'll try to respond with test results as soon as I can.
 
Regards,
Randy

>>> Jay <jay.krell at cornell.edu> 8/12/2008 6:49 AM >>>

Randy I don't think you need to add a way to use the unscaled data.
I think the fix is
a) go back to Image hardcoding 75
b) Have WinScreenType hardcode 96 or use GetDeviceCaps(LOGPIXELSX Y) -- same thing really.
And then see what happens.

Basically, the scale of pixmaps and the scale of screens has always been close to 1:1.
75:96, close enough.
Therefore, unscaled has been the norm.

Most GUI code uses GetDeviceCaps(LOGPIXELSX Y) I believe.
However, most code is not prepared to get back anything other than 96 from it.

Modula-3, at least for the pixmap code, was computing LOGPIXELSX and Y via a seemingly redundant equivalent way.
However, my believe is that LOGPIXELSX and Y is forced to lie, but the other route is not.
It seems an arbitrary discprecancy, but not beyond imagination.

By switching to the lying method, we will get back the nearly unscaled 75:96 behavior.

Vista adds a way for an application to declare that it is "high dpi aware", which then makes GetDeviceCaps(LOGPIXELX and Y) report the truth presumably. You can see, by the very existance of this ability to declare that you are high dpi aware -- to declare that your code is merely correct -- that most code is not correct.

What remains to be determined is why Modula-3 pixmaps behave "differently" than Modula-3 buttons, text, etc.

I also think there is a likely disconnect between painting and hit testing, but this is gross speculation.
I should fiddle with the numbers myself.

I will go ahead with a+b fairly soon.
I will verify the numbers computed in #b before and after.
I don't have any high dpi systems, so I expect the numbers to be roughly the same either way.
I think the only systems that will see a change are high dpi, and they will see an improvement.

Sorry for the back and forth regarding ImageInit -- a medium size change is going to be completely undone.

- Jay

________________________________

Date: Tue, 12 Aug 2008 04:25:11 -0400
From: rcoleburn at scires.com 
To: jay.krell at cornell.edu 
CC: m3devel at elegosoft.com 
Subject: Re: [M3devel] strange problem w/new Image/ImageInit



Jay:



For LOGPIXELS X & Y, I get 96 on the hi-res Dell M4300 system and also on my ThinkPad T60.



I've put together revised versions of Image.i3/m3 and my ScrollerVBTClass.m3.  The good news is that I've managed to get the scroll bar to look correct in both scaled and unscaled modes.



I've added a new procedure to Image.i3/m3 that will force subsequent calls to Scaled() to behave like Unscaled().  Using this, I can get the appearance I need on the hi-res monitor without resorting to changes in the original intent of the Image interface.  The advantage of this procedure is that it does not change the Image interface (except for addition of the procedure) and it therefore won't have any affect on pickles or anyone else's code.  Plus, it lets the programmer override use of Scaled() in all library modules without having to modify any source code.



Before I commit any of these changes, I want to do some more testing and to fix the problem with subwindows (ZChassisVBT) not being able to move.



Alas, my problem of the ZChassisVBTs not being able to move on the hi-res monitor persists with these changes, even though I left the xres/yres at 75.  Of course, these numbers are ignored for Unscaled images anyway.



I'm at a loss to explain this behavior.  Here is what I know based on testing:

1.  Using Scaled images and Image.Raw.xres/yres = 75.0, ZChassisVBT movement works on the hi-res monitor.

2.  Using Scaled images and Image.Raw.xres/yres set to 86.xxx or to 147.xxx, ZChassisVBT movement does not work on the hi-res 147.xxx dpi monitor, but it still works on my 86.xxx dpi monitor

3.  Using Unscaled images, ZChassisVBT movement does not work on the hi-res 147.xxx dpi monitor, but it still works on my 86.xxx dpi monitor



So, there seems to be something in the implementation somewhere of ZChassisVBT, or maybe ZMoveVBT, that doesn't like 147.xxx dpi monitors unless you scale all images assuming they were designed at 75 dpi.  At the 147 dpi, the 75 dpi pixmaps will be scaled by a factor of 2, which corresponds to what I am seeing on the screen.



I'm too sleepy to make any more progress for now.  If anyone has an idea on what to do next, please let me know.  I'm stumped at this point.



Regards,

Randy

>>> Jay  8/11/2008 3:52 PM>>>

Hm. Ok then, where does it get the screen resolution from?

Probably here?

WinScreenType.m3:

PROCEDURE InnerNew ((* IN-OUT *) res: T) =
  BEGIN
    WITH pix_hor = WinUser.GetSystemMetrics(WinUser.SM_CXSCREEN),
         pix_ver = WinUser.GetSystemMetrics(WinUser.SM_CYSCREEN),
         mm_hor  = GetDeviceCaps (WinGDI.HORZSIZE),
         mm_ver  = GetDeviceCaps (WinGDI.VERTSIZE) DO
      res.rootDom := Rect.FromSize(pix_hor, pix_ver);
      res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);
      res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);

ok.

Perhaps we should accept the numbers that Windows makes up instead?

GetDeviceCaps(LOGPIXELSX)
and GetDeviceCaps(LOGPIXELSY)

Please try that, in the WinScreenType.m3 code.
With removing ImageInit (or just have it hardcoded at 75).

This will most likely be 96 even on your high dpi system, unless you are on Vista
and tell the system you are high dpi aware.

I think there is disagreement in drawing vs. hit test as to where you are clicking.
Try making ImageInit always 75.
Try making the above convert from a hardcoded 96.
And then try GetDeviceCaps(LOGPIXELSX and Y) -- which I expect always returns 96 for you.
You can plug that into my dpi.c to see what it prints.

I think part of what is happening is that Modula-3 was very rare in doing the right thing for high dpi
monitors. But so much code is wrong that Windows has to counteract the wrongness,
which means Modula-3 needs to go along and do things wrong in order for the counteraction
to leave it doing the right thing also.
I'm not sure.
Oh, and presumably other places in Modula-3 are wrong, and the counteraction works for them.
That's a bit of a mystery -- drawing of pixmaps vs. drawing of everything else.

- Jay


________________________________

Date: Mon, 11 Aug 2008 15:23:17 -0400
From: rcoleburn at scires.com 
To: jay.krell at cornell.edu 
CC: m3devel at elegosoft.com; wagner at elegosoft.com 
Subject: RE: strange problem w/new Image/ImageInit



Jay:



I have been experimenting quite a bit and I've come up with some "new old" information.



I say "new old" because, after spending the time to read some of the comments in the original code (before we modified it), I think I now have a better idea of what the designers intended and why I had/have a problem.



If you read carefully, the xres/yres fields in Image.Raw are supposed to represent the resolution at which the pixmap was originally DEVELOPED, not the resolution of the current screen.  It seems the designers went to great lengths to represent everything as screen-independent until it is actually rendered.



The Image interface gives 3 ways of dealing with pixmaps:  (1) unscaled, (2) scaled, and (3) scaled to "most appropriate".  The change you and I conspired actually changes this behavior to make #2 (scaled) work as #1 (unscaled).  (It probably also changes #3.)  This is the behavior I want for my current program, but it changes the intent of the original interface, so I'm afraid we are going to have to revert all those changes.



Digging deeper into Image.m3, I've discovered that it is smart-enough already to deduce the screen resolution.  If you look into the ApplyScaled1 procedure, you see that it converts the current screen resolution in millimeters to pixels in order to scale the pixmap.  The change we introduced, namely making Raw.xres/yres equal to the current screen resolution, effectively caused the Scaled procedure to do nothing since (ScreenDPI / ImageDPI) = 1.



The problem that brought all this on in the first place is that my GUI was looking bad on the 1920x1200 screen.  The reason I have discovered *now* is that FormsVBT apparently uses the #2 (scaled) version for pixmaps.  In the old code, the interface defaulted the developed resolution of the pixmaps to be 75 dpi.  At my 147+ dpi screen, the scaled implementation would effectively double the size of the pixmap when rendered on the screen in an effort to make the pixmap look the same size on the 147dpi screen that it appeared on a 75 dpi screen.



All of this to say that the changes to Image.i3/m3 need to be undone in order to get back the original intent of the developers.



Of course, once these changes are undone, my problem returns with the GUI looking bad on 1920x1200 at 147+ dpi.  So, how to solve it properly now requires more thought.



I need to do some more reading of the code I guess to see if there is a way already to cause FormsVBT to use unscaled for all pixmaps.  Otherwise, a quick fix would be to add a new procedure to the interface that would force use of the unscaled implementation.



Now, back to the problem of not being able to drag the subwindows, I'm still puzzled.  To test my "understanding" as related above, I went back to the original Image.i3/m3, but this time changed the Scaled procedure to effectively do the same thing as Unscaled.  The pixmaps render fine on the 1920x1200 monitor, but the subwindows still can't be dragged.  If I back out my change to Scaled (effectively, revert to the original Image.m3), the subwindows drag with ease on the 1920x1200 monitor, but of course the pixmaps look bad.  I can't explain this behavior yet.  Any ideas?



Regards,

Randy

>>> Jay  8/11/2008 2:41 PM>>>

MemoryBarrier ensures that all the reads and writes before it finish before any reads and writes after it.
Look at winnt.h or MSDN, as well the comment I put in explains it.
It probably has no effect, since our compiler is not aggressive.
What is confusing in these cases is the compiler and processor both need to be informed.
There is a concurrency issue and the barrier should make extra certain to solve it.

Multiple monitors are not considered.
Do you have them?

Randy, please experiment.
Change the code to return hard coded numbers -- like the old 75.
   Either without the globals, or initialize the globals.
And then add in the the various calls one at a time, ignoring their return values.

Furthermore, I guess you could just say:

    IF xres = 0 THEN Init() END;

and

    IF yres = 0 THEN Init() END;

and maybe change the globals to INTEGER.
Though REAL should be 32 bits and be written atomatically.

The idea is, even if the code does run multiple times concurrently, it should always return the same information.

Anyway, like I said, try various or every combination between the two and find
out which part triggers the difference, then we can think more about just that.

I might be able to get an expert friend to give me some help, later.

- Jay


________________________________

Date: Mon, 11 Aug 2008 12:15:40 -0400
From: rcoleburn at scires.com 
To: jay.krell at cornell.edu 
CC: wagner at elegosoft.com 
Subject: RE: strange problem w/new Image/ImageInit



Jay:



I tested your change, but it has no effect on the problem I am having.  I also tried having the accessor functions just return a hardcoded number, but again, no effect on the problem.  This is real strange to me, because if I remove ImageInit and revert Image.i3/m3 back to the way it was before, the problem disappears.



Questions,

1.  What does the WinNT.MemoryBarrier() call do?

2.  What would happen if this code was run by multiple threads?  Are there any concurrency issues that need to be guarded?

3.  What would happen in the case of multiple monitors at different resolutions?



Regards,

Randy

>>> Jay  8/11/2008 6:46 AM>>>

Also try the change I just commited with ReleaseDC.

- Jay


> From: jayk123 at hotmail.com 
> To: rcoleburn at scires.com 
> CC: wagner at elegosoft.com 
> Subject: RE: strange problem w/new Image/ImageInit
> Date: Mon, 11 Aug 2008 07:51:52 +0000
>
>
> Randy, this makes no sense to me.
> What happens if you just hardcode the numbers instead of computing them?
>
>
> - Jay
>
>
>
>
>
>
> ________________________________
>
>
>
> Date: Mon, 11 Aug 2008 02:55:56 -0400
> From: rcoleburn at scires.com 
> To: jayk123 at hotmail.com 
> CC: Olaf Wagner




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080812/feddefb6/attachment-0002.html>

From jay.krell at cornell.edu  Wed Aug 13 05:17:22 2008
From: jay.krell at cornell.edu (Jay)
Date: Wed, 13 Aug 2008 03:17:22 +0000
Subject: [M3devel] strange problem w/new Image/ImageInit
In-Reply-To: <48A1FAF3.1E75.00D7.1@scires.com>
References: <489FAA38.1E75.00D7.1@scires.com>
	<COL101-W158F68823847D036260F0FE6710@phx.gbl>
	<48A02D67.1E75.00D7.1@scires.com>
	<COL101-W13606B4823978F6670D3C9E6710@phx.gbl>
	<48A05960.1E75.00D7.1@scires.com>
	<COL101-W65ECE9C2B48E275288EAF0E6710@phx.gbl>
	<48A110A3.1E75.00D7.1@scires.com>
	<COL101-W48D58C2FBDE5BCD3163650E6700@phx.gbl>
	<48A17936.1E75.00D7.1@scires.com>
	<COL101-W7934CC09223B996946776EE6700@phx.gbl> 
	<48A1FAF3.1E75.00D7.1@scires.com>
Message-ID: <COL101-W56F9FEE075B5A2C956F192E6730@phx.gbl>


1 and 2 correct. I expect 75 will do for #2.#1 you can verify and not just run blind. Print it, or use the C code, or maybe you already did.
The ratio of these numbers is the "problem". You asked for "unscaled", I suggest 75/96 or 96/75, close to unscalled, and should be about the same as it has been doing on most machines all along -- most machines having close to 96 actual dpi. (We should probably do a quick survey of that.)
 
Is there a way to fiddle with the numbers that breaks movement on all machines?I should try and look for that.
 
 - Jay



Date: Tue, 12 Aug 2008 21:04:58 -0400From: rcoleburn at scires.comTo: jay.krell at cornell.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] strange problem w/new Image/ImageInit



Jay:
 
So, let me make sure I understand what you are suggesting.
1.  Change WinScreenType to use LOGPIXELS and therefore it will yield 96 dpi.
2.  Test with Image.Raw.res at 75.0, if it doesn't work out, try changing to 96.0.
 
I'll try the above and let you know how it fares.  Or, if I've misunderstood, please correct me.
 
I find it interesting that if you leave Image.Raw.res at 75.0 and use scaled pixmaps, the ZChassisVBT's ZMoveVBT works as expected regardless of what dpi setting Windows reports to Trestle, but if you switch to unscaled pixmaps or if you change the Image.Raw.res to 86 or 147 the ZMoveVBT stops working on the 1920x1200 system yet it continues to work on all other systems I've tested.
 
Regards,
Randy>>> Jay <jay.krell at cornell.edu> 8/12/2008 3:58 PM >>>Twice I've lost my message here, darnit.LOGPIXELSX (look it up on MSDN/Google/LiveSearch) is pixels per inch on the x axis. It is stuck at 96 for compatibility. And the docs say it has just one value in a multimon situation.So you can ask Windows for pixels per inch and get 96.Or you can ask for pixels and millimeters and do the division and get the truth.Or you can tell it you are "high dpi aware" on Vista and get the truth either way.I understand the attempt to do the right thing, but it clearly doesn't work out -- the rest of the gui doesn't scale/move correctly with it.What makes sense and is ideal is often at odds with the bulk of existing code. The bulk of existing code wins, and sometimes nobody can do the right thing in contradiction do it.  - Jay



Date: Tue, 12 Aug 2008 11:51:25 -0400From: rcoleburn at scires.comTo: jay.krell at cornell.eduCC: m3devel at elegosoft.comSubject: Re: [M3devel] strange problem w/new Image/ImageInit
Jay:
 
Thanks for your insights here.  I'll try some more tests and see what I come up with.  I've attached my current Image.i3/Image.m3 and Win32/ScrollerVBTClass.m3 for your reference.  I've removed use of ImageInit from all of these.  And yes, I have reverted to the 75.0 hardcoded value.
 
Based on my limited understanding of the code, I still think I will get scaled behavior even if Modula-3 thinks the dpi is 96, because 147 / 96 =  1.53125, which rounds to 2.  So my pixmaps will still appear double-size.
 
In actuality, I think Modula-3 is trying to do the right thing with the scaling.  At some point on a high-enough dpi monitor, the pixmaps will be so tiny that you can't really see them if they are unscaled.  I've already observed this with some of my boolean and choice indicators--I had to reduce the shadowsize in order to tell whether the boolean/choice was TRUE or FALSE.  From the way Trestle/FormsVBT are set up, it appears that the designers wanted to get approximately the same size rendering on different dpi screens.  That's why you see millimeters everywhere in the code being converted to pixels.  Indeed, VBT has a procedure MMToPixels that is dependent on getting the screen type of the underlying VBT.T so it can get the ppm setting for this screen and do the computation.  Provided that the underlying implementation gives correct ppm info to Modula-3 for each screen, the current Trestle/FormsVBT should do the right thing even in multiple monitor situations.  I haven't tested this, but I should be able to drag a window from a monitor at one dpi onto a monitor at a different dpi and have everything scale to look correct on the new monitor.
 
The problem in my case with the 1920x1200 monitor is that the scaled pixmaps look huge in proportion to the text and other features of the window.  Maybe this other stuff isn't being scaled the same way pixmaps are scaled.
 
Does LOGPIXELSX stand for Logical Pixels X-Axis ?  I know that Windows has a dpi setting for fonts.  If set to normal, fonts are supposed to render at 96 dpi, but you can switch to large mode and have them rendered at 120 dpi, or you can make up a custom number.  This Windows setting applies only to fonts, not graphical elements.
 
You say that Modula-3 is computing LOGPIXELS via a "seemingly redundant equivalent way."  In my reading of the code in WinScreenType, it appears that Modula-3 is requesting from Windows the actual number of pixels in both axes and also the number of millimeters in both axes.  It uses these to compute the resolution in pixels per millimeter (ppm).  The ppm is what is stored and used internally when scaling pixmaps.  When necessary, ppm is converted to dpi using the formula (dpi = ppm x 25.4).
 
On my 4:3 aspect ratio IBM T60 at 1280x1024, the ppm is 3.41333 in both axes yielding a dpi of 86.698667.
 
On the widescreen (16:10 aspect ratio) Dell 4300 at 1920x1200 the ppm is slightly different in each axis, but is close to 5.8xxx yielding at dpi of 147.xxx  (again, the fractional part is different in each axis).
 
I don't mind running a test program for you on the hi-res system here--just send it to me via email.  I have the VC++ 2008 redistributables installed.
 
I think you are on the west coast and I'm on the east coast, so we have a time difference of 3 hours, but lately I've been working round the clock seemingly, so I'll try to respond with test results as soon as I can.
 
Regards,
Randy>>> Jay <jay.krell at cornell.edu> 8/12/2008 6:49 AM >>>Randy I don't think you need to add a way to use the unscaled data.I think the fix isa) go back to Image hardcoding 75b) Have WinScreenType hardcode 96 or use GetDeviceCaps(LOGPIXELSX Y) -- same thing really.And then see what happens.Basically, the scale of pixmaps and the scale of screens has always been close to 1:1.75:96, close enough.Therefore, unscaled has been the norm.Most GUI code uses GetDeviceCaps(LOGPIXELSX Y) I believe.However, most code is not prepared to get back anything other than 96 from it.Modula-3, at least for the pixmap code, was computing LOGPIXELSX and Y via a seemingly redundant equivalent way.However, my believe is that LOGPIXELSX and Y is forced to lie, but the other route is not.It seems an arbitrary discprecancy, but not beyond imagination.By switching to the lying method, we will get back the nearly unscaled 75:96 behavior.Vista adds a way for an application to declare that it is "high dpi aware", which then makes GetDeviceCaps(LOGPIXELX and Y) report the truth presumably. You can see, by the very existance of this ability to declare that you are high dpi aware -- to declare that your code is merely correct -- that most code is not correct.What remains to be determined is why Modula-3 pixmaps behave "differently" than Modula-3 buttons, text, etc.I also think there is a likely disconnect between painting and hit testing, but this is gross speculation.I should fiddle with the numbers myself.I will go ahead with a+b fairly soon.I will verify the numbers computed in #b before and after.I don't have any high dpi systems, so I expect the numbers to be roughly the same either way.I think the only systems that will see a change are high dpi, and they will see an improvement.Sorry for the back and forth regarding ImageInit -- a medium size change is going to be completely undone.- Jay________________________________Date: Tue, 12 Aug 2008 04:25:11 -0400From: rcoleburn at scires.comTo: jay.krell at cornell.eduCC: m3devel at elegosoft.comSubject: Re: [M3devel] strange problem w/new Image/ImageInitJay:For LOGPIXELS X & Y, I get 96 on the hi-res Dell M4300 system and also on my ThinkPad T60.I've put together revised versions of Image.i3/m3 and my ScrollerVBTClass.m3.  The good news is that I've managed to get the scroll bar to look correct in both scaled and unscaled modes.I've added a new procedure to Image.i3/m3 that will force subsequent calls to Scaled() to behave like Unscaled().  Using this, I can get the appearance I need on the hi-res monitor without resorting to changes in the original intent of the Image interface.  The advantage of this procedure is that it does not change the Image interface (except for addition of the procedure) and it therefore won't have any affect on pickles or anyone else's code.  Plus, it lets the programmer override use of Scaled() in all library modules without having to modify any source code.Before I commit any of these changes, I want to do some more testing and to fix the problem with subwindows (ZChassisVBT) not being able to move.Alas, my problem of the ZChassisVBTs not being able to move on the hi-res monitor persists with these changes, even though I left the xres/yres at 75.  Of course, these numbers are ignored for Unscaled images anyway.I'm at a loss to explain this behavior.  Here is what I know based on testing:1.  Using Scaled images and Image.Raw.xres/yres = 75.0, ZChassisVBT movement works on the hi-res monitor.2.  Using Scaled images and Image.Raw.xres/yres set to 86.xxx or to 147.xxx, ZChassisVBT movement does not work on the hi-res 147.xxx dpi monitor, but it still works on my 86.xxx dpi monitor3.  Using Unscaled images, ZChassisVBT movement does not work on the hi-res 147.xxx dpi monitor, but it still works on my 86.xxx dpi monitorSo, there seems to be something in the implementation somewhere of ZChassisVBT, or maybe ZMoveVBT, that doesn't like 147.xxx dpi monitors unless you scale all images assuming they were designed at 75 dpi.  At the 147 dpi, the 75 dpi pixmaps will be scaled by a factor of 2, which corresponds to what I am seeing on the screen.I'm too sleepy to make any more progress for now.  If anyone has an idea on what to do next, please let me know.  I'm stumped at this point.Regards,Randy>>> Jay  8/11/2008 3:52 PM>>>Hm. Ok then, where does it get the screen resolution from?Probably here?WinScreenType.m3:PROCEDURE InnerNew ((* IN-OUT *) res: T) =  BEGIN    WITH pix_hor = WinUser.GetSystemMetrics(WinUser.SM_CXSCREEN),         pix_ver = WinUser.GetSystemMetrics(WinUser.SM_CYSCREEN),         mm_hor  = GetDeviceCaps (WinGDI.HORZSIZE),         mm_ver  = GetDeviceCaps (WinGDI.VERTSIZE) DO      res.rootDom := Rect.FromSize(pix_hor, pix_ver);      res.res[Axis.T.Hor] := FLOAT(pix_hor) / FLOAT(mm_hor);      res.res[Axis.T.Ver] := FLOAT(pix_ver) / FLOAT(mm_ver);ok.Perhaps we should accept the numbers that Windows makes up instead?GetDeviceCaps(LOGPIXELSX)and GetDeviceCaps(LOGPIXELSY)Please try that, in the WinScreenType.m3 code.With removing ImageInit (or just have it hardcoded at 75).This will most likely be 96 even on your high dpi system, unless you are on Vistaand tell the system you are high dpi aware.I think there is disagreement in drawing vs. hit test as to where you are clicking.Try making ImageInit always 75.Try making the above convert from a hardcoded 96.And then try GetDeviceCaps(LOGPIXELSX and Y) -- which I expect always returns 96 for you.You can plug that into my dpi.c to see what it prints.I think part of what is happening is that Modula-3 was very rare in doing the right thing for high dpimonitors. But so much code is wrong that Windows has to counteract the wrongness,which means Modula-3 needs to go along and do things wrong in order for the counteractionto leave it doing the right thing also.I'm not sure.Oh, and presumably other places in Modula-3 are wrong, and the counteraction works for them.That's a bit of a mystery -- drawing of pixmaps vs. drawing of everything else.- Jay________________________________Date: Mon, 11 Aug 2008 15:23:17 -0400From: rcoleburn at scires.comTo: jay.krell at cornell.eduCC: m3devel at elegosoft.com; wagner at elegosoft.comSubject: RE: strange problem w/new Image/ImageInitJay:I have been experimenting quite a bit and I've come up with some "new old" information.I say "new old" because, after spending the time to read some of the comments in the original code (before we modified it), I think I now have a better idea of what the designers intended and why I had/have a problem.If you read carefully, the xres/yres fields in Image.Raw are supposed to represent the resolution at which the pixmap was originally DEVELOPED, not the resolution of the current screen.  It seems the designers went to great lengths to represent everything as screen-independent until it is actually rendered.The Image interface gives 3 ways of dealing with pixmaps:  (1) unscaled, (2) scaled, and (3) scaled to "most appropriate".  The change you and I conspired actually changes this behavior to make #2 (scaled) work as #1 (unscaled).  (It probably also changes #3.)  This is the behavior I want for my current program, but it changes the intent of the original interface, so I'm afraid we are going to have to revert all those changes.Digging deeper into Image.m3, I've discovered that it is smart-enough already to deduce the screen resolution.  If you look into the ApplyScaled1 procedure, you see that it converts the current screen resolution in millimeters to pixels in order to scale the pixmap.  The change we introduced, namely making Raw.xres/yres equal to the current screen resolution, effectively caused the Scaled procedure to do nothing since (ScreenDPI / ImageDPI) = 1.The problem that brought all this on in the first place is that my GUI was looking bad on the 1920x1200 screen.  The reason I have discovered *now* is that FormsVBT apparently uses the #2 (scaled) version for pixmaps.  In the old code, the interface defaulted the developed resolution of the pixmaps to be 75 dpi.  At my 147+ dpi screen, the scaled implementation would effectively double the size of the pixmap when rendered on the screen in an effort to make the pixmap look the same size on the 147dpi screen that it appeared on a 75 dpi screen.All of this to say that the changes to Image.i3/m3 need to be undone in order to get back the original intent of the developers.Of course, once these changes are undone, my problem returns with the GUI looking bad on 1920x1200 at 147+ dpi.  So, how to solve it properly now requires more thought.I need to do some more reading of the code I guess to see if there is a way already to cause FormsVBT to use unscaled for all pixmaps.  Otherwise, a quick fix would be to add a new procedure to the interface that would force use of the unscaled implementation.Now, back to the problem of not being able to drag the subwindows, I'm still puzzled.  To test my "understanding" as related above, I went back to the original Image.i3/m3, but this time changed the Scaled procedure to effectively do the same thing as Unscaled.  The pixmaps render fine on the 1920x1200 monitor, but the subwindows still can't be dragged.  If I back out my change to Scaled (effectively, revert to the original Image.m3), the subwindows drag with ease on the 1920x1200 monitor, but of course the pixmaps look bad.  I can't explain this behavior yet.  Any ideas?Regards,Randy>>> Jay  8/11/2008 2:41 PM>>>MemoryBarrier ensures that all the reads and writes before it finish before any reads and writes after it.Look at winnt.h or MSDN, as well the comment I put in explains it.It probably has no effect, since our compiler is not aggressive.What is confusing in these cases is the compiler and processor both need to be informed.There is a concurrency issue and the barrier should make extra certain to solve it.Multiple monitors are not considered.Do you have them?Randy, please experiment.Change the code to return hard coded numbers -- like the old 75.   Either without the globals, or initialize the globals.And then add in the the various calls one at a time, ignoring their return values.Furthermore, I guess you could just say:    IF xres = 0 THEN Init() END;and    IF yres = 0 THEN Init() END;and maybe change the globals to INTEGER.Though REAL should be 32 bits and be written atomatically.The idea is, even if the code does run multiple times concurrently, it should always return the same information.Anyway, like I said, try various or every combination between the two and findout which part triggers the difference, then we can think more about just that.I might be able to get an expert friend to give me some help, later.- Jay________________________________Date: Mon, 11 Aug 2008 12:15:40 -0400From: rcoleburn at scires.comTo: jay.krell at cornell.eduCC: wagner at elegosoft.comSubject: RE: strange problem w/new Image/ImageInitJay:I tested your change, but it has no effect on the problem I am having.  I also tried having the accessor functions just return a hardcoded number, but again, no effect on the problem.  This is real strange to me, because if I remove ImageInit and revert Image.i3/m3 back to the way it was before, the problem disappears.Questions,1.  What does the WinNT.MemoryBarrier() call do?2.  What would happen if this code was run by multiple threads?  Are there any concurrency issues that need to be guarded?3.  What would happen in the case of multiple monitors at different resolutions?Regards,Randy>>> Jay  8/11/2008 6:46 AM>>>Also try the change I just commited with ReleaseDC.- Jay> From: jayk123 at hotmail.com> To: rcoleburn at scires.com> CC: wagner at elegosoft.com> Subject: RE: strange problem w/new Image/ImageInit> Date: Mon, 11 Aug 2008 07:51:52 +0000>>> Randy, this makes no sense to me.> What happens if you just hardcode the numbers instead of computing them?>>> - Jay>>>>>>> ________________________________>>>> Date: Mon, 11 Aug 2008 02:55:56 -0400> From: rcoleburn at scires.com> To: jayk123 at hotmail.com> CC: Olaf Wagner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080813/0d8a70e0/attachment-0002.html>

From jay.krell at cornell.edu  Wed Aug 13 13:31:05 2008
From: jay.krell at cornell.edu (Jay)
Date: Wed, 13 Aug 2008 11:31:05 +0000
Subject: [M3devel] FW: [M3commit] CVS Update: cm3
In-Reply-To: <20080813111059.33D8010D4DFE@birch.elegosoft.com>
References: <20080813111059.33D8010D4DFE@birch.elegosoft.com>
Message-ID: <COL101-W464DEDAFAE6F8583491CF0E6730@phx.gbl>


Randy, sorry
1) I didn't realize the functions were in use.
2) I couldn't figure out what each number means. I did try varying them and seeing the affect.
I think maybe I need to learn the X Windows terms? I know in Mac/Windows the part you can drag is the "thumb".

I think I preserved your intent. Feel free to reinstate your intent.
I brought up formsedit and only could easily see a vertical scrollbar.
It doesn't look right to me, but I suspect it is.
If the layers of Trestle could be understand and plowed through, DrawFrameControl would be good.
I've misplaced my Nelson. I'll get another and see if I can understand this..
I'm also curious to see if Tk and Qt draw scrollbars themselves or not.
I'll probably check soon (or by end of month, will be gone next week, out of touch).

 - Jay




----------------------------------------
[big mess made by the ever non-working email systems..]
> Date: Wed, 13 Aug 2008 13:10:59 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT:	/usr/cvs
> Changes by:	jkrell at birch.	08/08/13 13:10:59
> 
> Modified files:
> 	cm3/m3-ui/vbtkit/src/lego/WIN32/: ScrollerVBTClass.m3 
> 
> Log message:
> 	fix it to compile, at least
> 	and eliminate common subexpressions
> 	will see if we can get Windows to draw much more of this
> 	using DrawFrameControl
> 


From martinbishop at bellsouth.net  Thu Aug 14 01:22:28 2008
From: martinbishop at bellsouth.net (Martin Bishop)
Date: Wed, 13 Aug 2008 18:22:28 -0500
Subject: [M3devel] CM3IDE
Message-ID: <48A36CB4.3050005@bellsouth.net>

I asked this on the mailing list, but I'll ask here too.

I compiled CM3, and all went well, but when I try to run "cm3ide" it
asks me for browser and editor to use, which I tell it, and then it just
hangs.

I tried going to http://localhost:3800, but it doesn't appear any
service is running (browser just gives an error)


From martinbishop at bellsouth.net  Thu Aug 14 01:57:42 2008
From: martinbishop at bellsouth.net (Martin Bishop)
Date: Wed, 13 Aug 2008 18:57:42 -0500
Subject: [M3devel] CM3IDE
In-Reply-To: <48A36CB4.3050005@bellsouth.net>
References: <48A36CB4.3050005@bellsouth.net>
Message-ID: <48A374F6.4090409@bellsouth.net>

Martin Bishop wrote:
> I asked this on the mailing list, but I'll ask here too.
> 
> I compiled CM3, and all went well, but when I try to run "cm3ide" it
> asks me for browser and editor to use, which I tell it, and then it just
> hangs.
> 
> I tried going to http://localhost:3800, but it doesn't appear any
> service is running (browser just gives an error)
> 

Of course I meant on the usenet group, as this IS the mailing list :P


From rcoleburn at scires.com  Thu Aug 14 05:30:23 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Wed, 13 Aug 2008 23:30:23 -0400
Subject: [M3devel] FW: [M3commit] CVS Update: cm3
Message-ID: <48A36E8F020000D7000461EC@SRCMAIL.scires.com>

Jay:

I have a "working" version of the Win32 version of the ScrollerVBTClass.m3.  I put "working" in quotes because some of the behavior is a bit awkward.  Actually, I've been working on an improved version, but wasn't ready to release it yet.

This Win32 version came from an effort where my company paid Critical Mass to make some modifications to Trestle/FormsVBT to make it appear more like Microsoft Windows.  Unfortunately, the CMass effort on the scroll bar didn't turn out as well as some of their other efforts.  

I've made some improvements in it recently, and I think the version I emailed to you contained some of those improvements.

One of the big issues is that the platform-independent interface for the scroll bar defines things very differently from Windows.  For example, you use the left button to scroll forward and the right button to scroll backward, and then there is the whole issue of scrolling in proportion to the distance from the thumb to the mouse click.  CMass tried to hack the POSIX form of the module to come up with something that worked under Windows, but it doesn't quite get it right.  One of the changes I made recently at least fixed the appearance of the scroll bar, especially when scaled pixmaps are in use.  My change forces the trough to occupy the same width/height of the arrow buttons.  I was working on other improvements when I got sidetracked with the resolution problem on the customer's Dell M4300 computer.

At this point, my most pressing issue is indeed how to make the ZMoveVBT/ZChassisVBT work properly for subwindow movement on the M4300 hi-res computer.  At this point, I can give the customer two versions of the software:  (1) everything "works", but the appearance is bad because pixmaps are doubled in size, or (2) everything looks great, but you can't move the subwindows around.  Both of these versions are unacceptable to the customer, so I've got to come up with a fix.  Once I've done that, I can resume my effort with the scroll bar.

Regards,
Randy

>>> Jay <jay.krell at cornell.edu> 08/13/08 7:31 AM >>>

Randy, sorry
1) I didn't realize the functions were in use.
2) I couldn't figure out what each number means. I did try varying them and seeing the affect.
I think maybe I need to learn the X Windows terms? I know in Mac/Windows the part you can drag is the "thumb".

I think I preserved your intent. Feel free to reinstate your intent.
I brought up formsedit and only could easily see a vertical scrollbar.
It doesn't look right to me, but I suspect it is.
If the layers of Trestle could be understand and plowed through, DrawFrameControl would be good.
I've misplaced my Nelson. I'll get another and see if I can understand this..
I'm also curious to see if Tk and Qt draw scrollbars themselves or not.
I'll probably check soon (or by end of month, will be gone next week, out of touch).

 - Jay




----------------------------------------
[big mess made by the ever non-working email systems..]
> Date: Wed, 13 Aug 2008 13:10:59 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT:	/usr/cvs
> Changes by:	jkrell at birch.	08/08/13 13:10:59
> 
> Modified files:
> 	cm3/m3-ui/vbtkit/src/lego/WIN32/: ScrollerVBTClass.m3 
> 
> Log message:
> 	fix it to compile, at least
> 	and eliminate common subexpressions
> 	will see if we can get Windows to draw much more of this
> 	using DrawFrameControl
> 




From rcoleburn at scires.com  Thu Aug 14 05:38:59 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Wed, 13 Aug 2008 23:38:59 -0400
Subject: [M3devel] FW: [M3commit] CVS Update: cm3
Message-ID: <48A37093020000D7000461F1@SRCMAIL.scires.com>

Jay:

After reading your message again, it seems that you may not have received the versions of Image.i3/m3 and ScrollerVBTClass that I sent you.  I had already done the work to remove ImageInit from ScrollerVBTClass and Image.  I just didn't commit it to the repository because everything is still in a state of flux.  The versions I sent also included my new procedure for forcing use of Unscaled pixmaps.

If you like, I can resend these, or commit the versions I have to the repository.  The latter would at least put things right for anyone else using the software right now while we work on a better solution.  Let me know.

BTW, I wasn't able to work on any Modula-3 today because I had to travel for business.  Unfortunately, I'm going to lose a bit more time in the next couple of days because of a tragic death (auto accident) in my extended family.

I'm due at the customer facility on Monday morning, so unfortunately I'm also quickly running out of time for a solution.

Regards,
Randy

Randy C. Coleburn
Senior Systems Engineer, Communications, Networks, & Electronics Division (CNE)
Corporate & Atlanta Information Systems Security Manager (ISSM)
Scientific Research Corporation
2300 Windy Ridge Parkway, Suite 400 South, Atlanta, Georgia 30339
voice: (770) 989-9464, email: RColeburn at SciRes.com, fax: (770) 989-9497

Quality Policy:  "SRC CNE Division is committed to delivering continually improving research & engineering excellence that meets or exceeds customer requirements."
>>> Jay <jay.krell at cornell.edu> 08/13/08 7:31 AM >>>

Randy, sorry
1) I didn't realize the functions were in use.
2) I couldn't figure out what each number means. I did try varying them and seeing the affect.
I think maybe I need to learn the X Windows terms? I know in Mac/Windows the part you can drag is the "thumb".

I think I preserved your intent. Feel free to reinstate your intent.
I brought up formsedit and only could easily see a vertical scrollbar.
It doesn't look right to me, but I suspect it is.
If the layers of Trestle could be understand and plowed through, DrawFrameControl would be good.
I've misplaced my Nelson. I'll get another and see if I can understand this..
I'm also curious to see if Tk and Qt draw scrollbars themselves or not.
I'll probably check soon (or by end of month, will be gone next week, out of touch).

 - Jay




----------------------------------------
[big mess made by the ever non-working email systems..]
> Date: Wed, 13 Aug 2008 13:10:59 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> CVSROOT:	/usr/cvs
> Changes by:	jkrell at birch.	08/08/13 13:10:59
> 
> Modified files:
> 	cm3/m3-ui/vbtkit/src/lego/WIN32/: ScrollerVBTClass.m3 
> 
> Log message:
> 	fix it to compile, at least
> 	and eliminate common subexpressions
> 	will see if we can get Windows to draw much more of this
> 	using DrawFrameControl
> 




From rcoleburn at scires.com  Thu Aug 14 05:57:32 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Wed, 13 Aug 2008 23:57:32 -0400
Subject: [M3devel] CM3IDE
Message-ID: <48A374ED020000D7000461FC@SRCMAIL.scires.com>

Martin:

Thanks for your question.

Please let me know what operating system platform you are using.

The first time you run CM3IDE, it asks about which editor and which browser you want to use.  These questions can be avoided by putting the information in your CM3.CFG file.

If you are using Microsoft IE and Windows, the required format of the response to the console dialog questions is not obvious.  

I will be glad to try and help you resolve this problem.  Please understand that CM3IDE is a new addition to the cm3 codebase and we are still working out some kinks.

Regards,
Randy

>>> Martin Bishop <martinbishop at bellsouth.net> 08/13/08 7:57 PM >>>
Martin Bishop wrote:
> I asked this on the mailing list, but I'll ask here too.
> 
> I compiled CM3, and all went well, but when I try to run "cm3ide" it
> asks me for browser and editor to use, which I tell it, and then it just
> hangs.
> 
> I tried going to http://localhost:3800, but it doesn't appear any
> service is running (browser just gives an error)
> 

Of course I meant on the usenet group, as this IS the mailing list :P




From rcoleburn at scires.com  Thu Aug 14 06:43:07 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Thu, 14 Aug 2008 00:43:07 -0400
Subject: [M3devel] CM3IDE
In-Reply-To: <48A374ED020000D7000461FC@SRCMAIL.scires.com>
References: <48A374ED020000D7000461FC@SRCMAIL.scires.com>
Message-ID: <48A37F94.1E75.00D7.1@scires.com>

Martin:
 
Sorry, I reread my post and realized I forgot to tell you the variables that can go into cm3\bin\cm3.cfg
 
INITIAL_CM3_IDE_BROWSER
INITIAL_CM3_IDE_EDITOR
 
If you are on Windows, you will need to escape the backslash character, e.g.
INITIAL_CM3_IDE_BROWSER="C:\\Program Files\\Internet Explorer\\iexplore.exe"
 
You should set the following environment variable to point to the location where your "private" Modula-3 projects are stored:  CM3_IDE_HOME
 
For example, CM3_IDE_HOME=C:\MyM3Projects
 
If you are using Microsoft Windows and you want to use paths with spaces, you should use the Microsoft short name equivalents, e.g., CM3_IDE_HOME=C:\DOCUME~1\mbishop\MYDOCU~1\CM3Home
 
Regards,
Randy

>>> "Randy Coleburn" <rcoleburn at scires.com> 8/13/2008 11:57 PM >>>
Martin:

Thanks for your question.

Please let me know what operating system platform you are using.

The first time you run CM3IDE, it asks about which editor and which browser you want to use.  These questions can be avoided by putting the information in your CM3.CFG file.

If you are using Microsoft IE and Windows, the required format of the response to the console dialog questions is not obvious.  

I will be glad to try and help you resolve this problem.  Please understand that CM3IDE is a new addition to the cm3 codebase and we are still working out some kinks.

Regards,
Randy

>>> Martin Bishop <martinbishop at bellsouth.net> 08/13/08 7:57 PM >>>
Martin Bishop wrote:
> I asked this on the mailing list, but I'll ask here too.
> 
> I compiled CM3, and all went well, but when I try to run "cm3ide" it
> asks me for browser and editor to use, which I tell it, and then it just
> hangs.
> 
> I tried going to http://localhost:3800, but it doesn't appear any
> service is running (browser just gives an error)
> 

Of course I meant on the usenet group, as this IS the mailing list :P



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080814/ca4f1365/attachment-0002.html>

From mika at async.caltech.edu  Thu Aug 14 10:08:54 2008
From: mika at async.caltech.edu (Mika Nystrom)
Date: Thu, 14 Aug 2008 01:08:54 -0700
Subject: [M3devel] FW: [M3commit] CVS Update: cm3
In-Reply-To: Your message of "Wed, 13 Aug 2008 23:30:23 EDT."
	<48A36E8F020000D7000461EC@SRCMAIL.scires.com> 
Message-ID: <200808140808.m7E88shk081883@camembert.async.caltech.edu>

...
>I've misplaced my Nelson. I'll get another and see if I can understand this..

You may want to just google for "SRC Research Report 68" and "...69"

    Mika

>I'm also curious to see if Tk and Qt draw scrollbars themselves or not.
>I'll probably check soon (or by end of month, will be gone next week, out of t
>ouch).
>
> - Jay


From jay.krell at cornell.edu  Thu Aug 14 14:17:29 2008
From: jay.krell at cornell.edu (Jay)
Date: Thu, 14 Aug 2008 12:17:29 +0000
Subject: [M3devel] FW: [M3commit] CVS Update: cm3
In-Reply-To: <200808140808.m7E88shk081883@camembert.async.caltech.edu>
References: Your message of 
	<200808140808.m7E88shk081883@camembert.async.caltech.edu>
Message-ID: <COL101-W2370AECE37D9828B834395E6720@phx.gbl>


Awesome, thanks.

 - Jay


> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] FW: [M3commit] CVS Update: cm3
> Date: Thu, 14 Aug 2008 01:08:54 -0700
> From: mika at async.caltech.edu
>
> ...
>>I've misplaced my Nelson. I'll get another and see if I can understand this..
>
> You may want to just google for "SRC Research Report 68" and "...69"
>
> Mika
>
>>I'm also curious to see if Tk and Qt draw scrollbars themselves or not.
>>I'll probably check soon (or by end of month, will be gone next week, out of t
>>ouch).
>>
>> - Jay


From jay.krell at cornell.edu  Thu Aug 14 14:46:06 2008
From: jay.krell at cornell.edu (Jay)
Date: Thu, 14 Aug 2008 12:46:06 +0000
Subject: [M3devel] windows move/scroller
Message-ID: <COL101-W123B5E9D268CE608107D40E6720@phx.gbl>


Randy, your scrollervbclass.m3 looks ok or better.

I went to try other gui apps, see if I could see the failure-to-move bug.
It seems that most gui apps now crash.
formsvbtedit is ok.


***
*** runtime error:
***     failed.
***    file "..\src\winvbt\WinContext.m3", line 171
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0x6e1f80c  0x1011cf9  PushPixmap + 0x49b in ..\src\winvbt\WinContext.m3
0x6e1f8d4  0x101fd0c  PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3
0x6e1fd30  0x101dc35  PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3
0x6e1fd98  0x10184ee  PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3
0x6e1fde0  0x1016ded  WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3
0x6e1fe0c  0x7d9472d8  
0x6e1fe84  0x7d947568  
0x6e1fefc  0x7d94778d  
0x6e1ff0c  0x7d94ab86  
0x6e1ff54  0x101bbc9  MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3
.........  .........  ... more frames ...
(a3c.aec): Break instruction exception - code 80000003 (first chance)
eax=00000001 ebx=000000ab ecx=0000ff27 edx=0000001c esi=06e1f5b0 edi=006358eb
eip=7d61002d esp=06e1f598 ebp=06e1f5b0 iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202
ntdll32!DbgBreakPoint:
7d61002d cc              int     3


The "funny" thing is that when this occurs, lots of scrollbar arrows have been drawn
at the wrong place -- filling up Juno's canvas.

This happens with current ScrollerVBClass.m3, or copying the Posix one over Win32,
or your current one.

I changed PushPixMap to print GetLastError, but it is 0. :(

I'll dig a bit.

Not great.
 - Jay


From jay.krell at cornell.edu  Thu Aug 14 15:07:09 2008
From: jay.krell at cornell.edu (Jay)
Date: Thu, 14 Aug 2008 13:07:09 +0000
Subject: [M3devel] another trestle bug..
Message-ID: <COL101-W3271758E974746EF2E7BEBE6720@phx.gbl>


Sigh..in FormsVBTEdit, control-a to select all, control-c to copy, control-c to copy again:



***
*** runtime error:
***    Thread client error: Attempt to lock mutex already locked by self
***    file "..\src\thread\WIN32\ThreadWin32.m3", line 155
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0x6a0f1d0   0x57ba8c  Die + 0x2d in ..\src\thread\WIN32\ThreadWin32.m3
0x6a0f204   0x578d22  LockMutex + 0x13a in ..\src\thread\WIN32\ThreadWin32.m3
0x6a0f24c   0xec9f01  LostClipboard + 0x7f in ..\src\winvbt\WinTrestle.m3
0x6a0f288   0xec702c  WindowProc + 0x8c8 in ..\src\winvbt\WinTrestle.m3
0x6a0f2b4  0x7d9472d8  
0x6a0f32c  0x7d947568  
0x6a0f388  0x7d947d93  
0x6a0f3c8  0x7d969cb2  
0x6a0f43c  0x7d61ea0e  
0x6a0f46c   0xec4506  Acquire + 0x2f in ..\src\winvbt\WinTrestle.m3
.........  .........  ... more frames ...

full stack is:


ChildEBP RetAddr
06a0f144 00575937 ntdll32!DbgBreakPoint
06a0f160 0056c42e m3core!RTOS__Crash+0x4c
06a0f178 0056a19e m3core!RTProcess__Crash+0x68
06a0f190 00569e1d m3core!RTError__EndError+0x37
06a0f1a8 0057ba8c m3core!RTError__Msg+0x8d
06a0f1d0 00578d22 m3core!ThreadWin32__Die+0x2d
06a0f204 00ec9f01 m3core!ThreadWin32__LockMutex+0x13a
06a0f24c 00ec702c m3ui!WinTrestle__LostClipboard+0x7f
06a0f288 7d9472d8 m3ui!WinTrestle__WindowProc+0x8c8
06a0f2b4 7d947568 user32!InternalCallWinProc+0x28
06a0f32c 7d947d93 user32!UserCallWinProcCheckWow+0x114
06a0f388 7d969cb2 user32!DispatchClientMessage+0xdf
06a0f3c8 7d61ea0e user32!__fnINDESTROYCLIPBRD+0x2c
06a0f3fc 00ec46bf ntdll32!KiUserCallbackDispatcher+0x2e
06a0f43c 00ec4506 m3ui!WinTrestle__Acquire__AcquireClipboard+0xf5
06a0f46c 00f327d8 m3ui!WinTrestle__Acquire+0x2f
06a0f4bc 00eedf1a m3ui!ETAgent__Acquire+0x21e
06a0f4f8 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
06a0f534 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
06a0f570 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
06a0f5ac 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
06a0f5e8 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
06a0f624 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
06a0f660 00f327d8 m3ui!VBTClass__AcquireDefault+0x110
06a0f6b0 00e06f96 m3ui!ETAgent__Acquire+0x21e
06a0f6e8 00eedf1a m3vbtkit!ReactivityVBT__Acquire+0x46
06a0f724 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
06a0f760 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
06a0f79c 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
06a0f7d8 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
06a0f814 00eed0e7 m3ui!VBTClass__AcquireDefault+0x110
06a0f848 00ee191b m3ui!VBTClass__Acquire+0xe1
06a0f874 00e3c80d m3ui!VBT__Acquire+0x56
06a0f918 00e3c737 m3vbtkit!TextPortClass__TakeSelection__take+0x7e
06a0f944 00e49ace m3vbtkit!TextPortClass__TakeSelection+0xbe
06a0f97c 00e49109 m3vbtkit!MacModel__Copy+0x87
06a0f9a4 00e3407d m3vbtkit!MacModel__ControlChord+0xd9
06a0fa1c 10026730 m3vbtkit!TextPort__Filter+0x243
06a0fa58 00405eaa m3formsvbt!FVRuntime__PortFilter+0xc3
06a0fb18 00e33e32 formsedit!FormsEditVBT__EPortFilter+0x3ac
06a0fb48 00e48c0e m3vbtkit!TextPort__ApplyStandardKeyFilter+0x89
06a0fb98 00e33da1 m3vbtkit!MacModel__ApplyMacFilter+0xcf
06a0fbf8 00eeae96 m3vbtkit!TextPort__Key+0x1a4
06a0fc30 00f33cd5 m3ui!VBTClass__Key+0xa5
06a0fc74 00e06f48 m3ui!ETAgent__KeyCode+0x19b
06a0fc94 00eeae96 m3vbtkit!ReactivityVBT__Key+0x42
06a0fccc 00f33cd5 m3ui!VBTClass__Key+0xa5
06a0fd10 00eeae96 m3ui!ETAgent__KeyCode+0x19b
06a0fd48 00ec8fbf m3ui!VBTClass__Key+0xa5
06a0fd9c 00ec6ef0 m3ui!WinTrestle__VBTKeyPress+0xfd
06a0fde0 7d9472d8 m3ui!WinTrestle__WindowProc+0x78c
06a0fe0c 7d947568 user32!InternalCallWinProc+0x28
06a0fe84 7d94778d user32!UserCallWinProcCheckWow+0x114
06a0fefc 7d94ab86 user32!DispatchMessageWorker+0x37b
06a0ff0c 00ecbbd9 user32!DispatchMessageA+0xf
06a0ff54 0057a69a m3ui!WinTrestle__MessengerApply+0x21f
06a0ff8c 0057a433 m3core!ThreadWin32__RunThread+0x1f6
06a0ffb8 7d4dfe21 m3core!ThreadWin32__ThreadBase+0x3a
06a0ffec 00000000 kernel32!BaseThreadStart+0x34


From wagner at elegosoft.com  Thu Aug 14 15:16:38 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Thu, 14 Aug 2008 15:16:38 +0200
Subject: [M3devel] another trestle bug..
In-Reply-To: <COL101-W3271758E974746EF2E7BEBE6720@phx.gbl>
References: <COL101-W3271758E974746EF2E7BEBE6720@phx.gbl>
Message-ID: <20080814151638.enfxv3axvok0g8wc@mail.elegosoft.com>

Quoting Jay <jay.krell at cornell.edu>:

>
> Sigh..in FormsVBTEdit, control-a to select all, control-c to copy,   
> control-c to copy again:
>
>
>
> ***
> *** runtime error:
> ***    Thread client error: Attempt to lock mutex already locked by self
> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 155
> ***

This may well be a side-effect of my changes, though I didn't notice
it. You may want to check the old code of the MacModel :-/
If it is, we have to review the mutex use.

Olaf

> Stack trace:
>    FP         PC      Procedure
> ---------  ---------  -------------------------------
> 0x6a0f1d0   0x57ba8c  Die + 0x2d in ..\src\thread\WIN32\ThreadWin32.m3
> 0x6a0f204   0x578d22  LockMutex + 0x13a in ..\src\thread\WIN32\ThreadWin32.m3
> 0x6a0f24c   0xec9f01  LostClipboard + 0x7f in ..\src\winvbt\WinTrestle.m3
> 0x6a0f288   0xec702c  WindowProc + 0x8c8 in ..\src\winvbt\WinTrestle.m3
> 0x6a0f2b4  0x7d9472d8
> 0x6a0f32c  0x7d947568
> 0x6a0f388  0x7d947d93
> 0x6a0f3c8  0x7d969cb2
> 0x6a0f43c  0x7d61ea0e
> 0x6a0f46c   0xec4506  Acquire + 0x2f in ..\src\winvbt\WinTrestle.m3
> .........  .........  ... more frames ...
>
> full stack is:
>
>
> ChildEBP RetAddr
> 06a0f144 00575937 ntdll32!DbgBreakPoint
> 06a0f160 0056c42e m3core!RTOS__Crash+0x4c
> 06a0f178 0056a19e m3core!RTProcess__Crash+0x68
> 06a0f190 00569e1d m3core!RTError__EndError+0x37
> 06a0f1a8 0057ba8c m3core!RTError__Msg+0x8d
> 06a0f1d0 00578d22 m3core!ThreadWin32__Die+0x2d
> 06a0f204 00ec9f01 m3core!ThreadWin32__LockMutex+0x13a
> 06a0f24c 00ec702c m3ui!WinTrestle__LostClipboard+0x7f
> 06a0f288 7d9472d8 m3ui!WinTrestle__WindowProc+0x8c8
> 06a0f2b4 7d947568 user32!InternalCallWinProc+0x28
> 06a0f32c 7d947d93 user32!UserCallWinProcCheckWow+0x114
> 06a0f388 7d969cb2 user32!DispatchClientMessage+0xdf
> 06a0f3c8 7d61ea0e user32!__fnINDESTROYCLIPBRD+0x2c
> 06a0f3fc 00ec46bf ntdll32!KiUserCallbackDispatcher+0x2e
> 06a0f43c 00ec4506 m3ui!WinTrestle__Acquire__AcquireClipboard+0xf5
> 06a0f46c 00f327d8 m3ui!WinTrestle__Acquire+0x2f
> 06a0f4bc 00eedf1a m3ui!ETAgent__Acquire+0x21e
> 06a0f4f8 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
> 06a0f534 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
> 06a0f570 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
> 06a0f5ac 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
> 06a0f5e8 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
> 06a0f624 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
> 06a0f660 00f327d8 m3ui!VBTClass__AcquireDefault+0x110
> 06a0f6b0 00e06f96 m3ui!ETAgent__Acquire+0x21e
> 06a0f6e8 00eedf1a m3vbtkit!ReactivityVBT__Acquire+0x46
> 06a0f724 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
> 06a0f760 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
> 06a0f79c 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
> 06a0f7d8 00eedf1a m3ui!VBTClass__AcquireDefault+0x110
> 06a0f814 00eed0e7 m3ui!VBTClass__AcquireDefault+0x110
> 06a0f848 00ee191b m3ui!VBTClass__Acquire+0xe1
> 06a0f874 00e3c80d m3ui!VBT__Acquire+0x56
> 06a0f918 00e3c737 m3vbtkit!TextPortClass__TakeSelection__take+0x7e
> 06a0f944 00e49ace m3vbtkit!TextPortClass__TakeSelection+0xbe
> 06a0f97c 00e49109 m3vbtkit!MacModel__Copy+0x87
> 06a0f9a4 00e3407d m3vbtkit!MacModel__ControlChord+0xd9
> 06a0fa1c 10026730 m3vbtkit!TextPort__Filter+0x243
> 06a0fa58 00405eaa m3formsvbt!FVRuntime__PortFilter+0xc3
> 06a0fb18 00e33e32 formsedit!FormsEditVBT__EPortFilter+0x3ac
> 06a0fb48 00e48c0e m3vbtkit!TextPort__ApplyStandardKeyFilter+0x89
> 06a0fb98 00e33da1 m3vbtkit!MacModel__ApplyMacFilter+0xcf
> 06a0fbf8 00eeae96 m3vbtkit!TextPort__Key+0x1a4
> 06a0fc30 00f33cd5 m3ui!VBTClass__Key+0xa5
> 06a0fc74 00e06f48 m3ui!ETAgent__KeyCode+0x19b
> 06a0fc94 00eeae96 m3vbtkit!ReactivityVBT__Key+0x42
> 06a0fccc 00f33cd5 m3ui!VBTClass__Key+0xa5
> 06a0fd10 00eeae96 m3ui!ETAgent__KeyCode+0x19b
> 06a0fd48 00ec8fbf m3ui!VBTClass__Key+0xa5
> 06a0fd9c 00ec6ef0 m3ui!WinTrestle__VBTKeyPress+0xfd
> 06a0fde0 7d9472d8 m3ui!WinTrestle__WindowProc+0x78c
> 06a0fe0c 7d947568 user32!InternalCallWinProc+0x28
> 06a0fe84 7d94778d user32!UserCallWinProcCheckWow+0x114
> 06a0fefc 7d94ab86 user32!DispatchMessageWorker+0x37b
> 06a0ff0c 00ecbbd9 user32!DispatchMessageA+0xf
> 06a0ff54 0057a69a m3ui!WinTrestle__MessengerApply+0x21f
> 06a0ff8c 0057a433 m3core!ThreadWin32__RunThread+0x1f6
> 06a0ffb8 7d4dfe21 m3core!ThreadWin32__ThreadBase+0x3a
> 06a0ffec 00000000 kernel32!BaseThreadStart+0x34
>



-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From jay.krell at cornell.edu  Thu Aug 14 15:11:19 2008
From: jay.krell at cornell.edu (Jay)
Date: Thu, 14 Aug 2008 13:11:19 +0000
Subject: [M3devel] another trestle bug..
In-Reply-To: <COL101-W3271758E974746EF2E7BEBE6720@phx.gbl>
References: <COL101-W3271758E974746EF2E7BEBE6720@phx.gbl>
Message-ID: <COL101-W57222A54717D1E92781042E6720@phx.gbl>


Better yet, with file/line:


ChildEBP RetAddr
06a0f144 00575937 ntdll32!DbgBreakPoint
06a0f160 0056c42e m3core!RTOS__Crash+0x4c [..\src\runtime\WIN32\RTOS.m3 @ 29]
06a0f178 0056a19e m3core!RTProcess__Crash+0x68 [..\src\runtime\common\RTProcess.m3 @ 66]
06a0f190 00569e1d m3core!RTError__EndError+0x37 [..\src\runtime\common\RTError.m3 @ 118]
06a0f1a8 0057ba8c m3core!RTError__Msg+0x8d [..\src\runtime\common\RTError.m3 @ 23]
06a0f1d0 00578d22 m3core!ThreadWin32__Die+0x2d [..\src\thread\WIN32\ThreadWin32.m3 @ 982]
06a0f204 00ec9f01 m3core!ThreadWin32__LockMutex+0x13a [..\src\thread\WIN32\ThreadWin32.m3 @ 155]
06a0f24c 00ec702c m3ui!WinTrestle__LostClipboard+0x7f [..\src\winvbt\WinTrestle.m3 @ 2044]
06a0f288 7d9472d8 m3ui!WinTrestle__WindowProc+0x8c8 [..\src\winvbt\WinTrestle.m3 @ 1211]
06a0f2b4 7d947568 user32!InternalCallWinProc+0x28
06a0f32c 7d947d93 user32!UserCallWinProcCheckWow+0x114
06a0f388 7d969cb2 user32!DispatchClientMessage+0xdf
06a0f3c8 7d61ea0e user32!__fnINDESTROYCLIPBRD+0x2c
06a0f3fc 00ec46bf ntdll32!KiUserCallbackDispatcher+0x2e
06a0f43c 00ec4506 m3ui!WinTrestle__Acquire__AcquireClipboard+0xf5 [..\src\winvbt\WinTrestle.m3 @ 431]
06a0f46c 00f327d8 m3ui!WinTrestle__Acquire+0x2f [..\src\winvbt\WinTrestle.m3 @ 445]
06a0f4bc 00eedf1a m3ui!ETAgent__Acquire+0x21e [..\src\split\ETAgent.m3 @ 120]
06a0f4f8 00eedf1a m3ui!VBTClass__AcquireDefault+0x110 [..\src\vbt\VBTClass.m3 @834]
06a0f534 00eedf1a m3ui!VBTClass__AcquireDefault+0x110 [..\src\vbt\VBTClass.m3 @834]
06a0f570 00eedf1a m3ui!VBTClass__AcquireDefault+0x110 [..\src\vbt\VBTClass.m3 @834]
06a0f5ac 00eedf1a m3ui!VBTClass__AcquireDefault+0x110 [..\src\vbt\VBTClass.m3 @834]
06a0f5e8 00eedf1a m3ui!VBTClass__AcquireDefault+0x110 [..\src\vbt\VBTClass.m3 @834]
06a0f624 00eedf1a m3ui!VBTClass__AcquireDefault+0x110 [..\src\vbt\VBTClass.m3 @834]
06a0f660 00f327d8 m3ui!VBTClass__AcquireDefault+0x110 [..\src\vbt\VBTClass.m3 @834]
06a0f6b0 00e06f96 m3ui!ETAgent__Acquire+0x21e [..\src\split\ETAgent.m3 @ 120]
06a0f6e8 00eedf1a m3vbtkit!ReactivityVBT__Acquire+0x46 [..\src\lego\ReactivityVBT.m3 @ 222]
06a0f724 00eedf1a m3ui!VBTClass__AcquireDefault+0x110 [..\src\vbt\VBTClass.m3 @834]
06a0f760 00eedf1a m3ui!VBTClass__AcquireDefault+0x110 [..\src\vbt\VBTClass.m3 @834]
06a0f79c 00eedf1a m3ui!VBTClass__AcquireDefault+0x110 [..\src\vbt\VBTClass.m3 @834]
06a0f7d8 00eedf1a m3ui!VBTClass__AcquireDefault+0x110 [..\src\vbt\VBTClass.m3 @834]
06a0f814 00eed0e7 m3ui!VBTClass__AcquireDefault+0x110 [..\src\vbt\VBTClass.m3 @834]
06a0f848 00ee191b m3ui!VBTClass__Acquire+0xe1 [..\src\vbt\VBTClass.m3 @ 612]
06a0f874 00e3c80d m3ui!VBT__Acquire+0x56 [..\src\vbt\VBT.m3 @ 156]
06a0f918 00e3c737 m3vbtkit!TextPortClass__TakeSelection__take+0x7e [..\src\etext\TextPortClass.m3 @ 833]
06a0f944 00e49ace m3vbtkit!TextPortClass__TakeSelection+0xbe [..\src\etext\TextPortClass.m3 @ 852]
06a0f97c 00e49109 m3vbtkit!MacModel__Copy+0x87 [..\src\etext\MacModel.m3 @ 371]
06a0f9a4 00e3407d m3vbtkit!MacModel__ControlChord+0xd9 [..\src\etext\MacModel.m3 @ 269]
06a0fa1c 10026730 m3vbtkit!TextPort__Filter+0x243 [..\src\etext\TextPort.m3 @ 768]
06a0fa58 00405eaa m3formsvbt!FVRuntime__PortFilter+0xc3 [..\src\FVRuntime.m3 @ 819]
06a0fb18 00e33e32 formsedit!FormsEditVBT__EPortFilter+0x3ac [..\src\FormsEditVBT.m3 @ 711]
06a0fb48 00e48c0e m3vbtkit!TextPort__ApplyStandardKeyFilter+0x89 [..\src\etext\TextPort.m3 @ 740]
06a0fb98 00e33da1 m3vbtkit!MacModel__ApplyMacFilter+0xcf [..\src\etext\MacModel.m3 @ 91]
06a0fbf8 00eeae96 m3vbtkit!TextPort__Key+0x1a4 [..\src\etext\TextPort.m3 @ 732]
06a0fc30 00f33cd5 m3ui!VBTClass__Key+0xa5 [..\src\vbt\VBTClass.m3 @ 250]
06a0fc74 00e06f48 m3ui!ETAgent__KeyCode+0x19b [..\src\split\ETAgent.m3 @ 295]
06a0fc94 00eeae96 m3vbtkit!ReactivityVBT__Key+0x42 [..\src\lego\ReactivityVBT.m3 @ 215]
06a0fccc 00f33cd5 m3ui!VBTClass__Key+0xa5 [..\src\vbt\VBTClass.m3 @ 250]
06a0fd10 00eeae96 m3ui!ETAgent__KeyCode+0x19b [..\src\split\ETAgent.m3 @ 295]
06a0fd48 00ec8fbf m3ui!VBTClass__Key+0xa5 [..\src\vbt\VBTClass.m3 @ 250]
06a0fd9c 00ec6ef0 m3ui!WinTrestle__VBTKeyPress+0xfd [..\src\winvbt\WinTrestle.m3 @ 1734]
06a0fde0 7d9472d8 m3ui!WinTrestle__WindowProc+0x78c [..\src\winvbt\WinTrestle.m3 @ 1178]
06a0fe0c 7d947568 user32!InternalCallWinProc+0x28
06a0fe84 7d94778d user32!UserCallWinProcCheckWow+0x114
06a0fefc 7d94ab86 user32!DispatchMessageWorker+0x37b
06a0ff0c 00ecbbd9 user32!DispatchMessageA+0xf
06a0ff54 0057a69a m3ui!WinTrestle__MessengerApply+0x21f [..\src\winvbt\WinTrestle.m3 @ 2436]
06a0ff8c 0057a433 m3core!ThreadWin32__RunThread+0x1f6 [..\src\thread\WIN32\ThreadWin32.m3 @ 579]
06a0ffb8 7d4dfe21 m3core!ThreadWin32__ThreadBase+0x3a [..\src\thread\WIN32\ThreadWin32.m3 @ 548]
06a0ffec 00000000 kernel32!BaseThreadStart+0x34


 - Jay

> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Date: Thu, 14 Aug 2008 13:07:09 +0000
> Subject: [M3devel] another trestle bug..
>
>
> Sigh..in FormsVBTEdit, control-a to select all, control-c to copy, control-c to copy again:
>
>
>
> ***
> *** runtime error:
> *** Thread client error: Attempt to lock mutex already locked by self
> *** file "..\src\thread\WIN32\ThreadWin32.m3", line 155
> ***
>
> Stack trace:
> FP PC Procedure
> --------- --------- -------------------------------
> 0x6a0f1d0 0x57ba8c Die + 0x2d in ..\src\thread\WIN32\ThreadWin32.m3
> 0x6a0f204 0x578d22 LockMutex + 0x13a in ..\src\thread\WIN32\ThreadWin32.m3
> 0x6a0f24c 0xec9f01 LostClipboard + 0x7f in ..\src\winvbt\WinTrestle.m3
> 0x6a0f288 0xec702c WindowProc + 0x8c8 in ..\src\winvbt\WinTrestle.m3
> 0x6a0f2b4 0x7d9472d8
> 0x6a0f32c 0x7d947568
> 0x6a0f388 0x7d947d93
> 0x6a0f3c8 0x7d969cb2
> 0x6a0f43c 0x7d61ea0e
> 0x6a0f46c 0xec4506 Acquire + 0x2f in ..\src\winvbt\WinTrestle.m3
> ......... ......... ... more frames ...
>
> full stack is:
>
>
> ChildEBP RetAddr
> 06a0f144 00575937 ntdll32!DbgBreakPoint
> 06a0f160 0056c42e m3core!RTOS__Crash+0x4c
...

From wagner at elegosoft.com  Thu Aug 14 15:20:40 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Thu, 14 Aug 2008 15:20:40 +0200
Subject: [M3devel] windows move/scroller
In-Reply-To: <COL101-W123B5E9D268CE608107D40E6720@phx.gbl>
References: <COL101-W123B5E9D268CE608107D40E6720@phx.gbl>
Message-ID: <20080814152040.tu00bh7jqckg0w8w@mail.elegosoft.com>

Quoting Jay <jay.krell at cornell.edu>:

>
> Randy, your scrollervbclass.m3 looks ok or better.
>
> I went to try other gui apps, see if I could see the failure-to-move bug.
> It seems that most gui apps now crash.
> formsvbtedit is ok.
>
>
> ***
> *** runtime error:
> ***     failed.
> ***    file "..\src\winvbt\WinContext.m3", line 171
> ***
>
> Stack trace:
>    FP         PC      Procedure
> ---------  ---------  -------------------------------
> 0x6e1f80c  0x1011cf9  PushPixmap + 0x49b in ..\src\winvbt\WinContext.m3
> 0x6e1f8d4  0x101fd0c  PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3
> 0x6e1fd30  0x101dc35  PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3
> 0x6e1fd98  0x10184ee  PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3
> 0x6e1fde0  0x1016ded  WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3
> 0x6e1fe0c  0x7d9472d8
> 0x6e1fe84  0x7d947568
> 0x6e1fefc  0x7d94778d
> 0x6e1ff0c  0x7d94ab86
> 0x6e1ff54  0x101bbc9  MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3
> .........  .........  ... more frames ...
> (a3c.aec): Break instruction exception - code 80000003 (first chance)
> eax=00000001 ebx=000000ab ecx=0000ff27 edx=0000001c esi=06e1f5b0 edi=006358eb
> eip=7d61002d esp=06e1f598 ebp=06e1f5b0 iopl=0         nv up ei pl nz na po nc
> cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202
> ntdll32!DbgBreakPoint:
> 7d61002d cc              int     3
>
>
> The "funny" thing is that when this occurs, lots of scrollbar arrows  
>  have been drawn
> at the wrong place -- filling up Juno's canvas.

Did Juno ever work on Windows' Trestle? I seem to remember that
the Windows implementation was not sufficient for this rather
sophisticated application, too many things were missing.

Olaf

>
> This happens with current ScrollerVBClass.m3, or copying the Posix   
> one over Win32,
> or your current one.
>
> I changed PushPixMap to print GetLastError, but it is 0. :(
>
> I'll dig a bit.
>
> Not great.
>  - Jay
>



-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From rcoleburn at scires.com  Thu Aug 14 16:38:22 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Thu, 14 Aug 2008 10:38:22 -0400
Subject: [M3devel] windows move/scroller
In-Reply-To: <20080814152040.tu00bh7jqckg0w8w@mail.elegosoft.com>
References: <COL101-W123B5E9D268CE608107D40E6720@phx.gbl>
	<20080814152040.tu00bh7jqckg0w8w@mail.elegosoft.com>
Message-ID: <48A40B18.1E75.00D7.1@scires.com>

Sorry, but I haven't used Juno, so I don't know if it worked on
Windows.
Regards,
Randy

>>> Olaf Wagner <wagner at elegosoft.com> 8/14/2008 9:20 AM >>>
Quoting Jay <jay.krell at cornell.edu>:

>
> Randy, your scrollervbclass.m3 looks ok or better.
>
> I went to try other gui apps, see if I could see the failure-to-move
bug.
> It seems that most gui apps now crash.
> formsvbtedit is ok.
>
>
> ***
> *** runtime error:
> ***     failed.
> ***    file "..\src\winvbt\WinContext.m3", line 171
> ***
>
> Stack trace:
>    FP         PC      Procedure
> ---------  ---------  -------------------------------
> 0x6e1f80c  0x1011cf9  PushPixmap + 0x49b in
..\src\winvbt\WinContext.m3
> 0x6e1f8d4  0x101fd0c  PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3
> 0x6e1fd30  0x101dc35  PaintBatch + 0x225 in
..\src\winvbt\WinPaint.m3
> 0x6e1fd98  0x10184ee  PaintBatchVBT + 0x12d in
..\src\winvbt\WinTrestle.m3
> 0x6e1fde0  0x1016ded  WindowProc + 0x699 in
..\src\winvbt\WinTrestle.m3
> 0x6e1fe0c  0x7d9472d8
> 0x6e1fe84  0x7d947568
> 0x6e1fefc  0x7d94778d
> 0x6e1ff0c  0x7d94ab86
> 0x6e1ff54  0x101bbc9  MessengerApply + 0x21f in
..\src\winvbt\WinTrestle.m3
> .........  .........  ... more frames ...
> (a3c.aec): Break instruction exception - code 80000003 (first
chance)
> eax=00000001 ebx=000000ab ecx=0000ff27 edx=0000001c esi=06e1f5b0
edi=006358eb
> eip=7d61002d esp=06e1f598 ebp=06e1f5b0 iopl=0         nv up ei pl nz
na po nc
> cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b            
efl=00000202
> ntdll32!DbgBreakPoint:
> 7d61002d cc              int     3
>
>
> The "funny" thing is that when this occurs, lots of scrollbar arrows 

>  have been drawn
> at the wrong place -- filling up Juno's canvas.

Did Juno ever work on Windows' Trestle? I seem to remember that
the Windows implementation was not sufficient for this rather
sophisticated application, too many things were missing.

Olaf

>
> This happens with current ScrollerVBClass.m3, or copying the Posix  

> one over Win32,
> or your current one.
>
> I changed PushPixMap to print GetLastError, but it is 0. :(
>
> I'll dig a bit.
>
> Not great.
>  - Jay
>



-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin,
Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45
86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz:
Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:
DE163214194


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080814/6256aebf/attachment-0002.html>

From jay.krell at cornell.edu  Thu Aug 14 16:38:33 2008
From: jay.krell at cornell.edu (Jay)
Date: Thu, 14 Aug 2008 14:38:33 +0000
Subject: [M3devel] windows move/scroller
In-Reply-To: <20080814152040.tu00bh7jqckg0w8w@mail.elegosoft.com>
References: <COL101-W123B5E9D268CE608107D40E6720@phx.gbl>
	<20080814152040.tu00bh7jqckg0w8w@mail.elegosoft.com>
Message-ID: <COL101-W298075CF2F20ED878F16C1E6720@phx.gbl>


I admit I can't remember between NT386GNU and NT386.
At least one of them Juno works on, at least better than I'm seeing on NT386 today.
Juno gets pretty far on NT386. The splash screen comes up, the loading progress,
most of the initial gui comes up, except the "canvas" is full of scrollbar arrows.
 
I'll have to try with 3.6/4.1..
 
A few seconds with mentor and I got:
 
D:\dev2\cm3.2\m3-ui\ui\src\winvbt>\cm3\bin\mentor.exeCreatePatternBrush failed with  0
****** runtime error:***    A runtime error occurred.***    pc = 0x7d61002d***
Stack trace:   FP         PC      Procedure---------  ---------  -------------------------------0x72af77c   0x9266ae  SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.m30x72af80c  0x7d61002d  <???>0x72af8d4  0x147fe8c  PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m30x72afd30  0x147ddb5  PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m30x72afd98  0x147867e  PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m30x72afde0  0x1476f7d  WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m30x72afe0c  0x7d9472d8  <???>0x72afe84  0x7d947568  <???>0x72afefc  0x7d94778d  <???>0x72aff0c  0x7d94ab86  <???>.........  .........  ... more frames ...
 
Maybe a divide by zero since I don't know how to setup mentor usefully..
Looks different than Juno.
 
Calculator works.
 
 - Jay
> Date: Thu, 14 Aug 2008 15:20:40 +0200> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] windows move/scroller> > Quoting Jay <jay.krell at cornell.edu>:> > >> > Randy, your scrollervbclass.m3 looks ok or better.> >> > I went to try other gui apps, see if I could see the failure-to-move bug.> > It seems that most gui apps now crash.> > formsvbtedit is ok.> >> >> > ***> > *** runtime error:> > *** failed.> > *** file "..\src\winvbt\WinContext.m3", line 171> > ***> >> > Stack trace:> > FP PC Procedure> > --------- --------- -------------------------------> > 0x6e1f80c 0x1011cf9 PushPixmap + 0x49b in ..\src\winvbt\WinContext.m3> > 0x6e1f8d4 0x101fd0c PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3> > 0x6e1fd30 0x101dc35 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3> > 0x6e1fd98 0x10184ee PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3> > 0x6e1fde0 0x1016ded WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3> > 0x6e1fe0c 0x7d9472d8> > 0x6e1fe84 0x7d947568> > 0x6e1fefc 0x7d94778d> > 0x6e1ff0c 0x7d94ab86> > 0x6e1ff54 0x101bbc9 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3> > ......... ......... ... more frames ...> > (a3c.aec): Break instruction exception - code 80000003 (first chance)> > eax=00000001 ebx=000000ab ecx=0000ff27 edx=0000001c esi=06e1f5b0 edi=006358eb> > eip=7d61002d esp=06e1f598 ebp=06e1f5b0 iopl=0 nv up ei pl nz na po nc> > cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202> > ntdll32!DbgBreakPoint:> > 7d61002d cc int 3> >> >> > The "funny" thing is that when this occurs, lots of scrollbar arrows > > have been drawn> > at the wrong place -- filling up Juno's canvas.> > Did Juno ever work on Windows' Trestle? I seem to remember that> the Windows implementation was not sufficient for this rather> sophisticated application, too many things were missing.> > Olaf> > >> > This happens with current ScrollerVBClass.m3, or copying the Posix > > one over Win32,> > or your current one.> >> > I changed PushPixMap to print GetLastError, but it is 0. :(> >> > I'll dig a bit.> >> > Not great.> > - Jay> >> > > > -- > Olaf Wagner -- elego Software Solutions GmbH> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080814/28a08669/attachment-0002.html>

From jay.krell at cornell.edu  Thu Aug 14 17:01:51 2008
From: jay.krell at cornell.edu (Jay)
Date: Thu, 14 Aug 2008 15:01:51 +0000
Subject: [M3devel] windows move/scroller
In-Reply-To: <20080814152040.tu00bh7jqckg0w8w@mail.elegosoft.com>
References: <COL101-W123B5E9D268CE608107D40E6720@phx.gbl>
	<20080814152040.tu00bh7jqckg0w8w@mail.elegosoft.com> 
Message-ID: <COL101-W37231C33F530CED8ACFD67E6720@phx.gbl>


Juno was not in 3.6 and 4.1.

 - Jay


________________________________

From: jay.krell at cornell.edu
To: wagner at elegosoft.com; m3devel at elegosoft.com
Subject: RE: [M3devel] windows move/scroller
Date: Thu, 14 Aug 2008 14:38:33 +0000




I admit I can't remember between NT386GNU and NT386.
At least one of them Juno works on, at least better than I'm seeing on NT386 today.
Juno gets pretty far on NT386. The splash screen comes up, the loading progress,
most of the initial gui comes up, except the "canvas" is full of scrollbar arrows.

I'll have to try with 3.6/4.1..

A few seconds with mentor and I got:

D:\dev2\cm3.2\m3-ui\ui\src\winvbt>\cm3\bin\mentor.exe
CreatePatternBrush failed with  0

***
*** runtime error:
***    A runtime error occurred.
***    pc = 0x7d61002d
***
Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0x72af77c   0x9266ae  SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.m3
0x72af80c  0x7d61002d  
0x72af8d4  0x147fe8c  PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3
0x72afd30  0x147ddb5  PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3
0x72afd98  0x147867e  PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3
0x72afde0  0x1476f7d  WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3
0x72afe0c  0x7d9472d8  
0x72afe84  0x7d947568  
0x72afefc  0x7d94778d  
0x72aff0c  0x7d94ab86  
.........  .........  ... more frames ...

Maybe a divide by zero since I don't know how to setup mentor usefully..
Looks different than Juno.

Calculator works.

 - Jay

> Date: Thu, 14 Aug 2008 15:20:40 +0200
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] windows move/scroller
>
> Quoting Jay :
>
>>
>> Randy, your scrollervbclass.m3 looks ok or better.
>>
>> I went to try other gui apps, see if I could see the failure-to-move bug.
>> It seems that most gui apps now crash.
>> formsvbtedit is ok.
>>
>>
>> ***
>> *** runtime error:
>> *** failed.
>> *** file "..\src\winvbt\WinContext.m3", line 171
>> ***
>>
>> Stack trace:
>> FP PC Procedure
>> --------- --------- -------------------------------
>> 0x6e1f80c 0x1011cf9 PushPixmap + 0x49b in ..\src\winvbt\WinContext.m3
>> 0x6e1f8d4 0x101fd0c PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3
>> 0x6e1fd30 0x101dc35 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3
>> 0x6e1fd98 0x10184ee PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3
>> 0x6e1fde0 0x1016ded WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3
>> 0x6e1fe0c 0x7d9472d8
>> 0x6e1fe84 0x7d947568
>> 0x6e1fefc 0x7d94778d
>> 0x6e1ff0c 0x7d94ab86
>> 0x6e1ff54 0x101bbc9 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3
>> ......... ......... ... more frames ...
>> (a3c.aec): Break instruction exception - code 80000003 (first chance)
>> eax=00000001 ebx=000000ab ecx=0000ff27 edx=0000001c esi=06e1f5b0 edi=006358eb
>> eip=7d61002d esp=06e1f598 ebp=06e1f5b0 iopl=0 nv up ei pl nz na po nc
>> cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
>> ntdll32!DbgBreakPoint:
>> 7d61002d cc int 3
>>
>>
>> The "funny" thing is that when this occurs, lots of scrollbar arrows
>> have been drawn
>> at the wrong place -- filling up Juno's canvas.
>
> Did Juno ever work on Windows' Trestle? I seem to remember that
> the Windows implementation was not sufficient for this rather
> sophisticated application, too many things were missing.
>
> Olaf
>
>>
>> This happens with current ScrollerVBClass.m3, or copying the Posix
>> one over Win32,
>> or your current one.
>>
>> I changed PushPixMap to print GetLastError, but it is 0. :(
>>
>> I'll dig a bit.
>>
>> Not great.
>> - Jay
>>
>
>
>
> --
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>



From jay.krell at cornell.edu  Thu Aug 14 17:08:26 2008
From: jay.krell at cornell.edu (Jay)
Date: Thu, 14 Aug 2008 15:08:26 +0000
Subject: [M3devel] windows move/scroller
In-Reply-To: <20080814152040.tu00bh7jqckg0w8w@mail.elegosoft.com>
References: <COL101-W123B5E9D268CE608107D40E6720@phx.gbl>
	<20080814152040.tu00bh7jqckg0w8w@mail.elegosoft.com>  
Message-ID: <COL101-W18E9D5B3112D5CFE53692BE6720@phx.gbl>


Could be that I had:


        brush := WinGDI.CreatePatternBrush (pst.pmtable[pm].hbmp);
        IF brush = NIL THEN
          win32error := WinBase.GetLastError ();
          IO.Put("CreatePatternBrush failed with " (* & Fmt.Address(brush) *) & " " & Fmt.Int(win32error) & "\n");
>>>          WinBase.DebugBreak ();
        END;
        


will remove that and see.
Fisheye sees this too ("RTSignal", we'll see if it was the breakpoint...)

 - Jay

> From: jay.krell at cornell.edu
> To: wagner at elegosoft.com; m3devel at elegosoft.com
> Subject: RE: [M3devel] windows move/scroller
> Date: Thu, 14 Aug 2008 15:01:51 +0000
>
>
> Juno was not in 3.6 and 4.1.
>
> - Jay
>
>
> ________________________________
>
> From: jay.krell at cornell.edu
> To: wagner at elegosoft.com; m3devel at elegosoft.com
> Subject: RE: [M3devel] windows move/scroller
> Date: Thu, 14 Aug 2008 14:38:33 +0000
>
>
>
>
> I admit I can't remember between NT386GNU and NT386.
> At least one of them Juno works on, at least better than I'm seeing on NT386 today.
> Juno gets pretty far on NT386. The splash screen comes up, the loading progress,
> most of the initial gui comes up, except the "canvas" is full of scrollbar arrows.
>
> I'll have to try with 3.6/4.1..
>
> A few seconds with mentor and I got:
>
> D:\dev2\cm3.2\m3-ui\ui\src\winvbt>\cm3\bin\mentor.exe
> CreatePatternBrush failed with 0
>
> ***
> *** runtime error:
> *** A runtime error occurred.
> *** pc = 0x7d61002d
> ***
> Stack trace:
> FP PC Procedure
> --------- --------- -------------------------------
> 0x72af77c 0x9266ae SystemError + 0x66 in ..\src\runtime\NT386\RTSignal.m3
> 0x72af80c 0x7d61002d
> 0x72af8d4 0x147fe8c PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3
> 0x72afd30 0x147ddb5 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3
> 0x72afd98 0x147867e PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3
> 0x72afde0 0x1476f7d WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3
> 0x72afe0c 0x7d9472d8
> 0x72afe84 0x7d947568
> 0x72afefc 0x7d94778d
> 0x72aff0c 0x7d94ab86
> ......... ......... ... more frames ...
>
> Maybe a divide by zero since I don't know how to setup mentor usefully..
> Looks different than Juno.
>
> Calculator works.
>
> - Jay
>
>> Date: Thu, 14 Aug 2008 15:20:40 +0200
>> From: wagner at elegosoft.com
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] windows move/scroller
>>
>> Quoting Jay :
>>
>>>
>>> Randy, your scrollervbclass.m3 looks ok or better.
>>>
>>> I went to try other gui apps, see if I could see the failure-to-move bug.
>>> It seems that most gui apps now crash.
>>> formsvbtedit is ok.
>>>
>>>
>>> ***
>>> *** runtime error:
>>> *** failed.
>>> *** file "..\src\winvbt\WinContext.m3", line 171
>>> ***
>>>
>>> Stack trace:
>>> FP PC Procedure
>>> --------- --------- -------------------------------
>>> 0x6e1f80c 0x1011cf9 PushPixmap + 0x49b in ..\src\winvbt\WinContext.m3
>>> 0x6e1f8d4 0x101fd0c PixmapCom + 0x932 in ..\src\winvbt\WinPaint.m3
>>> 0x6e1fd30 0x101dc35 PaintBatch + 0x225 in ..\src\winvbt\WinPaint.m3
>>> 0x6e1fd98 0x10184ee PaintBatchVBT + 0x12d in ..\src\winvbt\WinTrestle.m3
>>> 0x6e1fde0 0x1016ded WindowProc + 0x699 in ..\src\winvbt\WinTrestle.m3
>>> 0x6e1fe0c 0x7d9472d8
>>> 0x6e1fe84 0x7d947568
>>> 0x6e1fefc 0x7d94778d
>>> 0x6e1ff0c 0x7d94ab86
>>> 0x6e1ff54 0x101bbc9 MessengerApply + 0x21f in ..\src\winvbt\WinTrestle.m3
>>> ......... ......... ... more frames ...
>>> (a3c.aec): Break instruction exception - code 80000003 (first chance)
>>> eax=00000001 ebx=000000ab ecx=0000ff27 edx=0000001c esi=06e1f5b0 edi=006358eb
>>> eip=7d61002d esp=06e1f598 ebp=06e1f5b0 iopl=0 nv up ei pl nz na po nc
>>> cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
>>> ntdll32!DbgBreakPoint:
>>> 7d61002d cc int 3
>>>
>>>
>>> The "funny" thing is that when this occurs, lots of scrollbar arrows
>>> have been drawn
>>> at the wrong place -- filling up Juno's canvas.
>>
>> Did Juno ever work on Windows' Trestle? I seem to remember that
>> the Windows implementation was not sufficient for this rather
>> sophisticated application, too many things were missing.
>>
>> Olaf
>>
>>>
>>> This happens with current ScrollerVBClass.m3, or copying the Posix
>>> one over Win32,
>>> or your current one.
>>>
>>> I changed PushPixMap to print GetLastError, but it is 0. :(
>>>
>>> I'll dig a bit.
>>>
>>> Not great.
>>> - Jay
>>>
>>
>>
>>
>> --
>> Olaf Wagner -- elego Software Solutions GmbH
>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>>
>


From wagner at elegosoft.com  Thu Aug 14 19:45:09 2008
From: wagner at elegosoft.com (Olaf Wagner)
Date: Thu, 14 Aug 2008 19:45:09 +0200
Subject: [M3devel] another trestle bug..
In-Reply-To: <20080814151638.enfxv3axvok0g8wc@mail.elegosoft.com>
References: <COL101-W3271758E974746EF2E7BEBE6720@phx.gbl>
	<20080814151638.enfxv3axvok0g8wc@mail.elegosoft.com>
Message-ID: <20080814194509.6pl53v9csg04occ8@mail.elegosoft.com>

Quoting Olaf Wagner <wagner at elegosoft.com>:

> Quoting Jay <jay.krell at cornell.edu>:
>
>>
>> Sigh..in FormsVBTEdit, control-a to select all, control-c to copy,   
>>  control-c to copy again:
>>
>>
>>
>> ***
>> *** runtime error:
>> ***    Thread client error: Attempt to lock mutex already locked by self
>> ***    file "..\src\thread\WIN32\ThreadWin32.m3", line 155
>> ***
>
> This may well be a side-effect of my changes, though I didn't notice
> it. You may want to check the old code of the MacModel :-/
> If it is, we have to review the mutex use.

It's not related to the TextPort changes, but to WinTrestle.
I just tried on FreeBSD, and it works without a problem there.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194



From rodney.bates at wichita.edu  Fri Aug 15 03:20:07 2008
From: rodney.bates at wichita.edu (Rodney M. Bates)
Date: Thu, 14 Aug 2008 20:20:07 -0500
Subject: [M3devel] Recursive locks
In-Reply-To: <48A49161.1E75.00D7.1@scires.com>
References: <20080814142659.91A4A10D4F35@birch.elegosoft.com>
	<48A4134F.1E75.00D7.1@scires.com>
	<COL101-W30EE57E79AD843F646E8B4E6720@phx.gbl>
	<COL101-W22A7E87C9A16373E9679D9E6720@phx.gbl>
	<48A49161.1E75.00D7.1@scires.com>
Message-ID: <48A4D9C7.8030209@wichita.edu>

Randy Coleburn wrote:
> Jay:
>  
> There is the abstraction of multiple concurrent "readers" but only one 
> "writer".  I actually have such a module that I use sometimes in my 
> programs.  The idea is one of acquiring/releasing read locks and write 
> locks.  The difficulty here is in preventing starvation and usually 
> requires adherence to some rules (again rigor).  By starvation I mean 
> that writers must wait for all readers to finish before they get access, 
> so if there is always at least one reader, the writer will "starve" and 
> never gain access.
>  
> As for recursive locks, again that is usually indicative of a design 
> flaw.  I did once implement a system that permitted the same thread to 
> acquire a lock multiple times, provided that it eventually released the 
> lock the same number of times that it acquired it.  In other words, 
> after the first lock, subsequent locks by the same thread just increment 
> a counter.  Then, unlocks decrement the counter until it is zero with 
> the final unlock actually releasing the mutex.
>  
> In the code you modified, you could implement such a scheme to handle 
> the recursive locks, provided that at some point the thread releases for 
> each lock.  The Thread interface has the ability to note the current 
> thread (i.e., Thread.Self()).  So you could make a stack of locks by 
> same thread.  Other threads would have to block until the first thread's 
> lock stack was empty.
>  
> For example:
>  
> ACQUIRE:  If resource available, lock resource mutex and put current 
> thread on granted stack.  Otherwise, if current thread already on 
> granted stack, push it on stack again and let it proceed.  Otherwise 
> (this is a new thread wanting access), so push this thread onto a 
> waiting stack and wait.
>  
> RELEASE:  Pop granted stack and check to ensure the popped stack entry 
> represents the current thread.  If not, must crash due to a programming 
> error.  If granted stack is now empty, check to see if the waiting stack 
> is empty.  If the waiting stack is empty, release the resource mutex.  
> Otherwise (there is at least one thread waiting), pop waiting stack and 
> push onto granted stack.  Repeat pop/push for each occurrence of current 
> thread at top of waiting stack.  Allow waiting thread to proceed.
>  
> I can check into providing my read-write locks modules if needed.
>  
> Regards,
> Randy
> 


I have forgotten just where, but there are places in Trestle where it is
documented that, when your <whatever>-procedure is called, it is possible
that a certain MUTEX will sometimes already be held by the executing thread,
sometimes not.  If you need to access the data protected by that MUTEX,
you are just out of luck.  No matter what you do, it will be sometimes
wrong, sometimes not.  I don't remember the details, but I gave up trying
to find a way to do what I wanted to do.  I think it was very difficult,
even allowing modifications to Trestle.  This kind of lock scheme would
probably have solved this problem.


>  >>> Jay <jay.krell at cornell.edu> 8/14/2008 6:08 PM >>>
> 
> Maybe we should have another lock type that allows recursive acquires?
> To be used sparingly, but used here?
> I know that is often frowned upon -- the need for it implies a design 
> flaw -- but
> maybe it is ok sometimes?
> I don't understand when/why recursive locks are ok or not.
> 
> - Jay
> 
> 
> ________________________________
> 
> From: jay.krell at cornell.edu
> To: rcoleburn at scires.com; jkrell at elego.de; m3commit at elegosoft.com
> Date: Thu, 14 Aug 2008 22:05:13 +0000
> Subject: Re: [M3commit] CVS Update: cm3
> 
> 
> 
> 
> How about this comment in the code:
> 
> (*-------------------------------------------------- raw seething 
> windows ---*)
> (* NOTE: The helper procedures called by WindowProc lock VBT.mu when calling
>    various Trestle procedures.  They do not hold locks while calling Win32
>    because it knows nothing about Modula-3 locks and it can, on a whim, call
>    WindowProc to do something.  The only reason this scheme might work is
>    because we have a single Modula-3 thread that's pulling on the Win32
>    message queue and calling WindowProc.
> 
>    Similarly, we don't bother locking around updates to Child records.
>    They are updated by the single Modula-3/WindowProc thread.
> *)
> 
> ?
> I also need to check if any state has been modified, or cached in 
> locals, with
> the locks held that are being released.
> 
> -Jay
> 
> 
> 
> ________________________________
> 
> 
> Date: Thu, 14 Aug 2008 11:13:25 -0400
> From: rcoleburn at scires.com
> To: jkrell at elego.de; m3commit at elegosoft.com
> Subject: Re: [M3commit] CVS Update: cm3
> 
> 
> 
> Jay:
> 
> 
> 
> I haven't studied this code in depth, but on the surface I doubt your 
> change is "correct".
> 
> 
> 
> I think the more telling problem is that if you look at the body of 
> WinTrestle.Release, it is empty, save for a comment that it is not yet 
> implemented.  So, it would seem that if WinTrestle.Acquire is called 
> more than once, you will crash because the locks have not been released.
> 
> 
> 
> Further, I don't think it would make sense to release the locks before 
> calling out to Windows, and then reacquire them upon return.  The locks 
> are known to Modula-3 and not Windows.  Releasing them will allow other 
> competing threads to acquire them while you are in the Windows subsystem 
> and would seem to violate whatever protections were in place per holding 
> the locks.  Upon return from Windows, the thread will be back in 
> competition with others to reacquire the locks it gave up and upon 
> success, there is no guarantee that the other threads didn't disturb the 
> state the original thread depended upon.
> 
> 
> 
> I would suggest reverting these changes and looking to implement the 
> Release procedure.
> 
> 
> 
> Regards,
> 
> Randy
> 
> 
>  >>> Jay Krell  8/14/2008 4:26 PM>>>
> CVSROOT:/usr/cvs
> Changes by:jkrell at birch.08/08/14 16:26:59
> 
> Modified files:
> cm3/m3-ui/ui/src/winvbt/: WinTrestle.m3
> 
> Log message:
> release locks when calling out to Win32 to prevent recursive lock 
> acquisition. correct?
> 
> 
> 

-- 
-------------------------------------------------------------
Rodney M. Bates, retired assistant professor
Dept. of Computer Science, Wichita State University
Wichita, KS 67260-0083
316-978-3922
rodney.bates at wichita.edu


From jay.krell at cornell.edu  Fri Aug 15 08:27:17 2008
From: jay.krell at cornell.edu (Jay)
Date: Fri, 15 Aug 2008 06:27:17 +0000
Subject: [M3devel] Recursive locks
In-Reply-To: <48A4D9C7.8030209@wichita.edu>
References: <20080814142659.91A4A10D4F35@birch.elegosoft.com>
	<48A4134F.1E75.00D7.1@scires.com>
	<COL101-W30EE57E79AD843F646E8B4E6720@phx.gbl>
	<COL101-W22A7E87C9A16373E9679D9E6720@phx.gbl>
	<48A49161.1E75.00D7.1@scires.com>  <48A4D9C7.8030209@wichita.edu>
Message-ID: <COL101-W769E513D93D5D95A0F5D6BE66D0@phx.gbl>


Btw, notice that the comment I quoted is NOT true, prior to my change.
It claims we don't hold locks when we call out to Win32, but we do.
 
I vaguely know that releasing and reacquiring locks is or can be dangerous..
But, it depends, right?
It depends on if the locked data has been used yet, and if it is assumed to be
unchanged from the use before the release to uses after the reacquire, right?
 
I believe:
  Handling messages in Win32 possibly causes reentrance  -- called while already "in the middle" of doing something.
  Trestle, at least in parts, is perhaps not "designed" to handle that.
     That is, it does a lot of long term locking.
 
I tried to consider if the work here can be deferred, but it seems like it is exactly meant to occur in this order. I'll have dig more..sometimes...
 
 - Jay> Date: Thu, 14 Aug 2008 20:20:07 -0500> From: rodney.bates at wichita.edu> To: m3devel at elegosoft.com> Subject: [M3devel] Recursive locks> > Randy Coleburn wrote:> > Jay:> > > > There is the abstraction of multiple concurrent "readers" but only one > > "writer". I actually have such a module that I use sometimes in my > > programs. The idea is one of acquiring/releasing read locks and write > > locks. The difficulty here is in preventing starvation and usually > > requires adherence to some rules (again rigor). By starvation I mean > > that writers must wait for all readers to finish before they get access, > > so if there is always at least one reader, the writer will "starve" and > > never gain access.> > > > As for recursive locks, again that is usually indicative of a design > > flaw. I did once implement a system that permitted the same thread to > > acquire a lock multiple times, provided that it eventually released the > > lock the same number of times that it acquired it. In other words, > > after the first lock, subsequent locks by the same thread just increment > > a counter. Then, unlocks decrement the counter until it is zero with > > the final unlock actually releasing the mutex.> > > > In the code you modified, you could implement such a scheme to handle > > the recursive locks, provided that at some point the thread releases for > > each lock. The Thread interface has the ability to note the current > > thread (i.e., Thread.Self()). So you could make a stack of locks by > > same thread. Other threads would have to block until the first thread's > > lock stack was empty.> > > > For example:> > > > ACQUIRE: If resource available, lock resource mutex and put current > > thread on granted stack. Otherwise, if current thread already on > > granted stack, push it on stack again and let it proceed. Otherwise > > (this is a new thread wanting access), so push this thread onto a > > waiting stack and wait.> > > > RELEASE: Pop granted stack and check to ensure the popped stack entry > > represents the current thread. If not, must crash due to a programming > > error. If granted stack is now empty, check to see if the waiting stack > > is empty. If the waiting stack is empty, release the resource mutex. > > Otherwise (there is at least one thread waiting), pop waiting stack and > > push onto granted stack. Repeat pop/push for each occurrence of current > > thread at top of waiting stack. Allow waiting thread to proceed.> > > > I can check into providing my read-write locks modules if needed.> > > > Regards,> > Randy> > > > > I have forgotten just where, but there are places in Trestle where it is> documented that, when your <whatever>-procedure is called, it is possible> that a certain MUTEX will sometimes already be held by the executing thread,> sometimes not. If you need to access the data protected by that MUTEX,> you are just out of luck. No matter what you do, it will be sometimes> wrong, sometimes not. I don't remember the details, but I gave up trying> to find a way to do what I wanted to do. I think it was very difficult,> even allowing modifications to Trestle. This kind of lock scheme would> probably have solved this problem.> > > > >>> Jay <jay.krell at cornell.edu> 8/14/2008 6:08 PM >>>> > > > Maybe we should have another lock type that allows recursive acquires?> > To be used sparingly, but used here?> > I know that is often frowned upon -- the need for it implies a design > > flaw -- but> > maybe it is ok sometimes?> > I don't understand when/why recursive locks are ok or not.> > > > - Jay> > > > > > ________________________________> > > > From: jay.krell at cornell.edu> > To: rcoleburn at scires.com; jkrell at elego.de; m3commit at elegosoft.com> > Date: Thu, 14 Aug 2008 22:05:13 +0000> > Subject: Re: [M3commit] CVS Update: cm3> > > > > > > > > > How about this comment in the code:> > > > (*-------------------------------------------------- raw seething > > windows ---*)> > (* NOTE: The helper procedures called by WindowProc lock VBT.mu when calling> > various Trestle procedures. They do not hold locks while calling Win32> > because it knows nothing about Modula-3 locks and it can, on a whim, call> > WindowProc to do something. The only reason this scheme might work is> > because we have a single Modula-3 thread that's pulling on the Win32> > message queue and calling WindowProc.> > > > Similarly, we don't bother locking around updates to Child records.> > They are updated by the single Modula-3/WindowProc thread.> > *)> > > > ?> > I also need to check if any state has been modified, or cached in > > locals, with> > the locks held that are being released.> > > > -Jay> > > > > > > > ________________________________> > > > > > Date: Thu, 14 Aug 2008 11:13:25 -0400> > From: rcoleburn at scires.com> > To: jkrell at elego.de; m3commit at elegosoft.com> > Subject: Re: [M3commit] CVS Update: cm3> > > > > > > > Jay:> > > > > > > > I haven't studied this code in depth, but on the surface I doubt your > > change is "correct".> > > > > > > > I think the more telling problem is that if you look at the body of > > WinTrestle.Release, it is empty, save for a comment that it is not yet > > implemented. So, it would seem that if WinTrestle.Acquire is called > > more than once, you will crash because the locks have not been released.> > > > > > > > Further, I don't think it would make sense to release the locks before > > calling out to Windows, and then reacquire them upon return. The locks > > are known to Modula-3 and not Windows. Releasing them will allow other > > competing threads to acquire them while you are in the Windows subsystem > > and would seem to violate whatever protections were in place per holding > > the locks. Upon return from Windows, the thread will be back in > > competition with others to reacquire the locks it gave up and upon > > success, there is no guarantee that the other threads didn't disturb the > > state the original thread depended upon.> > > > > > > > I would suggest reverting these changes and looking to implement the > > Release procedure.> > > > > > > > Regards,> > > > Randy> > > > > > >>> Jay Krell 8/14/2008 4:26 PM>>>> > CVSROOT:/usr/cvs> > Changes by:jkrell at birch.08/08/14 16:26:59> > > > Modified files:> > cm3/m3-ui/ui/src/winvbt/: WinTrestle.m3> > > > Log message:> > release locks when calling out to Win32 to prevent recursive lock > > acquisition. correct?> > > > > > > > -- > -------------------------------------------------------------> Rodney M. Bates, retired assistant professor> Dept. of Computer Science, Wichita State University> Wichita, KS 67260-0083> 316-978-3922> rodney.bates at wichita.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080815/2369c19c/attachment-0002.html>

From rcoleburn at scires.com  Tue Aug 19 22:55:00 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Tue, 19 Aug 2008 16:55:00 -0400
Subject: [M3devel] pixmaps et al on Win32 hi-res monitors
Message-ID: <48AAFADE.1E75.00D7.1@scires.com>

Jay, Sorry for the delay in getting back to you.
 
I ran tests as you suggested, namely, in WinScreenType.InnerNew I changed the x & y resolution to be 96.0 (I did not change the pixels,  just the res field).  I tried running this version with Image.Raw.x/yres set to 75.0 and also set to 96.0.  In both cases, what I got on the screen was horrid.  Everything was extremely large and only a fraction of the window was visible on screen (e.g., shadow size on buttons appeared to be increased by a factor of 7 or more).
 
So, here is where I stand:
 
1.  It seems that for certain high-dpi monitors (Dell M4300 laptop is only one I've tested), if you use unscaled pixmaps in FormsVBT/Trestle, the ZGrowVBT stops working for ZChassisVBT.  You can still grab the title and try to drag.  The system will put an outline around the window, but it won't let you drag it anywhere.
 
2.  I have put an environment variable in my programs that lets you choose between scaled and unscaled pixmaps.  For either case, the program seems to work fine on "normal dpi" monitors, but when run on the Dell M4300 hi-res system, you get the following behavior:  
 
Unscaled=subwindows can't be dragged around (moved), but the GUI looks good; 
 
Scaled=subwindow dragging works as expected, but all pixmaps are double-size resulting in bad appearance (pixmaps are out of proportion with text and cause some subwindows to be too big to fit on screen).  
 
So, the end user gets to decide via environment variable whether he wants a pretty GUI with frozen subwindows, or an ugly GUI with movable subwindows.  Alas, the choices are poor, at best.
 
3.  At this point I don't know of anything else to try as a potential solution to this problem.
 
4.  I am running final tests today & tomorrow at the customer location.  We will meet tomorrow (Wednesday) afternoon to decide if customer will accept the program.
 
If anyone has any other ideas for a solution, please let me know ASAP.
 
I plan to commit my changes to the repository as soon as the final decision on acceptance is rendered.  These changes will not alter the way Trestle/FormsVBT has been working on Windows, except to fix the appearance of scaled scroll bars and to add the capability to force use of unscaled pixmaps.  The latter is not done thru env var, but via a new procedure in Image.i3.  (One could use an env var in one's program, like I did, to provide a control input to the new procedure.)  Unless one calls the new procedure, the default is to use scaled pixmaps so as to maintain compatibility with the way its been done in the past, thus there is no change in operation unless explicitly called for by the programmer.
 
Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080819/8d2b858f/attachment-0002.html>

From jay.krell at cornell.edu  Tue Aug 19 23:23:52 2008
From: jay.krell at cornell.edu (Jay)
Date: Tue, 19 Aug 2008 21:23:52 +0000
Subject: [M3devel] pixmaps et al on Win32 hi-res monitors
In-Reply-To: <48AAFADE.1E75.00D7.1@scires.com>
References: <48AAFADE.1E75.00D7.1@scires.com>
Message-ID: <COL101-W685AD60FBE2EC60E5831C6E6690@phx.gbl>


Randy this is all unfortunate. I really wish I had this configuration locally to try out. :(
If you or your customer can send me one....I make no promises. :)
(It is not a cheap machine. It is a "high end" laptop ("high end" means "arbitrarily inflated price"), starts at $1400, and is not well configured at that price. You can get a much better Dell Vostro or Inspiron for half the price.)
 
"I kinda thunk" 96 and 75 or 96 and 96, would lead to "correcly unscaled pixmaps".
I need to read the code more..these must have had other affects.
 
Be sure your customer knows it works fine on most machines/configurations.
Try to get your customer to believe we might yet fix it. 
  However, granted, confidence in the overall system will still suffer.
And if you can get them to send me one..just to borrow...probably not a good move in a "professional environment", use your judgement.
 
Sorry,
 - Jay



Date: Tue, 19 Aug 2008 16:55:00 -0400From: rcoleburn at scires.comTo: m3devel at elegosoft.com; jayk123 at hotmail.comSubject: pixmaps et al on Win32 hi-res monitors

Jay, Sorry for the delay in getting back to you.
 
I ran tests as you suggested, namely, in WinScreenType.InnerNew I changed the x & y resolution to be 96.0 (I did not change the pixels,  just the res field).  I tried running this version with Image.Raw.x/yres set to 75.0 and also set to 96.0.  In both cases, what I got on the screen was horrid.  Everything was extremely large and only a fraction of the window was visible on screen (e.g., shadow size on buttons appeared to be increased by a factor of 7 or more).
 
So, here is where I stand:
 
1.  It seems that for certain high-dpi monitors (Dell M4300 laptop is only one I've tested), if you use unscaled pixmaps in FormsVBT/Trestle, the ZGrowVBT stops working for ZChassisVBT.  You can still grab the title and try to drag.  The system will put an outline around the window, but it won't let you drag it anywhere.
 
2.  I have put an environment variable in my programs that lets you choose between scaled and unscaled pixmaps.  For either case, the program seems to work fine on "normal dpi" monitors, but when run on the Dell M4300 hi-res system, you get the following behavior:  
 
Unscaled=subwindows can't be dragged around (moved), but the GUI looks good; 
 
Scaled=subwindow dragging works as expected, but all pixmaps are double-size resulting in bad appearance (pixmaps are out of proportion with text and cause some subwindows to be too big to fit on screen).  
 
So, the end user gets to decide via environment variable whether he wants a pretty GUI with frozen subwindows, or an ugly GUI with movable subwindows.  Alas, the choices are poor, at best.
 
3.  At this point I don't know of anything else to try as a potential solution to this problem.
 
4.  I am running final tests today & tomorrow at the customer location.  We will meet tomorrow (Wednesday) afternoon to decide if customer will accept the program.
 
If anyone has any other ideas for a solution, please let me know ASAP.
 
I plan to commit my changes to the repository as soon as the final decision on acceptance is rendered.  These changes will not alter the way Trestle/FormsVBT has been working on Windows, except to fix the appearance of scaled scroll bars and to add the capability to force use of unscaled pixmaps.  The latter is not done thru env var, but via a new procedure in Image.i3.  (One could use an env var in one's program, like I did, to provide a control input to the new procedure.)  Unless one calls the new procedure, the default is to use scaled pixmaps so as to maintain compatibility with the way its been done in the past, thus there is no change in operation unless explicitly called for by the programmer.
 
Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080819/9c2d9618/attachment-0002.html>

From rcoleburn at scires.com  Wed Aug 20 01:46:35 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Tue, 19 Aug 2008 19:46:35 -0400
Subject: [M3devel] pixmaps et al on Win32 hi-res monitors
In-Reply-To: <COL101-W685AD60FBE2EC60E5831C6E6690@phx.gbl>
References: <48AAFADE.1E75.00D7.1@scires.com>
	<COL101-W685AD60FBE2EC60E5831C6E6690@phx.gbl>
Message-ID: <48AB2313.1E75.00D7.1@scires.com>

Jay:
 
Thanks.  I probably can't arrange to send you one of these computers, but I might be able to set up a way for you to remotely access it.
 
Regards,
Randy

>>> Jay <jay.krell at cornell.edu> 8/19/2008 5:23 PM >>>
Randy this is all unfortunate. I really wish I had this configuration locally to try out. :(
If you or your customer can send me one....I make no promises. :)
(It is not a cheap machine. It is a "high end" laptop ("high end" means "arbitrarily inflated price"), starts at $1400, and is not well configured at that price. You can get a much better Dell Vostro or Inspiron for half the price.)
 
"I kinda thunk" 96 and 75 or 96 and 96, would lead to "correcly unscaled pixmaps".
I need to read the code more..these must have had other affects.
 
Be sure your customer knows it works fine on most machines/configurations.
Try to get your customer to believe we might yet fix it. 
  However, granted, confidence in the overall system will still suffer.
And if you can get them to send me one..just to borrow...probably not a good move in a "professional environment", use your judgement.
 
Sorry,
 - Jay



Date: Tue, 19 Aug 2008 16:55:00 -0400
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com; jayk123 at hotmail.com 
Subject: pixmaps et al on Win32 hi-res monitors


Jay, Sorry for the delay in getting back to you.
 
I ran tests as you suggested, namely, in WinScreenType.InnerNew I changed the x & y resolution to be 96.0 (I did not change the pixels,  just the res field).  I tried running this version with Image.Raw.x/yres set to 75.0 and also set to 96.0.  In both cases, what I got on the screen was horrid.  Everything was extremely large and only a fraction of the window was visible on screen (e.g., shadow size on buttons appeared to be increased by a factor of 7 or more).
 
So, here is where I stand:
 
1.  It seems that for certain high-dpi monitors (Dell M4300 laptop is only one I've tested), if you use unscaled pixmaps in FormsVBT/Trestle, the ZGrowVBT stops working for ZChassisVBT.  You can still grab the title and try to drag.  The system will put an outline around the window, but it won't let you drag it anywhere.
 
2.  I have put an environment variable in my programs that lets you choose between scaled and unscaled pixmaps.  For either case, the program seems to work fine on "normal dpi" monitors, but when run on the Dell M4300 hi-res system, you get the following behavior:  
 
Unscaled=subwindows can't be dragged around (moved), but the GUI looks good; 
 
Scaled=subwindow dragging works as expected, but all pixmaps are double-size resulting in bad appearance (pixmaps are out of proportion with text and cause some subwindows to be too big to fit on screen).  
 
So, the end user gets to decide via environment variable whether he wants a pretty GUI with frozen subwindows, or an ugly GUI with movable subwindows.  Alas, the choices are poor, at best.
 
3.  At this point I don't know of anything else to try as a potential solution to this problem.
 
4.  I am running final tests today & tomorrow at the customer location.  We will meet tomorrow (Wednesday) afternoon to decide if customer will accept the program.
 
If anyone has any other ideas for a solution, please let me know ASAP.
 
I plan to commit my changes to the repository as soon as the final decision on acceptance is rendered.  These changes will not alter the way Trestle/FormsVBT has been working on Windows, except to fix the appearance of scaled scroll bars and to add the capability to force use of unscaled pixmaps.  The latter is not done thru env var, but via a new procedure in Image.i3.  (One could use an env var in one's program, like I did, to provide a control input to the new procedure.)  Unless one calls the new procedure, the default is to use scaled pixmaps so as to maintain compatibility with the way its been done in the past, thus there is no change in operation unless explicitly called for by the programmer.
 
Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080819/02e9be3e/attachment-0002.html>

From jay.krell at cornell.edu  Thu Aug 21 13:00:43 2008
From: jay.krell at cornell.edu (Jay)
Date: Thu, 21 Aug 2008 11:00:43 +0000
Subject: [M3devel] pixmaps et al on Win32 hi-res monitors
In-Reply-To: <48AB2313.1E75.00D7.1@scires.com>
References: <48AAFADE.1E75.00D7.1@scires.com>
	<COL101-W685AD60FBE2EC60E5831C6E6690@phx.gbl> 
	<48AB2313.1E75.00D7.1@scires.com>
Message-ID: <COL101-W44C26F20E9DF8DF3815DAEE66B0@phx.gbl>


Randy, in case anyone splurges on one of these..

Can you go to Dell.com.
Support.
Type in the asset tag. I think they are on small
barcode stickers on the bottom.

Tell us which screen type this as?
  15.4 IN WIDE WUXGA Anti-Glare LCD Panel
  15.4 inch Wide Screen WSXGA+ TrueLife LCD Panel
  15.4 inch Wide Screen WXGA Anti-Glare LCD Panel
(These are the current options when buying this;
could be there were others in the past. Totally unknown.
Should be easy to map the alphabet soup of *GA to resolutions,
but I don't know.)

Could be also you can simulate this with a simple setting.
I'll try when I get home.
You have a small app that demonstrates the problem?

Hm..

http://en.wikipedia.org/wiki/WSXGA
http://www.pcmag.com/encyclopedia_term/0,2542,t=WSXGA&i=54916,00.asp

 - Jay

________________________________
> Date: Tue, 19 Aug 2008 19:46:35 -0400
> From: rcoleburn at scires.com
> To: jay.krell at cornell.edu; m3devel at elegosoft.com
> Subject: Re: [M3devel] pixmaps et al on Win32 hi-res monitors
> 
> Jay:
> 
> Thanks.  I probably can't arrange to send you one of these computers, but I might be able to set up a way for you to remotely access it.
> 
> Regards,
> Randy
> 
>>>> Jay  8/19/2008 5:23 PM>>>
> Randy this is all unfortunate. I really wish I had this configuration locally to try out. :(
> If you or your customer can send me one....I make no promises. :)
> (It is not a cheap machine. It is a "high end" laptop ("high end" means "arbitrarily inflated price"), starts at $1400, and is not well configured at that price. You can get a much better Dell Vostro or Inspiron for half the price.)
> 
> "I kinda thunk" 96 and 75 or 96 and 96, would lead to "correcly unscaled pixmaps".
> I need to read the code more..these must have had other affects.
> 
> Be sure your customer knows it works fine on most machines/configurations.
> Try to get your customer to believe we might yet fix it.
>   However, granted, confidence in the overall system will still suffer.
> And if you can get them to send me one..just to borrow...probably not a good move in a "professional environment", use your judgement.
> 
> Sorry,
>  - Jay
> 
> 
> ________________________________
> 
> Date: Tue, 19 Aug 2008 16:55:00 -0400
> From: rcoleburn at scires.com
> To: m3devel at elegosoft.com; jayk123 at hotmail.com
> Subject: pixmaps et al on Win32 hi-res monitors
> 
> 
> Jay, Sorry for the delay in getting back to you.
> 
> I ran tests as you suggested, namely, in WinScreenType.InnerNew I changed the x & y resolution to be 96.0 (I did not change the pixels,  just the res field).  I tried running this version with Image.Raw.x/yres set to 75.0 and also set to 96.0.  In both cases, what I got on the screen was horrid.  Everything was extremely large and only a fraction of the window was visible on screen (e.g., shadow size on buttons appeared to be increased by a factor of 7 or more).
> 
> So, here is where I stand:
> 
> 1.  It seems that for certain high-dpi monitors (Dell M4300 laptop is only one I've tested), if you use unscaled pixmaps in FormsVBT/Trestle, the ZGrowVBT stops working for ZChassisVBT.  You can still grab the title and try to drag.  The system will put an outline around the window, but it won't let you drag it anywhere.
> 
> 2.  I have put an environment variable in my programs that lets you choose between scaled and unscaled pixmaps.  For either case, the program seems to work fine on "normal dpi" monitors, but when run on the Dell M4300 hi-res system, you get the following behavior:
> 
> Unscaled=subwindows can't be dragged around (moved), but the GUI looks good;
> 
> Scaled=subwindow dragging works as expected, but all pixmaps are double-size resulting in bad appearance (pixmaps are out of proportion with text and cause some subwindows to be too big to fit on screen).
> 
> So, the end user gets to decide via environment variable whether he wants a pretty GUI with frozen subwindows, or an ugly GUI with movable subwindows.  Alas, the choices are poor, at best.
> 
> 3.  At this point I don't know of anything else to try as a potential solution to this problem.
> 
> 4.  I am running final tests today & tomorrow at the customer location.  We will meet tomorrow (Wednesday) afternoon to decide if customer will accept the program.
> 
> If anyone has any other ideas for a solution, please let me know ASAP.
> 
> I plan to commit my changes to the repository as soon as the final decision on acceptance is rendered.  These changes will not alter the way Trestle/FormsVBT has been working on Windows, except to fix the appearance of scaled scroll bars and to add the capability to force use of unscaled pixmaps.  The latter is not done thru env var, but via a new procedure in Image.i3.  (One could use an env var in one's program, like I did, to provide a control input to the new procedure.)  Unless one calls the new procedure, the default is to use scaled pixmaps so as to maintain compatibility with the way its been done in the past, thus there is no change in operation unless explicitly called for by the programmer.
> 
> Regards,
> Randy


From rcoleburn at scires.com  Thu Aug 21 14:20:01 2008
From: rcoleburn at scires.com (Randy Coleburn)
Date: Thu, 21 Aug 2008 08:20:01 -0400
Subject: [M3devel] pixmaps et al on Win32 hi-res monitors
In-Reply-To: <COL101-W44C26F20E9DF8DF3815DAEE66B0@phx.gbl>
References: <48AAFADE.1E75.00D7.1@scires.com>
	<COL101-W685AD60FBE2EC60E5831C6E6690@phx.gbl>
	<48AB2313.1E75.00D7.1@scires.com>
	<COL101-W44C26F20E9DF8DF3815DAEE66B0@phx.gbl>
Message-ID: <48AD2527.1E75.00D7.1@scires.com>

Jay:
 
I wouldn't "splurge" on this unless someone just wants one of them.
 
Based on the URLs you sent, the Dell M4300 display is a WUXGA, 16:10, 1920x1200.  See http://en.wikipedia.org/wiki/WUXGA 
 
I'm heading to the airport now, so I'll have to get the asset tag for you when I get back to Atlanta.
 
BTW, the customer is impressed with the speed with which I was able to provide the new software.  I owe this credit to Modula-3.  The customer is also impressed with the software, esp. the use of multi-threading and the ability to target multiple platforms simply by recompiling.  Again, credit Modula-3.  Using my env var hack, I was able to show the customer correct appearance of the GUI, at the expense of sub-window movement, so the customer believes I should be able to eventually solve the problem.  Therefore, the customer has agreed to take delivery of the software with the proviso that I continue to work to solve the problem.  So, it looks like I have some more time to work toward a solution.
 
FYI:  My software is used to control and monitor a satellite multi-receiver system.  This system receives and processes tactical data for display and action by the operator and other automated systems.  I can't be more specific because the application is used by the military.  Indeed, the reason for the hard delivery deadline is to meet a deadline for flight testing aboard a new military aircraft.
 
When I get back to Atlanta, I'll try to put together some screen captures of the GUI (minus any tactical info) and provide them in a PDF so you can see some of the windows.  I may be able to put together a small program that demonstrates the problem I'm having.  I won't be able to release the source code, but I should be able to provide a standalone EXE file.
 
Regards,
Randy

>>> Jay <jay.krell at cornell.edu> 8/21/2008 7:00 AM >>>

Randy, in case anyone splurges on one of these..

Can you go to Dell.com.
Support.
Type in the asset tag. I think they are on small
barcode stickers on the bottom.

Tell us which screen type this as?
  15.4 IN WIDE WUXGA Anti-Glare LCD Panel
  15.4 inch Wide Screen WSXGA+ TrueLife LCD Panel
  15.4 inch Wide Screen WXGA Anti-Glare LCD Panel
(These are the current options when buying this;
could be there were others in the past. Totally unknown.
Should be easy to map the alphabet soup of *GA to resolutions,
but I don't know.)

Could be also you can simulate this with a simple setting.
I'll try when I get home.
You have a small app that demonstrates the problem?

Hm..

http://en.wikipedia.org/wiki/WSXGA 
http://www.pcmag.com/encyclopedia_term/0,2542,t=WSXGA&i=54916,00.asp 

- Jay

________________________________
> Date: Tue, 19 Aug 2008 19:46:35 -0400
> From: rcoleburn at scires.com 
> To: jay.krell at cornell.edu; m3devel at elegosoft.com 
> Subject: Re: [M3devel] pixmaps et al on Win32 hi-res monitors
> 
> Jay:
> 
> Thanks.  I probably can't arrange to send you one of these computers, but I might be able to set up a way for you to remotely access it.
> 
> Regards,
> Randy
> 
>>>> Jay  8/19/2008 5:23 PM>>>
> Randy this is all unfortunate. I really wish I had this configuration locally to try out. :(
> If you or your customer can send me one....I make no promises. :)
> (It is not a cheap machine. It is a "high end" laptop ("high end" means "arbitrarily inflated price"), starts at $1400, and is not well configured at that price. You can get a much better Dell Vostro or Inspiron for half the price.)
> 
> "I kinda thunk" 96 and 75 or 96 and 96, would lead to "correcly unscaled pixmaps".
> I need to read the code more..these must have had other affects.
> 
> Be sure your customer knows it works fine on most machines/configurations.
> Try to get your customer to believe we might yet fix it.
>   However, granted, confidence in the overall system will still suffer.
> And if you can get them to send me one..just to borrow...probably not a good move in a "professional environment", use your judgement.
> 
> Sorry,
>  - Jay
> 
> 
> ________________________________
> 
> Date: Tue, 19 Aug 2008 16:55:00 -0400
> From: rcoleburn at scires.com 
> To: m3devel at elegosoft.com; jayk123 at hotmail.com 
> Subject: pixmaps et al on Win32 hi-res monitors
> 
> 
> Jay, Sorry for the delay in getting back to you.
> 
> I ran tests as you suggested, namely, in WinScreenType.InnerNew I changed the x & y resolution to be 96.0 (I did not change the pixels,  just the res field).  I tried running this version with Image.Raw.x/yres set to 75.0 and also set to 96.0.  In both cases, what I got on the screen was horrid.  Everything was extremely large and only a fraction of the window was visible on screen (e.g., shadow size on buttons appeared to be increased by a factor of 7 or more).
> 
> So, here is where I stand:
> 
> 1.  It seems that for certain high-dpi monitors (Dell M4300 laptop is only one I've tested), if you use unscaled pixmaps in FormsVBT/Trestle, the ZGrowVBT stops working for ZChassisVBT.  You can still grab the title and try to drag.  The system will put an outline around the window, but it won't let you drag it anywhere.
> 
> 2.  I have put an environment variable in my programs that lets you choose between scaled and unscaled pixmaps.  For either case, the program seems to work fine on "normal dpi" monitors, but when run on the Dell M4300 hi-res system, you get the following behavior:
> 
> Unscaled=subwindows can't be dragged around (moved), but the GUI looks good;
> 
> Scaled=subwindow dragging works as expected, but all pixmaps are double-size resulting in bad appearance (pixmaps are out of proportion with text and cause some subwindows to be too big to fit on screen).
> 
> So, the end user gets to decide via environment variable whether he wants a pretty GUI with frozen subwindows, or an ugly GUI with movable subwindows.  Alas, the choices are poor, at best.
> 
> 3.  At this point I don't know of anything else to try as a potential solution to this problem.
> 
> 4.  I am running final tests today & tomorrow at the customer location.  We will meet tomorrow (Wednesday) afternoon to decide if customer will accept the program.
> 
> If anyone has any other ideas for a solution, please let me know ASAP.
> 
> I plan to commit my changes to the repository as soon as the final decision on acceptance is rendered.  These changes will not alter the way Trestle/FormsVBT has been working on Windows, except to fix the appearance of scaled scroll bars and to add the capability to force use of unscaled pixmaps.  The latter is not done thru env var, but via a new procedure in Image.i3.  (One could use an env var in one's program, like I did, to provide a control input to the new procedure.)  Unless one calls the new procedure, the default is to use scaled pixmaps so as to maintain compatibility with the way its been done in the past, thus there is no change in operation unless explicitly called for by the programmer.
> 
> Regards,
> Randy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080821/7218998f/attachment-0002.html>