[PATCH v2] server: Release related atoms when destroying a window class

[Dmitry Timoshkov]

Ralf Habacker  wrote:
> - ok(GetClipboardFormatNameW(classatom, str, ARRAY_SIZE(str)) == 0,
> -
>    "UnregisterClass() failed - unable to unregister atom\n");

Using a clipboard api in the class test looks strange, why not call
GlobalGetAtomName() directly instead?

[Ralf Habacker]

Am 26.11.18 um 17:55 schrieb Dmitry Timoshkov:
> Ralf Habacker  wrote:
> > - ok(GetClipboardFormatNameW(classatom, str, ARRAY_SIZE(str)) == 0,
> > -
> >    "UnregisterClass() failed - unable to unregister atom\n");
>
> Using a clipboard api in the class test looks strange, why not call
> GlobalGetAtomName() directly instead?

On native Windows Atoms registered by RegisterClass are not in the
global atom table and therefore could not be checked by inspecting the
global atom table.

from
https://docs.microsoft.com/en-us/windows/desktop/dataxchg/about-atom-tables
"Also, registered classes are stored in an internal atom table used by
the system. An application adds atoms to this atom table using the
RegisterClass or RegisterClassEx function."

[Dmitry Timoshkov]

Ralf Habacker  wrote:
> > > - ok(GetClipboardFormatNameW(classatom, str, ARRAY_SIZE(str)) == 0,
> > > -
> > >    "UnregisterClass() failed - unable to unregister atom\n");
> >
> > Using a clipboard api in the class test looks strange, why not call
> > GlobalGetAtomName() directly instead?
>
> On native Windows Atoms registered by RegisterClass are not in the
> global atom table and therefore could not be checked by inspecting the
> global atom table.
>
> from
> https://docs.microsoft.com/en-us/windows/desktop/dataxchg/about-atom-tables
> "Also, registered classes are stored in an internal atom table used by
> the system. An application adds atoms to this atom table using the
> RegisterClass or RegisterClassEx function."

How does this justify the usage of GetClipboardFormatName?

[Ralf Habacker]

Am 27.11.18 um 08:32 schrieb Dmitry Timoshkov:
> Ralf Habacker  wrote:
> > > > - ok(GetClipboardFormatNameW(classatom, str, ARRAY_SIZE(str)) == 0,
> > > > -
> > > >    "UnregisterClass() failed - unable to unregister atom\n");
> > >
> > > Using a clipboard api in the class test looks strange, why not call
> > > GlobalGetAtomName() directly instead?
> >
> > On native Windows Atoms registered by RegisterClass are not in the
> > global atom table and therefore could not be checked by inspecting the
> > global atom table.
> >
> > from
> > https://docs.microsoft.com/en-us/windows/desktop/dataxchg/about-atom-tables
> > "Also, registered classes are stored in an internal atom table used by
> > the system. An application adds atoms to this atom table using the
> > RegisterClass or RegisterClassEx function."
>
> How does this justify the usage of GetClipboardFormatName?

Some details about internal atom tables on Window are documentated at

https://docs.microsoft.com/en-us/windows/desktop/dataxchg/about-atom-tables

"The system uses atom tables that are not directly accessible to
applications. However, the application uses these atoms when calling a
variety of functions. For example, registered clipboard formats are
stored in an internal atom table used by the system. An application adds
atoms to this atom table using the RegisterClipboardFormat function.
Also, registered classes are stored in an internal atom table used by
the system. An application adds atoms to this atom table using the
RegisterClass or RegisterClassEx function."

On native Windows atoms from RegisterClass are in the same atom table as
atoms registered by clipboard formats and the api function
GetClipboardFormatName() is the official way to get them. You may check
this with the test app from bug
https://bugs.winehq.org/show_bug.cgi?id=46180

[Dmitry Timoshkov]

Ralf Habacker  wrote:
> > > > > - ok(GetClipboardFormatNameW(classatom, str, ARRAY_SIZE(str)) == 0,
> > > > > -
> > > > >    "UnregisterClass() failed - unable to unregister atom\n");
> > > >
> > > > Using a clipboard api in the class test looks strange, why not call
> > > > GlobalGetAtomName() directly instead?
> > >
> > > On native Windows Atoms registered by RegisterClass are not in the
> > > global atom table and therefore could not be checked by inspecting the
> > > global atom table.
> > >
> > > from
> > > https://docs.microsoft.com/en-us/windows/desktop/dataxchg/about-atom-tables
> > > "Also, registered classes are stored in an internal atom table used by
> > > the system. An application adds atoms to this atom table using the
> > > RegisterClass or RegisterClassEx function."
> >
> > How does this justify the usage of GetClipboardFormatName?
>
> Some details about internal atom tables on Window are documentated at

[skipped]

It would save time just mentioning that GlobalGetAtomName() doesn't work
for class atoms under Windows while it works under Wine.

[Alexandre Julliard]

Ralf Habacker  writes:
> On native Windows atoms from RegisterClass are in the same atom table as
> atoms registered by clipboard formats and the api function
> GetClipboardFormatName() is the official way to get them. You may check
> this with the test app from bug
> https://bugs.winehq.org/show_bug.cgi?id=46180

This should be part of the test, i.e. you should check that the atom can
be found with GetClipboardFormatName() before the class is unregistered.