News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

Hotkey code and text 2 clipboard merge

Started by Magnum, December 15, 2010, 12:41:51 AM

Previous topic - Next topic

Magnum

Part of some code I found.

1. Could I incorporate my code to send text to the clipboard in this sequence?

Since I want to be able to paste multiple texts using hot keys, this won't work for the goal in mind.
(Or will it, hmmm.)

I'll have to send the text fragments "elsewhere".

Maybe to the registry. (I keep it lean.)

P.S. Nasal polyps suk.



main proc
local msg:MSG
invoke RegisterHotKey,0,0,MOD_WIN,VK_L ; Windows Key + L
again:
invoke GetMessage,addr msg,0,0,0
.if msg.message==786
call LockWindowStat
.endif

ret
main endp

invoke ExitProcess,0

end start
main proc
local msg:MSG
invoke RegisterHotKey,0,0,MOD_WIN,VK_L ; Windows Key + L
again:
invoke GetMessage,addr msg,0,0,0
.if msg.message==786
call LockWindowStat
.endif

ret
main endp

invoke ExitProcess,0

end start
main proc
local msg:MSG
invoke RegisterHotKey,0,0,MOD_WIN,VK_L ; Windows Key + L
again:
invoke GetMessage,addr msg,0,0,0
.if msg.message==786
call LockWindowStat
.endif

ret
main endp

invoke ExitProcess,0

end start
Have a great day,
                         Andy

evlncrn8

pasted it 3 times to make it 3 times better? :)

dedndave

use Michael's code to get the proper sequence....
the masm32 library version (SetClipboardText in setcbtxt.asm) seems to be different - not sure if that is good or bad
but, Michael's code follows the MSDN example code sequence
the only thing missing is GlobalFree at the end

http://www.masm32.com/board/index.php?topic=3879.msg28908#msg28908

as for pasting "multiple text" into the clipboard
you are going to have a problem if other programs access the clipboard
if you leave the clipboard open, they won't be able to copy/paste
if you close it, then your previous stuff may be overwritten

what you might do, is to keep a running buffer, so that it always has the complete clipboard data you want to appear


evlncrn8

if i remember right you don't do the global free, you let the clipboard handle that...

dedndave

well - i use a tool that tells me it leaves a memory leak
http://www.runtimechecker.com/

MS documents say that the OS takes ownership of the memory object
apparently, that does not mean you do not have to release the handle   :P

MichaelW

MSDN: SetClipboardData

Quote
If SetClipboardData succeeds, the system owns the object identified by the hMem parameter. The application may not write to or free the data once ownership has been transferred to the system, but it can lock and read from the data until the CloseClipboard function is called. (The memory must be unlocked before the Clipboard is closed.) If the hMem parameter identifies a memory object, the object must have been allocated using the function with the GMEM_MOVEABLE flag.

I took this at face value when I created the example, but now that I test a GlobalFree at the end does return success, but as a result the memory usage shown in task manager increases by 4KB. I suspect that your tool is simply looking for a free of each handle, and reporting a leak when it does not find one.

eschew obfuscation

dedndave

the way i read that, once you have closed the clipboard, you should free the allocation as normal

here is the order i am working on...

alloc GMEM_MOVEABLE or GMEM_DDESHARE (for 16-bit compat)
*
open NULL
*
empty
lock
copy
set CF_TEXT
*
unlock
close
free

the asterisks indicate error checks

Magnum

Quote from: MichaelW on December 17, 2010, 04:28:52 PM
MSDN: SetClipboardData

Quote
If SetClipboardData succeeds, the system owns the object identified by the hMem parameter. The application may not write to or free the data once ownership has been transferred to the system, but it can lock and read from the data until the CloseClipboard function is called. (The memory must be unlocked before the Clipboard is closed.) If the hMem parameter identifies a memory object, the object must have been allocated using the function with the GMEM_MOVEABLE flag.

I took this at face value when I created the example, but now that I test a GlobalFree at the end does return success, but as a result the memory usage shown in task manager increases by 4KB. I suspect that your tool is simply looking for a free of each handle, and reporting a leak when it does not find one.


Using RunTimeChecker on my code, after my program had gracefully exited,

I got "one memory block in use".

Good or bad?





Have a great day,
                         Andy

dedndave


dedndave

i have searched the web, looked at the MSDN example, Michael's example, and the masm32 lib version
the differences i am seeing are as follows

1) the masm32 version uses GMEM_MOVEABLE or GMEM_DDESHARE
including the GMEM_DDESHARE flag shouldn't hurt anything, as it is ignored by newer OS's

2) the order things are done is a little different
it makes sense to me to allocate the memory before opening and emptying the clipboard
this allows for better flow if an error occurs

3) the masm32 lib version allocates 64 bytes more than required by the string
probably a good idea

4) the masm32 lib version uses StrLen to get the string length
i think i would require the length as a parm because the caller probably already knows the length and it is faster

5) discrepency in whether or not to free the global allocation
again - it seems only logical that, once the clipboard has been closed, you should free the allocated block

6) the masm32 lib version makes no error checks
as i outlined above, making some checks is probably a good idea
although, you shouldn't have to check every step
for example, i don't think you'll ever see an error locking/unlocking, so long as the allocation uses the right flag

dedndave

oh - forgot to mention....

many examples i see do this...

lock
copy
unlock

huh ????? - lol
that makes no sense at all

i think you want to leave it locked during SetClipboardData
THEN unlock
as i recall, the masm32 lib version does it this way

dedndave

#11
i have modified the order a bit to simplify the code...

alloc GMEM_MOVEABLE or GMEM_DDESHARE (for 16-bit compat)
*
lock
copy
unlock
open NULL
*
empty
set CF_TEXT
*
close
free

the asterisks indicate error checks

dedndave

#12
here is what i come up with
it needs testing, of course
suggestions are welcome   :U


EDIT - removed the code from this post, as it had bugzzz

dedndave

#13
let's try this one
with error checks and return status in EAX


EDIT - removed the code from this post, as it had bugzzz

dedndave

#14
i'd like to test it under diff OS's - especially win 7


EDIT - removed the code from this post, as it had bugzzz