Windows 8 and Common Controls

Hi all,

Has anyone been running VSE successfully on Windows 8, when using Common Controls such as owner-draw tree view and list view, as well as toolbars?

We've had an issue when using the TtsAlwaystip flag on the toolbar (sending recursive nc paint messages) and there appear to be others. Not using TtsAlwaystip style results in the prevention of these recursive messages.

-- Derek

***           this signature added by listserv             ***
*** Visit  http://www.listserv.dfn.de/archives/vswe-l.html ***
*** for archive browsing and VSWE-L membership management  ***

Derek,
not sure if this will solve your problem, but we had a severe stability
issue under W8. We found that the original WindowHandle subclass method  did
not check if a proc was already subclassed. Caching and checking the address
solved the issue:

subclass
        "Private - Subclass the receiver window class
         to use the Smalltalk win proc and the original
         win proc is used as the default."
    | originalProc newProc classStruct |
    classStruct := WinWindowClass new.
    ( UserLibrary
        getClassInfo: OperatingSystem hInstanceExe
        className: OperatingSystem winClassName asParameter
        wndClass: classStruct asParameter )
            ifFalse: [ ^self osError ].
    newProc := classStruct windProc.

    originalProc := UserLibrary
        getWindowLongString: self index: GwlWndproc.
    newProc = ( ExternalAddress fromString: originalProc ) asInteger
        ifTrue: [ ^originalProc ]. "already subclassed"

    (self propertyAt: 'oldProc' nlsNeutral) ifNotNil: [ :oldProc |
        " Are we trying to subclass 3rd party subclassed window? "
        (ExternalAddress fromString: oldProc) isValid ifTrue: [
^originalProc ].
    ].

    UserLibrary setWindowLong: self index: GwlWndproc long: newProc.
    self propertyAt: 'oldProc' nlsNeutral put: originalProc.
    ^originalProc.


Regards
Thomas
(sending
> recursive nc paint messages) and there appear to be others. Not using
> TtsAlwaystip style results in the prevention of these recursive messages.
>
> -- Derek
>
> ***           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  ***

Thanks Thomas. We'll investigate this.

-- Derek

-----Original Message-----
From: Using Visual Smalltalk for Windows/Enterprise [mailto:[hidden email]] On Behalf Of Thomas Muhr
Sent: Friday, 22 February 2013 1:10 AM
To: [hidden email]
Subject: Re: Windows 8 and Common Controls

Derek,
not sure if this will solve your problem, but we had a severe stability issue under W8. We found that the original WindowHandle subclass method  did not check if a proc was already subclassed. Caching and checking the address solved the issue:

subclass
        "Private - Subclass the receiver window class
         to use the Smalltalk win proc and the original
         win proc is used as the default."
    | originalProc newProc classStruct |
    classStruct := WinWindowClass new.
    ( UserLibrary
        getClassInfo: OperatingSystem hInstanceExe
        className: OperatingSystem winClassName asParameter
        wndClass: classStruct asParameter )
            ifFalse: [ ^self osError ].
    newProc := classStruct windProc.

    originalProc := UserLibrary
        getWindowLongString: self index: GwlWndproc.
    newProc = ( ExternalAddress fromString: originalProc ) asInteger
        ifTrue: [ ^originalProc ]. "already subclassed"

    (self propertyAt: 'oldProc' nlsNeutral) ifNotNil: [ :oldProc |
        " Are we trying to subclass 3rd party subclassed window? "
        (ExternalAddress fromString: oldProc) isValid ifTrue: [ ^originalProc ].
    ].

    UserLibrary setWindowLong: self index: GwlWndproc long: newProc.
    self propertyAt: 'oldProc' nlsNeutral put: originalProc.
    ^originalProc.


Regards
Thomas
(sending
> recursive nc paint messages) and there appear to be others. Not using
> TtsAlwaystip style results in the prevention of these recursive messages.
>
> -- Derek
>
> ***           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  ***

Apologies for the late reply to this email thread.  When I went to implement this fix in our own VSE image I was also trying to understand the change.  I got a bit confused.  Is the problem that the WindowHandle>>subclass method can sometimes be called more than once, but only had protection from being called more than once if there were no third parties subclassing the window in addition to Smalltalk?

If I understand the problem, then maybe this version of the method gives equivalent protection but is more optimal. It saves one getClassInfo  API call in the problem situation.  We've had some API call in this method randomly return "The window does not have scroll bars. ( OS error 16r5A7 )" in the past for some reason so the less calls the better in my opinion.

If you think this version has problems, or I don't get the problem in the first place, please let me know.

subclass
"
        Access: Private
        Description: Subclass the receiver window class
                 to use the Smalltalk win proc and the original
                 win proc is used as the default.
"
        | originalProc newProc classStruct |

        originalProc := UserLibrary  
                getWindowLongString: self index: GwlWndproc.
        (self propertyAt: 'oldProc') ifNotNil: [ :oldProc |
                "If oldProc has been cached, then this method is being called for a second time or more.  Don't subclass again."
                (ExternalAddress fromString: oldProc) isValid ifTrue: [ ^originalProc ].
        ].

        classStruct := WinWindowClass new.
        ( UserLibrary
                getClassInfo: OperatingSystem hInstanceExe
                className: OperatingSystem winClassName asParameter
                wndClass: classStruct asParameter )
                        ifFalse: [ ^self osError ].
        newProc := classStruct windProc.
        newProc = ( ExternalAddress fromString: originalProc ) asInteger
                ifTrue: [ ^originalProc ]. "Smalltalk winproc is already the winproc.  Don't subclass again."

        UserLibrary setWindowLong: self index: GwlWndproc long: newProc.
        self propertyAt: 'oldProc' put: originalProc.
        ^originalProc.


Regards,
Lorin

-----Original Message-----
From: Using Visual Smalltalk for Windows/Enterprise [mailto:[hidden email]] On Behalf Of Thomas Muhr
Sent: Thursday, February 21, 2013 7:10 AM
To: [hidden email]
Subject: Re: Windows 8 and Common Controls

Derek,
not sure if this will solve your problem, but we had a severe stability
issue under W8. We found that the original WindowHandle subclass method  did
not check if a proc was already subclassed. Caching and checking the address
solved the issue:

subclass
        "Private - Subclass the receiver window class
         to use the Smalltalk win proc and the original
         win proc is used as the default."
    | originalProc newProc classStruct |
    classStruct := WinWindowClass new.
    ( UserLibrary
        getClassInfo: OperatingSystem hInstanceExe
        className: OperatingSystem winClassName asParameter
        wndClass: classStruct asParameter )
            ifFalse: [ ^self osError ].
    newProc := classStruct windProc.

    originalProc := UserLibrary
        getWindowLongString: self index: GwlWndproc.
    newProc = ( ExternalAddress fromString: originalProc ) asInteger
        ifTrue: [ ^originalProc ]. "already subclassed"

    (self propertyAt: 'oldProc' nlsNeutral) ifNotNil: [ :oldProc |
        " Are we trying to subclass 3rd party subclassed window? "
        (ExternalAddress fromString: oldProc) isValid ifTrue: [
^originalProc ].
    ].

    UserLibrary setWindowLong: self index: GwlWndproc long: newProc.
    self propertyAt: 'oldProc' nlsNeutral put: originalProc.
    ^originalProc.


Regards
Thomas
(sending
> recursive nc paint messages) and there appear to be others. Not using
> TtsAlwaystip style results in the prevention of these recursive messages.
>
> -- Derek
>
> ***           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  ***

Hello Lorin,

The issue is that the control ends up being subclassed twice by VSE. First VSE, then something else then again by VSE. The two VSE procedures share the same "global variable" for the previous window procedure, and that's not going to work. And yes, the problem is that WindowHandle>>subclass gets called several times incl. deferred calls.

The GetClassInfo problem is probably something else. I've seen this several times and tried to reproduce it many years ago, but no luck. Recently I read an article on corruption of the Windows Atom Table (which is session-global). This is most probably the case, but I am not 100% sure.

-- Todor



-----Original Message-----
From: Using Visual Smalltalk for Windows/Enterprise [mailto:[hidden email]] On Behalf Of Lorin McCaffrey
Sent: 22. marts 2013 00:15
To: [hidden email]
Subject: Re: Windows 8 and Common Controls

Apologies for the late reply to this email thread.  When I went to implement this fix in our own VSE image I was also trying to understand the change.  I got a bit confused.  Is the problem that the WindowHandle>>subclass method can sometimes be called more than once, but only had protection from being called more than once if there were no third parties subclassing the window in addition to Smalltalk?

If I understand the problem, then maybe this version of the method gives equivalent protection but is more optimal. It saves one getClassInfo  API call in the problem situation.  We've had some API call in this method randomly return "The window does not have scroll bars. ( OS error 16r5A7 )" in the past for some reason so the less calls the better in my opinion.

If you think this version has problems, or I don't get the problem in the first place, please let me know.

subclass
"
        Access: Private
        Description: Subclass the receiver window class
                 to use the Smalltalk win proc and the original
                 win proc is used as the default.
"
        | originalProc newProc classStruct |

        originalProc := UserLibrary  
                getWindowLongString: self index: GwlWndproc.
        (self propertyAt: 'oldProc') ifNotNil: [ :oldProc |
                "If oldProc has been cached, then this method is being called for a second time or more.  Don't subclass again."
                (ExternalAddress fromString: oldProc) isValid ifTrue: [ ^originalProc ].
        ].

        classStruct := WinWindowClass new.
        ( UserLibrary
                getClassInfo: OperatingSystem hInstanceExe
                className: OperatingSystem winClassName asParameter
                wndClass: classStruct asParameter )
                        ifFalse: [ ^self osError ].
        newProc := classStruct windProc.
        newProc = ( ExternalAddress fromString: originalProc ) asInteger
                ifTrue: [ ^originalProc ]. "Smalltalk winproc is already the winproc.  Don't subclass again."

        UserLibrary setWindowLong: self index: GwlWndproc long: newProc.
        self propertyAt: 'oldProc' put: originalProc.
        ^originalProc.


Regards,
Lorin

-----Original Message-----
From: Using Visual Smalltalk for Windows/Enterprise [mailto:[hidden email]] On Behalf Of Thomas Muhr
Sent: Thursday, February 21, 2013 7:10 AM
To: [hidden email]
Subject: Re: Windows 8 and Common Controls

Derek,
not sure if this will solve your problem, but we had a severe stability issue under W8. We found that the original WindowHandle subclass method  did not check if a proc was already subclassed. Caching and checking the address solved the issue:

subclass
        "Private - Subclass the receiver window class
         to use the Smalltalk win proc and the original
         win proc is used as the default."
    | originalProc newProc classStruct |
    classStruct := WinWindowClass new.
    ( UserLibrary
        getClassInfo: OperatingSystem hInstanceExe
        className: OperatingSystem winClassName asParameter
        wndClass: classStruct asParameter )
            ifFalse: [ ^self osError ].
    newProc := classStruct windProc.

    originalProc := UserLibrary
        getWindowLongString: self index: GwlWndproc.
    newProc = ( ExternalAddress fromString: originalProc ) asInteger
        ifTrue: [ ^originalProc ]. "already subclassed"

    (self propertyAt: 'oldProc' nlsNeutral) ifNotNil: [ :oldProc |
        " Are we trying to subclass 3rd party subclassed window? "
        (ExternalAddress fromString: oldProc) isValid ifTrue: [ ^originalProc ].
    ].

    UserLibrary setWindowLong: self index: GwlWndproc long: newProc.
    self propertyAt: 'oldProc' nlsNeutral put: originalProc.
    ^originalProc.


Regards
Thomas
(sending
> recursive nc paint messages) and there appear to be others. Not using
> TtsAlwaystip style results in the prevention of these recursive messages.
>
> -- Derek
>
> ***           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  ***

I'm seeing a problem now with Windows 7 (it only started doing this
recently) where I will be clicking along in the debugger and VSE will just
quit with a protection violation popup.  This happens even with really old
images that I dug up just to see if I broke anything.  It happens on more
than one Windows 7 PC, and it doesn't happen on my Windows XP box.

Any ideas?

Thanks.

-Carl Gundel

***           this signature added by listserv             ***
*** Visit  http://www.listserv.dfn.de/archives/vswe-l.html ***
*** for archive browsing and VSWE-L membership management  ***