Ge van Geldorp [EMAIL PROTECTED] wrote:
Another idea just popped up: the basic problem we're having is
translating the handle passed in to a table containing the accelerator
entries. How about using CopyAcceleratorTableA/W to do that? This
function is designed to do that job and is located in
From: Dmitry Timoshkov
Ge van Geldorp [EMAIL PROTECTED] wrote:
Another idea just popped up: the basic problem we're having is
translating the handle passed in to a table containing the
accelerator entries. How about using CopyAcceleratorTableA/W
to do that? This function is designed
Ge van Geldorp [EMAIL PROTECTED] writes:
Just to be sure: if I understand you correctly you suggest doing the
LockResource16 in LoadAcceleratorsA/W, then GlobalAlloc a new block of
memory, copy the table to the new block and return the global memory
handle as the HACCEL. Then in IsAccelerator
Ge van Geldorp [EMAIL PROTECTED] wrote:
Just to be sure: if I understand you correctly you suggest doing the
LockResource16 in LoadAcceleratorsA/W, then GlobalAlloc a new block of
memory, copy the table to the new block and return the global memory
handle as the HACCEL. Then in IsAccelerator
From: Dmitry Timoshkov
Casper Hornstrup [EMAIL PROTECTED] wrote:
I would like to have the call to the Win16 API LockResource16 removed
from ole32.dll. I guess there is a reason for it being LockResource16
and not LockResource. What is the reason?
Because LoadAcceleratorsA/W returns a
From: Dmitry Timoshkov [mailto:[EMAIL PROTECTED]
Ge van Geldorp [EMAIL PROTECTED] wrote:
Would the attached patch be an acceptable solution?
Basically it does a GetProcAddress on LockResource16
and uses it if found (Wine case). If it's not found,
it uses LockResource().
That will not
Ge van Geldorp [EMAIL PROTECTED] wrote:
That will not work. 32-bit LockResource can't be used on a
memory block allocated by GlobalAlloc16, as I explained before.
No, not in Wine. But Wine will still use LockResource16, so there's no
problem. I can assure you that the memory block won't
From: Dmitry Timoshkov
Then it's better to fix LoadAcceleratorsA/W to use a proper allocator
and use the same aproach in both Wine and ReactOS.
But in that case you have to write a test case which works at least
on NT/2000 and Wine.
Another idea just popped up: the basic problem we're
Ge van Geldorp [EMAIL PROTECTED] wrote:
Would the attached patch be an acceptable solution? Basically it does a
GetProcAddress on LockResource16 and uses it if found (Wine case). If it's
not found, it uses LockResource().
That will not work. 32-bit LockResource can't be used on a memory block
Casper Hornstrup [EMAIL PROTECTED] wrote:
I would like to have the call to the Win16 API LockResource16
removed from ole32.dll. I guess there is a reason for it being
LockResource16 and not LockResource. What is the reason?
Because LoadAcceleratorsA/W returns a value allocated by
-Oprindelig meddelelse-
Fra: Dmitry Timoshkov [mailto:[EMAIL PROTECTED]
Sendt: 6. december 2003 14:00
Til: Casper Hornstrup
Cc: [EMAIL PROTECTED]
Emne: Re: LockResource16 in ole32.dll
Casper Hornstrup [EMAIL PROTECTED] wrote:
I would like to have the call to the Win16 API
11 matches
Mail list logo
