News:

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

PostMessage Control

Started by bomz, July 02, 2011, 12:53:56 PM

Previous topic - Next topic

bomz

Quote from: donkey on July 03, 2011, 03:34:41 PM
I haven't read this whole thread so forgive me if I'm off the mark here. However, from the first few posts I gather that you are having problems sending certain messages to a window in another thread using SendMessage but mysteriously PostMessage seems to work. That is becuase the input states of the two message queues are independant of each other, use AttachThreadInput to syncronize them then SendMessage should work fine.


LOCAL chWnd:DWORD
LOCAL dhWnd:DWORD
----------------------------------------
invoke GetCurrentThreadId
mov chWnd, eax
invoke GetWindowThreadProcessId, EDITOR.hwndFocus , addr dhWnd
mov dhWnd, eax
invoke AttachThreadInput,chWnd,dhWnd,TRUE
--------------------------------------
invoke SendMessage,EDITOR.hwndFocus, WM_CHAR,edx,0
--------------------------------------
invoke AttachThreadInput,chWnd,dhWnd,FALSE
invoke ExitThread, 0

bomz

the problem is - that Windows don't provide that somebody would print quicker than 5000 sing in sec, and provide only 10 000 places in postmessage queue

bomz

Quote from: dedndave on July 02, 2011, 02:04:22 PM
        push    0
        CALL    OpenClipboard


        push    hWnd
        CALL    OpenClipboard



and some other artefact too happens like that

Quote
A handle to the window to be associated with the open clipboard. If this parameter is NULL, the open clipboard is associated with the current task.
If an application calls OpenClipboard with hwnd set to NULL, EmptyClipboard sets the clipboard owner to NULL; this causes SetClipboardData to fail.

qWord

well, the method Donkey describe is also used in my example. Just to say, AttachThreadInput() fails on console windows (protected). Fortunately it work if you set the console as the forground window.
WM_CHAR, WM_KEYDOWN ,... are messages that are send by the OS - they are not not designed for explicit  sending. SendInput() is the way to go!
FPU in a trice: SmplMath
It's that simple!

bomz

#49
WM_CHAR rather than SendKey of SendInput because it have target. you may move window hide it print to another editor. only one problem with speed of print

http://xmages.net/storage/10/1/0/a/b/upload/05df53f1.gif

qWord

Quote from: bomz on July 03, 2011, 05:30:45 PM
WM_CHAR rather than SendKey of SendInput because it have target. you may move window hide it print to another editor
:dazzled:
good luck!
FPU in a trice: SmplMath
It's that simple!

bomz

program needs several methods - sendkey one of them

dedndave

i a not sure i understand the MSDN document...
QuoteIf an application calls OpenClipboard with hwnd set to NULL, EmptyClipboard
sets the clipboard owner to NULL; this causes SetClipboardData to fail.

that makes no sense to me   :P
in their own example, they set it to NULL...
http://msdn.microsoft.com/en-us/library/ms649016%28v=VS.85%29.aspx

here is a little test program
it places the text "test string" into the clipboard...

bomz

data set, but some may crashes. findtext for ex. and some times data not set or set even odd time. I think this may updates with windows update

bomz

invoke CreateThread,NULL,NULL,eax,0,0,addr ThreadID
mov ThreadID, eax
invoke SetWindowLong,hList,GWL_WNDPROC,ThreadID
mov OldWndProc,eax


this code would work?

dedndave


bomz

ThreadID is not physical address in memory?

dedndave

whether it is or not, a thread function does not have 4 parms   :bg
even so, i don't think it's a valid plan
if you want to do something like that, you create the window in a thread
then, the message loop can be in that thread   :U

bomz

parameters is not a problem

WndProc proc hWnd:DWORD,uMsg:DWORD,wParam:DWORD,lParam:DWORD


ListViewWndProc proc hWnd:DWORD
pop uMsg
pop wParam
pop lParam

Thread and proc diff things

bomz

I must post-send message CHAR with address in lParam.This addres in lParam to old wnd proc and count of message