Access is denied. (OS error 16r5)
Locked
12
12
Access is denied. (OS error 16r5)
 
|
Hi folks.
Occasionally, we encounter the following error: Runtime error: Access is denied. (OS error 16r5). The error pop up when a Screensaver is running. Probably because VSE tries to write to the screen and Microsoft have changed the return value when a Screensaver is running ;-) The error log tells us that this has to do with GraphicsTool>>line: (and other places...) I've come up with a proposal for a solution (shown below the error log) but is it a better way to solve it? Error log: Runtime error: Access is denied. (OS error 16r5) Error(Exception)>>defaultAction Error(Exception)>>activateHandler: <anUndefinedObject> Error(Exception)>>handle Error(Exception)>>signal Error class(Exception class)>>signal: <'Access is denied. (O...'> Pen(Object)>>osError: <5> Pen(Object)>>osError [] in GraphicsTool>>line: Array(IndexedCollection)>>do: <aBlockClosure> Pen(GraphicsTool)>>line: <aPoint> Pen(GraphicsTool)>>lineFrom: <aPoint> to: <aPoint> Pen>>draw3DRect: <aRectangle> depth: <1> style: <#in> CX3DTextFrame>>displayWith: <aPen> inRect: <aRectangle> CX3DTextFrame(CPSubPane)>>displayWith: <aPen> inRect: <aRectangle> clipRect: <aRectangle> [] in CPSubPane>>display CX3DTextFrame(Window)>>doGraphics: <aBlockClosure> CX3DTextFrame(CPSubPane)>>display CX3DTextFrame(Window)>>display: <aRectangle> CX3DTextFrame(Window)>>wmPaint: <0> with: <0> NotificationManager>>notify: <aWinMessage> NotificationManager>>notifyRecursive NotificationManager>>recursiveMessage SystemDictionary>>recursiveMessage SystemDictionary>>launch NotificationManager>>readWinQueue NotificationManager>>runEventLoop Message>>perform Message>>evaluate Process>>safelyEvaluate: <aMessage> The cause seems to be '^self osError' and below is a proposal for a solution: line: aPoint "Private - Draw a line from the current location to aPoint. Answer the new location." | anError | self allHandles do: [:h | (GDILibrary lineTo: h x: aPoint x y: aPoint y) ifFalse: [anError := KernelLibrary getLastError. (#(5) includes: anError) "Check for ERROR_ACCESS_DENIED" ifFalse: [^self osError]. self osNotification]]. ^location := aPoint rounded Original: line: aPoint "Private - Draw a line from the current location to aPoint. Answer the new location." self allHandles do: [ :h | ( GDILibrary lineTo: h x: aPoint x y: aPoint y ) ifFalse: [ ^self osError ] ]. ^location := aPoint rounded Is this a good fix? Or shall I reimplement the osError on Pen or GraphicsTool and test there? We have already chanced three places where we call GDILibrary stretchBlt: destDC x: x1 y: y1 dWidth: dWidth dHeight: dHeight srcDC: srcDC xSrc: x2 ySrc: y2 sWidth: sWidth sHeight: sHeight rop: aRopConstant and just call "^self osNotification" instead of "^self osError " when stretchBlt... return false. And we can keep on changing one place after another, but I would like to "just fix it" :-) Regards /Kjell Kjell H. Ulstad Arkitekt. Systemeier Paga/R&D www.bluegarden.no *** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management *** |
Re: Access is denied. (OS error 16r5)
|
|
You could just reimplement osError in GraphicsTool to ignore the access is
denied error. -Carl GraphicsTool>>osError "Report the error unless it is an access denied error (value of 5)." | theLastError | (theLastError := self lastOsError) = 5 ifTrue: [ ^ self ]. ^self osError: theLastError -----Original Message----- From: Using Visual Smalltalk for Windows/Enterprise [mailto:[hidden email]] On Behalf Of Kjell Harald Ulstad Sent: Friday, April 29, 2011 10:06 AM To: [hidden email] Subject: Access is denied. (OS error 16r5) Hi folks. Occasionally, we encounter the following error: Runtime error: Access is denied. (OS error 16r5). The error pop up when a Screensaver is running. Probably because VSE tries to write to the screen and Microsoft have changed the return value when a Screensaver is running ;-) The error log tells us that this has to do with GraphicsTool>>line: (and other places...) I've come up with a proposal for a solution (shown below the error log) but is it a better way to solve it? Error log: Runtime error: Access is denied. (OS error 16r5) Error(Exception)>>defaultAction Error(Exception)>>activateHandler: <anUndefinedObject> Error(Exception)>>handle Error(Exception)>>signal Error class(Exception class)>>signal: <'Access is denied. (O...'> Pen(Object)>>osError: <5> Pen(Object)>>osError [] in GraphicsTool>>line: Array(IndexedCollection)>>do: <aBlockClosure> Pen(GraphicsTool)>>line: <aPoint> Pen(GraphicsTool)>>lineFrom: <aPoint> to: <aPoint> Pen>>draw3DRect: <aRectangle> depth: <1> style: <#in> CX3DTextFrame>>displayWith: <aPen> inRect: <aRectangle> CX3DTextFrame(CPSubPane)>>displayWith: <aPen> inRect: <aRectangle> clipRect: <aRectangle> [] in CPSubPane>>display CX3DTextFrame(Window)>>doGraphics: <aBlockClosure> CX3DTextFrame(CPSubPane)>>display CX3DTextFrame(Window)>>display: <aRectangle> CX3DTextFrame(Window)>>wmPaint: <0> with: <0> NotificationManager>>notify: <aWinMessage> NotificationManager>>notifyRecursive NotificationManager>>recursiveMessage SystemDictionary>>recursiveMessage SystemDictionary>>launch NotificationManager>>readWinQueue NotificationManager>>runEventLoop Message>>perform Message>>evaluate Process>>safelyEvaluate: <aMessage> The cause seems to be '^self osError' and below is a proposal for a solution: line: aPoint "Private - Draw a line from the current location to aPoint. Answer the new location." | anError | self allHandles do: [:h | (GDILibrary lineTo: h x: aPoint x y: aPoint y) ifFalse: [anError := KernelLibrary getLastError. (#(5) includes: anError) "Check for ERROR_ACCESS_DENIED" ifFalse: [^self osError]. self osNotification]]. ^location := aPoint rounded Original: line: aPoint "Private - Draw a line from the current location to aPoint. Answer the new location." self allHandles do: [ :h | ( GDILibrary lineTo: h x: aPoint x y: aPoint y ) ifFalse: [ ^self osError ] ]. ^location := aPoint rounded Is this a good fix? Or shall I reimplement the osError on Pen or GraphicsTool and test there? We have already chanced three places where we call GDILibrary stretchBlt: destDC x: x1 y: y1 dWidth: dWidth dHeight: dHeight srcDC: srcDC xSrc: x2 ySrc: y2 sWidth: sWidth sHeight: sHeight rop: aRopConstant and just call "^self osNotification" instead of "^self osError " when stretchBlt... return false. And we can keep on changing one place after another, but I would like to "just fix it" :-) Regards /Kjell Kjell H. Ulstad Arkitekt. Systemeier Paga/R&D www.bluegarden.no *** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management *** *** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management *** |
Re: Access is denied. (OS error 16r5)
|
|
Does you drawing code use the graphicsTool that is getting a
DC from the beginPaint? My assumption is, you are using a pen that is connected to the Display device context. It is bad style to use the "Display pen" when drawing inside a window and it will result in the problems you are experiencing. The Display device context will report access denied errors while screen savers are active and for other situations. Using pens that are connected to a DC returned by BeginPaint or GetDC(NULL) will not cause any problem for situations, when the Display DC is being locked. Regards Andreas Andreas Rosenberg | eMail: [hidden email] APIS GmbH | Phone: +49 9482 9415-0 Im Haslet 42 | Fax: +49 9482 9415-55 93086 Worth/D | WWW: <http://www.apis.de/> Germany | <http://www.fmea.de/> *** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management *** |
Re: Access is denied. (OS error 16r5)
|
|
In reply to this post by Kjell Harald Ulstad
Wasnt there an official "patch" for this?
-- Claus Kick "Wenn Sie mich suchen: Ich halte mich in der Nähe des Wahnsinns auf. Genauer gesagt auf der schmalen Linie zwischen Wahnsinn und Panik. Gleich um die Ecke von Todesangst, nicht weit weg von Irrwitz und Idiotie." "If you are looking for me: I am somewhere near to lunacy. More clearly, on the narrow path between lunacy and panic. Right around the corner of fear of death, not far away from idiocy and insanity." -----Ursprüngliche Nachricht----- Von: "Kjell Harald Ulstad" <[hidden email]> Gesendet: 29.04.2011 16:06:02 An: [hidden email] Betreff: [VSWE-L] Access is denied. (OS error 16r5) >Hi folks. > >Occasionally, we encounter the following error: Runtime error: Access is >denied. (OS error 16r5). >The error pop up when a Screensaver is running. >Probably because VSE tries to write to the screen and Microsoft have >changed the return value when a Screensaver is running ;-) >The error log tells us that this has to do with GraphicsTool>>line: >(and other places...) >I've come up with a proposal for a solution (shown below the error log) >but is it a better way to solve it? > >Error log: > >Runtime error: Access is denied. (OS error 16r5) > >Error(Exception)>>defaultAction >Error(Exception)>>activateHandler: <anUndefinedObject> >Error(Exception)>>handle >Error(Exception)>>signal >Error class(Exception class)>>signal: <'Access is denied. (O...'> >Pen(Object)>>osError: <5> >Pen(Object)>>osError >[] in GraphicsTool>>line: >Array(IndexedCollection)>>do: <aBlockClosure> >Pen(GraphicsTool)>>line: <aPoint> >Pen(GraphicsTool)>>lineFrom: <aPoint> to: <aPoint> >Pen>>draw3DRect: <aRectangle> depth: <1> style: <#in> >CX3DTextFrame>>displayWith: <aPen> inRect: <aRectangle> >CX3DTextFrame(CPSubPane)>>displayWith: <aPen> inRect: <aRectangle> >clipRect: <aRectangle> >[] in CPSubPane>>display >CX3DTextFrame(Window)>>doGraphics: <aBlockClosure> >CX3DTextFrame(CPSubPane)>>display >CX3DTextFrame(Window)>>display: <aRectangle> >CX3DTextFrame(Window)>>wmPaint: <0> with: <0> >NotificationManager>>notify: <aWinMessage> >NotificationManager>>notifyRecursive >NotificationManager>>recursiveMessage >SystemDictionary>>recursiveMessage >SystemDictionary>>launch >NotificationManager>>readWinQueue >NotificationManager>>runEventLoop >Message>>perform >Message>>evaluate >Process>>safelyEvaluate: <aMessage> > >The cause seems to be '^self osError' and below is a proposal for a >solution: > >line: aPoint > "Private - Draw a line from the current location > to aPoint. Answer the new location." > > | anError | > self allHandles > do: > [:h | > (GDILibrary > >lineTo: h > >x: aPoint x > >y: aPoint y) > ifFalse: > >[anError := KernelLibrary getLastError. > >(#(5) includes: anError) "Check for ERROR_ACCESS_DENIED" > >ifFalse: [^self osError]. > >self osNotification]]. > ^location := aPoint rounded > >Original: >line: aPoint > "Private - Draw a line from the current location > to aPoint. Answer the new location." > self allHandles do: [ :h | > ( GDILibrary lineTo: h x: aPoint x y: aPoint y ) > ifFalse: [ ^self osError ] ]. > ^location := aPoint rounded > >Is this a good fix? >Or shall I reimplement the osError on Pen or GraphicsTool and test >there? > >We have already chanced three places where we call >GDILibrary > stretchBlt: destDC > x: x1 > y: y1 > dWidth: dWidth > dHeight: dHeight > srcDC: srcDC > xSrc: x2 > ySrc: y2 > sWidth: sWidth > sHeight: sHeight > rop: aRopConstant >and just call "^self osNotification" instead of "^self osError " when >stretchBlt... return false. > >And we can keep on changing one place after another, but I would like to >"just fix it" :-) > >Regards > >/Kjell > >Kjell H. Ulstad >Arkitekt. Systemeier Paga/R&D >www.bluegarden.no > >*** this signature added by listserv *** >*** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** >*** for archive browsing and VSWE-L membership management *** *** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management *** |
Re: Access is denied. (OS error 16r5)
|
|
Yes, there was: V352666w.
That patch fixed the following methods: Bitmap (class)>>bitBlt:x:y:width:height:srcDC:xSrc:ySrc:rop: GraphicsTool>>bitBlt:x:y:width:height:srcDC:xSrc:ySrc:rop: GraphicsTool>>stretchBlt:x:y:dWidth:dHeight:srcDC:xSrc:ySrc:sWidth:sHeight:rop: by replacing ^self osError with ^self osNotification. The accompanying text-file tells us that "... In all cases it is sufficient for VSE to ignore this error code." However, as the text-file also states: ALL the graphics code is written to be sensitive to returned error codes from the underlying (Windows) We have later fixed the following: Pen>>rectangleFilled: "Return self if there is an error." TextTool>>displayText:at: "Return self if there is an error. Note that normal termination sets "place" (cursor position) to the right of the displayed text." CursorManager (class)>>cursorPosition "Return 0@0 if there is an error. Note that normal termination returns the actual (hardware) cursor position!" Note that the last "fix" might actually have introduced an error (as I now see it)! Users of that method now gets 0@0 instead of "the real cursor position" (which I guess sort of "doesn't exist" when the screen is locked). Sort of the same argument can be said of the "fix" to TextTool>>displayText:at: - the invariant of updating "place" might be broken (or is it? If the graphics returned an error code, did the (underlying graphics) "place" update?). It might be better to do "self osNotification", but I am not sure about this - actually far from. Does anyone out there have any ideas or "gut feelings" about this? One of the big problems with this (kind of) bug, is that it's next to impossible to provoke. After filing in the V352666w fix, most problems in the development image went away. And we have not been able to provoke these errors in the production image. The production image is served to our customers as a Citrix Published Application. Just starting the (test-) application on a test server and locking the screen (or letting the screen-saver do it) hasn't provoked the error so far. One customer that has problems with this error actually has a "company Citrix Desktop" that they log on to that our "Citrix application" in turn is Published in to. (Arrgh...) Holm-Kjetil Holmsen Senior Software Engineer www.bluegarden.no -----Original Message----- From: Using Visual Smalltalk for Windows/Enterprise [mailto:[hidden email]] On Behalf Of Claus Kick Sent: 2. mai 2011 12:40 To: [hidden email] Subject: Re: Access is denied. (OS error 16r5) Wasnt there an official "patch" for this? -- Claus Kick "Wenn Sie mich suchen: Ich halte mich in der Nähe des Wahnsinns auf. Genauer gesagt auf der schmalen Linie zwischen Wahnsinn und Panik. Gleich um die Ecke von Todesangst, nicht weit weg von Irrwitz und Idiotie." "If you are looking for me: I am somewhere near to lunacy. More clearly, on the narrow path between lunacy and panic. Right around the corner of fear of death, not far away from idiocy and insanity." -----Ursprüngliche Nachricht----- Von: "Kjell Harald Ulstad" <[hidden email]> Gesendet: 29.04.2011 16:06:02 An: [hidden email] Betreff: [VSWE-L] Access is denied. (OS error 16r5) >Hi folks. > >Occasionally, we encounter the following error: Runtime error: Access >is denied. (OS error 16r5). >The error pop up when a Screensaver is running. >Probably because VSE tries to write to the screen and Microsoft have >changed the return value when a Screensaver is running ;-) The error >log tells us that this has to do with GraphicsTool>>line: >(and other places...) >I've come up with a proposal for a solution (shown below the error log) >but is it a better way to solve it? > >Error log: > >Runtime error: Access is denied. (OS error 16r5) > >Error(Exception)>>defaultAction >Error(Exception)>>activateHandler: <anUndefinedObject> >Error(Exception)>>handle Error(Exception)>>signal Error class(Exception >class)>>signal: <'Access is denied. (O...'> >Pen(Object)>>osError: <5> >Pen(Object)>>osError >[] in GraphicsTool>>line: >Array(IndexedCollection)>>do: <aBlockClosure> >Pen(GraphicsTool)>>line: <aPoint> >Pen(GraphicsTool)>>lineFrom: <aPoint> to: <aPoint> >Pen>>draw3DRect: <aRectangle> depth: <1> style: <#in> >CX3DTextFrame>>displayWith: <aPen> inRect: <aRectangle> >CX3DTextFrame(CPSubPane)>>displayWith: <aPen> inRect: <aRectangle> >clipRect: <aRectangle> >[] in CPSubPane>>display >CX3DTextFrame(Window)>>doGraphics: <aBlockClosure> >CX3DTextFrame(CPSubPane)>>display >CX3DTextFrame(Window)>>display: <aRectangle> >CX3DTextFrame(Window)>>wmPaint: <0> with: <0> >NotificationManager>>notify: <aWinMessage> notifyRecursive >NotificationManager>>recursiveMessage >SystemDictionary>>recursiveMessage >SystemDictionary>>launch >NotificationManager>>readWinQueue >NotificationManager>>runEventLoop >Message>>perform >Message>>evaluate >Process>>safelyEvaluate: <aMessage> > >The cause seems to be '^self osError' and below is a proposal for a >solution: > >line: aPoint > "Private - Draw a line from the current location to aPoint. Answer >the new location." > > | anError | > self allHandles > do: > [:h | > (GDILibrary > >lineTo: h > >x: aPoint x > >y: aPoint y) > ifFalse: > >[anError := KernelLibrary getLastError. > >(#(5) includes: anError) "Check for ERROR_ACCESS_DENIED" > >ifFalse: [^self osError]. > >self osNotification]]. > ^location := aPoint rounded > >Original: >line: aPoint > "Private - Draw a line from the current location to aPoint. Answer >the new location." > self allHandles do: [ :h | > ( GDILibrary lineTo: h x: aPoint x y: aPoint y ) > ifFalse: [ ^self osError ] ]. > ^location := aPoint rounded > >Is this a good fix? >Or shall I reimplement the osError on Pen or GraphicsTool and test >there? > >We have already chanced three places where we call GDILibrary > stretchBlt: destDC > x: x1 > y: y1 > dWidth: dWidth > dHeight: dHeight > srcDC: srcDC > xSrc: x2 > ySrc: y2 > sWidth: sWidth > sHeight: sHeight > rop: aRopConstant >and just call "^self osNotification" instead of "^self osError " when >stretchBlt... return false. > >And we can keep on changing one place after another, but I would like >to "just fix it" :-) > >Regards > >/Kjell > >Kjell H. Ulstad >Arkitekt. Systemeier Paga/R&D >www.bluegarden.no > >*** this signature added by listserv *** >*** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** >*** for archive browsing and VSWE-L membership management *** *** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management *** *** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management *** |
AW: Access is denied. (OS error 16r5)
|
|
Couldn't resist - the fix is not serious - it should be done right - not in
just ignoring an error condition - there is a simple way to do it right - register with the powerChanged:with: event of SessionModel current - when you need you deny the Screensaver you need to change SystemWindow>>wmPowerbroadcast: wparam with: lparam not to return nil ( e.g the result of the event). -----Ursprüngliche Nachricht----- Von: Using Visual Smalltalk for Windows/Enterprise [mailto:[hidden email]] Im Auftrag von Holm-Kjetil Holmsen Gesendet: Montag, 2. Mai 2011 15:02 An: [hidden email] Betreff: Re: Access is denied. (OS error 16r5) Yes, there was: V352666w. That patch fixed the following methods: Bitmap (class)>>bitBlt:x:y:width:height:srcDC:xSrc:ySrc:rop: GraphicsTool>>bitBlt:x:y:width:height:srcDC:xSrc:ySrc:rop: GraphicsTool>>stretchBlt:x:y:dWidth:dHeight:srcDC:xSrc:ySrc:sWidth:sHeight:r op: by replacing ^self osError with ^self osNotification. The accompanying text-file tells us that "... In all cases it is sufficient for VSE to ignore this error code." However, as the text-file also states: ALL the graphics code is written to be sensitive to returned error codes from the underlying (Windows) We have later fixed the following: Pen>>rectangleFilled: "Return self if there is an error." TextTool>>displayText:at: "Return self if there is an error. Note that normal termination sets "place" (cursor position) to the right of the displayed text." CursorManager (class)>>cursorPosition "Return 0@0 if there is an error. Note that normal termination returns the actual (hardware) cursor position!" Note that the last "fix" might actually have introduced an error (as I now see it)! Users of that method now gets 0@0 instead of "the real cursor position" (which I guess sort of "doesn't exist" when the screen is locked). Sort of the same argument can be said of the "fix" to TextTool>>displayText:at: - the invariant of updating "place" might be broken (or is it? If the graphics returned an error code, did the (underlying graphics) "place" update?). It might be better to do "self osNotification", but I am not sure about this - actually far from. Does anyone out there have any ideas or "gut feelings" about this? One of the big problems with this (kind of) bug, is that it's next to impossible to provoke. After filing in the V352666w fix, most problems in the development image went away. And we have not been able to provoke these errors in the production image. The production image is served to our customers as a Citrix Published Application. Just starting the (test-) application on a test server and locking the screen (or letting the screen-saver do it) hasn't provoked the error so far. One customer that has problems with this error actually has a "company Citrix Desktop" that they log on to that our "Citrix application" in turn is Published in to. (Arrgh...) Holm-Kjetil Holmsen Senior Software Engineer www.bluegarden.no -----Original Message----- From: Using Visual Smalltalk for Windows/Enterprise [mailto:[hidden email]] On Behalf Of Claus Kick Sent: 2. mai 2011 12:40 To: [hidden email] Subject: Re: Access is denied. (OS error 16r5) Wasnt there an official "patch" for this? -- Claus Kick "Wenn Sie mich suchen: Ich halte mich in der Nähe des Wahnsinns auf. Genauer gesagt auf der schmalen Linie zwischen Wahnsinn und Panik. Gleich um die Ecke von Todesangst, nicht weit weg von Irrwitz und Idiotie." "If you are looking for me: I am somewhere near to lunacy. More clearly, on the narrow path between lunacy and panic. Right around the corner of fear of death, not far away from idiocy and insanity." -----Ursprüngliche Nachricht----- Von: "Kjell Harald Ulstad" <[hidden email]> Gesendet: 29.04.2011 16:06:02 An: [hidden email] Betreff: [VSWE-L] Access is denied. (OS error 16r5) >Hi folks. > >Occasionally, we encounter the following error: Runtime error: Access >is denied. (OS error 16r5). >The error pop up when a Screensaver is running. >Probably because VSE tries to write to the screen and Microsoft have >changed the return value when a Screensaver is running ;-) The error >log tells us that this has to do with GraphicsTool>>line: >(and other places...) >I've come up with a proposal for a solution (shown below the error log) >but is it a better way to solve it? > >Error log: > >Runtime error: Access is denied. (OS error 16r5) > >Error(Exception)>>defaultAction >Error(Exception)>>activateHandler: <anUndefinedObject> >Error(Exception)>>handle Error(Exception)>>signal Error class(Exception >class)>>signal: <'Access is denied. (O...'> >Pen(Object)>>osError: <5> >Pen(Object)>>osError >[] in GraphicsTool>>line: >Array(IndexedCollection)>>do: <aBlockClosure> >Pen(GraphicsTool)>>line: <aPoint> >Pen(GraphicsTool)>>lineFrom: <aPoint> to: <aPoint> >Pen>>draw3DRect: <aRectangle> depth: <1> style: <#in> >CX3DTextFrame>>displayWith: <aPen> inRect: <aRectangle> >CX3DTextFrame(CPSubPane)>>displayWith: <aPen> inRect: <aRectangle> >clipRect: <aRectangle> >[] in CPSubPane>>display >CX3DTextFrame(Window)>>doGraphics: <aBlockClosure> >CX3DTextFrame(CPSubPane)>>display >CX3DTextFrame(Window)>>display: <aRectangle> >CX3DTextFrame(Window)>>wmPaint: <0> with: <0> >NotificationManager>>notify: <aWinMessage> notifyRecursive >NotificationManager>>recursiveMessage >SystemDictionary>>recursiveMessage >SystemDictionary>>launch >NotificationManager>>readWinQueue >NotificationManager>>runEventLoop >Message>>perform >Message>>evaluate >Process>>safelyEvaluate: <aMessage> > >The cause seems to be '^self osError' and below is a proposal for a >solution: > >line: aPoint > "Private - Draw a line from the current location to aPoint. Answer >the new location." > > | anError | > self allHandles > do: > [:h | > (GDILibrary > >lineTo: h > >x: aPoint x > >y: aPoint y) > ifFalse: > >[anError := KernelLibrary getLastError. > >(#(5) includes: anError) "Check for ERROR_ACCESS_DENIED" > >ifFalse: [^self osError]. > >self osNotification]]. > ^location := aPoint rounded > >Original: >line: aPoint > "Private - Draw a line from the current location to aPoint. Answer >the new location." > self allHandles do: [ :h | > ( GDILibrary lineTo: h x: aPoint x y: aPoint y ) > ifFalse: [ ^self osError ] ]. > ^location := aPoint rounded > >Is this a good fix? >Or shall I reimplement the osError on Pen or GraphicsTool and test >there? > >We have already chanced three places where we call GDILibrary > stretchBlt: destDC > x: x1 > y: y1 > dWidth: dWidth > dHeight: dHeight > srcDC: srcDC > xSrc: x2 > ySrc: y2 > sWidth: sWidth > sHeight: sHeight > rop: aRopConstant >and just call "^self osNotification" instead of "^self osError " when >stretchBlt... return false. > >And we can keep on changing one place after another, but I would like >to "just fix it" :-) > >Regards > >/Kjell > >Kjell H. Ulstad >Arkitekt. Systemeier Paga/R&D >www.bluegarden.no > >*** this signature added by listserv *** >*** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** >*** for archive browsing and VSWE-L membership management *** *** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management *** *** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management *** *** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management *** |
Re: Access is denied. (OS error 16r5)
|
|
Yep.
In addition to that I suggest taking care of things that might go messy: bitmap caches, etc. This is an example of what we do: powerChange: eventType
eventType = 'suspend request' ifTrue: [Notifier cleanUpAllMessages]. eventType = 'resume suspend' ifTrue: [
AlphaBitmap resetCache. windows do: [:w | (w isTopPane ifTrue: [w] ifFalse: [w mainWindow]) enableRedraw]]
/Leandro On Mon, May 2, 2011 at 3:40 PM, Frank Lesser <[hidden email]> wrote: Couldn't resist - the fix is not serious - it should be done right - not in |
Re: Access is denied. (OS error 16r5)
|
|
Screensavers are
only one possiblity where the screen will be inaccessible.
I think, in
general you should change your implementation to avoid usage of the
"Display pen" (aka
display DC) at all.
There are various
other situations:
- you can do a
"switch user" in your OS - this will keep your program running, but the screen
device
will not be
accessible, because a different session will be connected to the display
DC.
I think
similar situations can happen, when working with Citrix/Terminal
Server.
- if your app will
be started as a service or via certain registry "run keys" and nobody
does
a login, the
display DC will not be accessible, too.
- if you are using
multiple monitors, the "Display pen" will be the device for the primary monitor.
But the
user can
switch the display for primary monitor, if the graphics card has multiple heads.
I never really examined this situation,
but it could be, that the cached handle to the display DC will become
invalid.
...
Regards
Andreas
*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management *** |
Re: AW: Access is denied. (OS error 16r5)
|
|
In reply to this post by Kjell Harald Ulstad
That is why I called it a "patch" instead of a patch.
-- Claus Kick "Wenn Sie mich suchen: Ich halte mich in der Nähe des Wahnsinns auf. Genauer gesagt auf der schmalen Linie zwischen Wahnsinn und Panik. Gleich um die Ecke von Todesangst, nicht weit weg von Irrwitz und Idiotie." "If you are looking for me: I am somewhere near to lunacy. More clearly, on the narrow path between lunacy and panic. Right around the corner of fear of death, not far away from idiocy and insanity." -----Ursprüngliche Nachricht----- Von: "Frank Lesser" <[hidden email]> Gesendet: 02.05.2011 20:40:55 An: [hidden email] Betreff: [VSWE-L] AW: Access is denied. (OS error 16r5) >Couldn't resist - the fix is not serious - it should be done right - not in >just ignoring an error condition - there is a simple way to do it right - >register with the powerChanged:with: event of SessionModel current - when >you need you deny the Screensaver you need to change >SystemWindow>>wmPowerbroadcast: wparam with: lparam not to return nil ( e.g >the result of the event). > > >-----Ursprüngliche Nachricht----- >Von: Using Visual Smalltalk for Windows/Enterprise >[mailto:[hidden email]] Im Auftrag von Holm-Kjetil Holmsen >Gesendet: Montag, 2. Mai 2011 15:02 >An: [hidden email] >Betreff: Re: Access is denied. (OS error 16r5) > >Yes, there was: V352666w. >That patch fixed the following methods: > > Bitmap (class)>>bitBlt:x:y:width:height:srcDC:xSrc:ySrc:rop: > GraphicsTool>>bitBlt:x:y:width:height:srcDC:xSrc:ySrc:rop: > >GraphicsTool>>stretchBlt:x:y:dWidth:dHeight:srcDC:xSrc:ySrc:sWidth:sHeight:r >op: > >by replacing ^self osError with ^self osNotification. > >The accompanying text-file tells us that "... In all cases it is sufficient >for VSE to ignore this error code." However, as the text-file also states: >ALL the graphics code is written to be sensitive to returned error codes >from the underlying (Windows) > > >We have later fixed the following: > Pen>>rectangleFilled: > "Return self if there is an error." > TextTool>>displayText:at: > "Return self if there is an error. > Note that normal termination sets "place" (cursor position) >to the right of the displayed text." > CursorManager (class)>>cursorPosition > "Return 0@0 if there is an error. > Note that normal termination returns the actual (hardware) >cursor position!" > >Note that the last "fix" might actually have introduced an error (as I now >see it)! Users of that method now gets 0@0 instead of "the real cursor >position" (which I guess sort of "doesn't exist" when the screen is locked). >Sort of the same argument can be said of the "fix" to >TextTool>>displayText:at: - the invariant of updating "place" might be >broken (or is it? If the graphics returned an error code, did the >(underlying graphics) "place" update?). It might be better to do "self >osNotification", but I am not sure about this - actually far from. Does >anyone out there have any ideas or "gut feelings" about this? > >One of the big problems with this (kind of) bug, is that it's next to >impossible to provoke. After filing in the V352666w fix, most problems in >the development image went away. And we have not been able to provoke these >errors in the production image. The production image is served to our >customers as a Citrix Published Application. Just starting the (test-) >application on a test server and locking the screen (or letting the >screen-saver do it) hasn't provoked the error so far. One customer that has >problems with this error actually has a "company Citrix Desktop" that they >log on to that our "Citrix application" in turn is Published in to. >(Arrgh...) > > >Holm-Kjetil Holmsen >Senior Software Engineer >www.bluegarden.no > > >-----Original Message----- >From: Using Visual Smalltalk for Windows/Enterprise >[mailto:[hidden email]] On Behalf Of Claus Kick >Sent: 2. mai 2011 12:40 >To: [hidden email] >Subject: Re: Access is denied. (OS error 16r5) > >Wasnt there an official "patch" for this? > > > >-- >Claus Kick > >"Wenn Sie mich suchen: Ich halte mich in der Nähe des Wahnsinns auf. >Genauer gesagt auf der schmalen Linie zwischen Wahnsinn und Panik. >Gleich um die Ecke von Todesangst, nicht weit weg von Irrwitz und Idiotie." > >"If you are looking for me: I am somewhere near to lunacy. >More clearly, on the narrow path between lunacy and panic. >Right around the corner of fear of death, >not far away from idiocy and insanity." > >-----Ursprüngliche Nachricht----- >Von: "Kjell Harald Ulstad" <[hidden email]> >Gesendet: 29.04.2011 16:06:02 >An: [hidden email] >Betreff: [VSWE-L] Access is denied. (OS error 16r5) > >>Hi folks. >> >>Occasionally, we encounter the following error: Runtime error: Access >>is denied. (OS error 16r5). >>The error pop up when a Screensaver is running. >>Probably because VSE tries to write to the screen and Microsoft have >>changed the return value when a Screensaver is running ;-) The error >>log tells us that this has to do with GraphicsTool>>line: >>(and other places...) >>I've come up with a proposal for a solution (shown below the error log) >>but is it a better way to solve it? >> >>Error log: >> >>Runtime error: Access is denied. (OS error 16r5) >> >>Error(Exception)>>defaultAction >>Error(Exception)>>activateHandler: <anUndefinedObject> >>Error(Exception)>>handle Error(Exception)>>signal Error class(Exception >>class)>>signal: <'Access is denied. (O...'> >>Pen(Object)>>osError: <5> >>Pen(Object)>>osError >>[] in GraphicsTool>>line: >>Array(IndexedCollection)>>do: <aBlockClosure> >>Pen(GraphicsTool)>>line: <aPoint> >>Pen(GraphicsTool)>>lineFrom: <aPoint> to: <aPoint> >>Pen>>draw3DRect: <aRectangle> depth: <1> style: <#in> >>CX3DTextFrame>>displayWith: <aPen> inRect: <aRectangle> >>CX3DTextFrame(CPSubPane)>>displayWith: <aPen> inRect: <aRectangle> >>clipRect: <aRectangle> >>[] in CPSubPane>>display >>CX3DTextFrame(Window)>>doGraphics: <aBlockClosure> >>CX3DTextFrame(CPSubPane)>>display >>CX3DTextFrame(Window)>>display: <aRectangle> >>CX3DTextFrame(Window)>>wmPaint: <0> with: <0> >>NotificationManager>>notify: <aWinMessage> notifyRecursive >>NotificationManager>>recursiveMessage >>SystemDictionary>>recursiveMessage >>SystemDictionary>>launch >>NotificationManager>>readWinQueue >>NotificationManager>>runEventLoop >>Message>>perform >>Message>>evaluate >>Process>>safelyEvaluate: <aMessage> >> >>The cause seems to be '^self osError' and below is a proposal for a >>solution: >> >>line: aPoint >> "Private - Draw a line from the current location to aPoint. Answer >>the new location." >> >> | anError | >> self allHandles >> do: >> [:h | >> (GDILibrary >> >>lineTo: h >> >>x: aPoint x >> >>y: aPoint y) >> ifFalse: >> >>[anError := KernelLibrary getLastError. >> >>(#(5) includes: anError) "Check for ERROR_ACCESS_DENIED" >> >>ifFalse: [^self osError]. >> >>self osNotification]]. >> ^location := aPoint rounded >> >>Original: >>line: aPoint >> "Private - Draw a line from the current location to aPoint. Answer >>the new location." >> self allHandles do: [ :h | >> ( GDILibrary lineTo: h x: aPoint x y: aPoint y ) >> ifFalse: [ ^self osError ] ]. >> ^location := aPoint rounded >> >>Is this a good fix? >>Or shall I reimplement the osError on Pen or GraphicsTool and test >>there? >> >>We have already chanced three places where we call GDILibrary >> stretchBlt: destDC >> x: x1 >> y: y1 >> dWidth: dWidth >> dHeight: dHeight >> srcDC: srcDC >> xSrc: x2 >> ySrc: y2 >> sWidth: sWidth >> sHeight: sHeight >> rop: aRopConstant >>and just call "^self osNotification" instead of "^self osError " when >>stretchBlt... return false. >> >>And we can keep on changing one place after another, but I would like >>to "just fix it" :-) >> >>Regards >> >>/Kjell >> >>Kjell H. Ulstad >>Arkitekt. Systemeier Paga/R&D >>www.bluegarden.no >> >>*** this signature added by listserv *** >>*** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** >>*** for archive browsing and VSWE-L membership management *** > >*** this signature added by listserv *** >*** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** >*** for archive browsing and VSWE-L membership management *** > >*** this signature added by listserv *** >*** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** >*** for archive browsing and VSWE-L membership management *** > >*** this signature added by listserv *** >*** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** >*** for archive browsing and VSWE-L membership management *** *** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management *** |
Re: Access is denied. (OS error 16r5)
|
|
In reply to this post by Leandro Caniglia
Thanks to You both, Frank and Leandro! We’ll try this approach – and it is indeed a much more elegant solution than what we have done before! (And thereby much more satisfying!) The most furious thing about this problem is that it does not show itself in our development images, nor in the test-environment (which is set up as Citrix published applications, just as in production as far as I can tell). It apparently only materializes itself for (some of) our customers (which are not “in house”, but the application is served from “in house”). Needs for some “testing and prodding” to see if we actually can catch the right events, I would think – but that is the challenge… I’ll – we’ll – keep the list posted as of how this goes. Regards Holm-Kjetil Holmsen Senior software engineer From: Using Visual Smalltalk for Windows/Enterprise [mailto:[hidden email]] On Behalf Of Leandro Caniglia Yep. In addition to that I suggest taking care of things that might go messy: bitmap caches, etc. This is an example of what we do: powerChange: eventType eventType = 'suspend request' ifTrue: [Notifier cleanUpAllMessages]. eventType = 'resume suspend' ifTrue: [ AlphaBitmap resetCache. windows do: [:w | (w isTopPane ifTrue: [w] ifFalse: [w mainWindow]) enableRedraw]] /Leandro On Mon, May 2, 2011 at 3:40 PM, Frank Lesser <[hidden email]> wrote: Couldn't resist - the fix is not serious - it should be done right - not in An: [hidden email] Betreff: Re: Access is denied. (OS error 16r5)
>Hi folks. > >Occasionally, we encounter the following error: Runtime error: Access >is denied. (OS error 16r5). >The error pop up when a Screensaver is running. >Probably because VSE tries to write to the screen and Microsoft have >changed the return value when a Screensaver is running ;-) The error >log tells us that this has to do with GraphicsTool>>line: >(and other places...) >I've come up with a proposal for a solution (shown below the error log) >but is it a better way to solve it? > >Error log: > >Runtime error: Access is denied. (OS error 16r5) > >Error(Exception)>>defaultAction >Error(Exception)>>activateHandler: <anUndefinedObject> >Error(Exception)>>handle Error(Exception)>>signal Error class(Exception >class)>>signal: <'Access is denied. (O...'> >Pen(Object)>>osError: <5> >Pen(Object)>>osError >[] in GraphicsTool>>line: >Array(IndexedCollection)>>do: <aBlockClosure> >Pen(GraphicsTool)>>line: <aPoint> >Pen(GraphicsTool)>>lineFrom: <aPoint> to: <aPoint> >Pen>>draw3DRect: <aRectangle> depth: <1> style: <#in> >CX3DTextFrame>>displayWith: <aPen> inRect: <aRectangle> >CX3DTextFrame(CPSubPane)>>displayWith: <aPen> inRect: <aRectangle> >clipRect: <aRectangle> >[] in CPSubPane>>display >CX3DTextFrame(Window)>>doGraphics: <aBlockClosure> >CX3DTextFrame(CPSubPane)>>display >CX3DTextFrame(Window)>>display: <aRectangle> >CX3DTextFrame(Window)>>wmPaint: <0> with: <0> >NotificationManager>>notify: <aWinMessage> notifyRecursive >NotificationManager>>recursiveMessage >SystemDictionary>>recursiveMessage >SystemDictionary>>launch >NotificationManager>>readWinQueue >NotificationManager>>runEventLoop >Message>>perform >Message>>evaluate >Process>>safelyEvaluate: <aMessage> > >The cause seems to be '^self osError' and below is a proposal for a >solution: > >line: aPoint > "Private - Draw a line from the current location to aPoint. Answer >the new location." > > | anError | > self allHandles > do: > [:h | > (GDILibrary > >lineTo: h > >x: aPoint x > >y: aPoint y) > ifFalse: > >[anError := KernelLibrary getLastError. > >(#(5) includes: anError) "Check for ERROR_ACCESS_DENIED" > >ifFalse: [^self osError]. > >self osNotification]]. > ^location := aPoint rounded > >Original: >line: aPoint > "Private - Draw a line from the current location to aPoint. Answer >the new location." > self allHandles do: [ :h | > ( GDILibrary lineTo: h x: aPoint x y: aPoint y ) > ifFalse: [ ^self osError ] ]. > ^location := aPoint rounded > >Is this a good fix? >Or shall I reimplement the osError on Pen or GraphicsTool and test >there? > >We have already chanced three places where we call GDILibrary > stretchBlt: destDC > x: x1 > y: y1 > dWidth: dWidth > dHeight: dHeight > srcDC: srcDC > xSrc: x2 > ySrc: y2 > sWidth: sWidth > sHeight: sHeight > rop: aRopConstant >and just call "^self osNotification" instead of "^self osError " when >stretchBlt... return false. > >And we can keep on changing one place after another, but I would like >to "just fix it" :-) > >Regards > >/Kjell > >Kjell H. Ulstad >Arkitekt. Systemeier Paga/R&D >www.bluegarden.no > >*** this signature added by listserv *** >*** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** >*** for archive browsing and VSWE-L membership management *** *** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management *** *** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management *** *** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management *** *** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management *** |
|
|
In reply to this post by Kjell Harald Ulstad
For some reason VSE failed with a "Float denormalized operand" error
executing the following. Float fromInteger: 100 I can't reproduce it. Why would it do this at all? How would converting 100 to a float produce this error? -Carl *** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management *** |
Re: Float denormalized operand
|
|
Hi Carl,
this topic has been raised some time ago, if I remember correctly. This is a bug in the VM, that will appear if any API call is doing floating point operations. I know this can happen with some printer drivers, so you will get "random" errors after printing stuff. During the API call, floating point instructions result in a denormalized float (very small numbers - google it, if you want to know exactly how it works). This status is signaled by setting a flag in the CPU floating point status word. This flag stays until being cleared. Usually the float status word should be cleared BEFORE doing any float operations and should be checked AFTER any float operations. The VSE VM does not clear this status word, but is checking for it. Todor posted a workaround for this problem: Float class>>fromInteger: anInteger "Answer a floating point representation of the argument anInteger." <primitive: 40> self clearExceptionFlags. ^self fromIntegerRetry: anInteger. Float class>>fromIntegerRetry: anInteger "Answer a floating point representation of the argument anInteger." <primitive: 40> ^0.0 floatError Similar implementations are needed for all kinds of float primitives, if your app uses floats. Regards Andreas Andreas Rosenberg | eMail: [hidden email] APIS GmbH | Phone: +49 9482 9415-0 Im Haslet 42 | Fax: +49 9482 9415-55 93086 Worth/D | WWW: <http://www.apis.de/> Germany | <http://www.fmea.de/> -----Original Message----- From: Using Visual Smalltalk for Windows/Enterprise [mailto:[hidden email]]On Behalf Of Carl Gundel Sent: Montag, 16. Mai 2011 16:02 To: [hidden email] Subject: Float denormalized operand For some reason VSE failed with a "Float denormalized operand" error executing the following. Float fromInteger: 100 I can't reproduce it. Why would it do this at all? How would converting 100 to a float produce this error? -Carl *** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management *** *** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management *** |
Re: Float denormalized operand
|
|
In reply to this post by Carl Gundel-3
This is the code we have in that method. Float class >> fromInteger: anInteger <primitive: 40>
Float denormalizedOperandFlag ifTrue: [ Float clearExceptionFlags. ^self fromInteger: anInteger].
^0.0 floatError On Mon, May 16, 2011 at 11:01 AM, Carl Gundel <[hidden email]> wrote: For some reason VSE failed with a "Float denormalized operand" error *** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management *** |
Re: Float denormalized operand
|
|
Just in case
Float class >> denormalizedOperandFlag ^(self status bitAnd: 2) ~= 0
On Mon, May 16, 2011 at 11:45 AM, Leandro Caniglia <[hidden email]> wrote:
|
Re: Float denormalized operand
|
|
In reply to this post by Carl Gundel-3
If you can't reproduce it anymore, it may be related to unclean float
flags left by previous operations. just a guess On 05/16/2011 11:01 AM, Carl Gundel wrote: > For some reason VSE failed with a "Float denormalized operand" error > executing the following. > > Float fromInteger: 100 > > I can't reproduce it. Why would it do this at all? How would converting > 100 to a float produce this error? *** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management *** |
Re: Float denormalized operand
|
|
That's precisely my guess. And that's why we changed the implementation of fromInteger:
/Leandro
*** this signature added by listserv ***
*** Visit http://www.listserv.dfn.de/archives/vswe-l.html ***
*** for archive browsing and VSWE-L membership management ***
On Mon, May 16, 2011 at 11:51 AM, Gerardo Richarte <[hidden email]> wrote: If you can't reproduce it anymore, it may be related to unclean float |
|
|
In reply to this post by Carl Gundel-3
Clear the float error flags. If I remember, some class method on Float.
This is due to 3rd party code not clearing the processor error flag registers after use. -----Original Message----- From: Using Visual Smalltalk for Windows/Enterprise [mailto:[hidden email]] On Behalf Of Carl Gundel Sent: 16. maj 2011 16:02 To: [hidden email] Subject: Float denormalized operand For some reason VSE failed with a "Float denormalized operand" error executing the following. Float fromInteger: 100 I can't reproduce it. Why would it do this at all? How would converting 100 to a float produce this error? -Carl *** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management *** *** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management *** |
Re: Float denormalized operand
|
|
In reply to this post by Carl Gundel-3
This has been discussed here a couple of years ago. Below is the posting that helped us solve the problem in 2009 (thanks Todor!). In our case, we traced the cause of the problem to a third party PDF tool we were using at the time... the tool seemed to sometime leave the register flag (discussed below) set at the end of an API call. Sometime after that our Smalltalk image would give "Float denormalized operand" or "Float invalid operation".
From: Using Visual Smalltalk for Windows/Enterprise [mailto:[hidden email]] On Behalf Of Todor Todorov Sent: Monday, April 27, 2009 7:32 AM To: [hidden email] Subject: Re: impossible Error (Float invalid operation) There is a bug in VSE. VSE uses some CPU primitive for this, which if it fails generates an exception. This on the CPU level is done by setting a register flag to tell your app (VSE) that the CPU instruction failed / overflowed. However, it's your responsibility to clear the flag before calling the to-float function. If somebody else did float conversion that failed and didn't clear the flag, you will see those strange results. Here's our solution. Try, if failed, clear the flag and retry. Float class>>fromInteger: anInteger "Answer a floating point representation of the argument anInteger." <primitive: 40> self clearExceptionFlags. ^self fromIntegerRetry: anInteger. Float class>>fromIntegerRetry: anInteger "Answer a floating point representation of the argument anInteger." <primitive: 40> ^0.0 floatError -----Original Message----- From: Using Visual Smalltalk for Windows/Enterprise [mailto:[hidden email]] On Behalf Of Carl Gundel Sent: Monday, 16 May, 2011 8:02 AM To: [hidden email] Subject: Float denormalized operand For some reason VSE failed with a "Float denormalized operand" error executing the following. Float fromInteger: 100 I can't reproduce it. Why would it do this at all? How would converting 100 to a float produce this error? -Carl *** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management *** *** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management *** |
|
|
In reply to this post by Leandro Caniglia
Thanks for all the feedback. Very helpful. :-) -Carl From: Using Visual Smalltalk for Windows/Enterprise [mailto:[hidden email]] On Behalf Of Leandro Caniglia That's precisely my guess. And that's why we changed the implementation of fromInteger: /Leandro On Mon, May 16, 2011 at 11:51 AM, Gerardo Richarte <[hidden email]> wrote: If you can't reproduce it anymore, it may be related to unclean float
*** this signature added by listserv *** *** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management *** |
|
|
In reply to this post by Leandro Caniglia
Now and then VSE will crash without error (just go away) when interacting with tab controls. I used to think the problem was related to the use of RichEdit controls in a tabbed UI, but now it has also happened in tabbed UIs that have other controls in them. This isn’t reproducible easily, but sometimes while using the mouse to switch from one tab to another the app will “just go away”. I also wonder if it’s the tooltip code that might be causing the problem. Anyone else experience this? Thanks. -Carl |
«
Return to Visual Smalltalk Enterprise
|
1 view|%1 views
| Free forum by Nabble | Edit this page |