|
if u do like the page says ull be creating this key 
Papa
Murex Co.
while (TRUE)
Papa.WillLove ( Bebe ) ;
|
|
|
|
|
|
Heres the VC client calling the function in a DlL:
CButton * pBar = (CButton*)GetDlgItem(IDC_BUTTONRECV);
long hPbHandle = (long)pBar->GetSafeHwnd();
_CRemoteCall p;
p.CreateDispatch("DllwithForm.Class1");
p.CheckingPB(hPbHandle);
p.ReleaseDispatch();
In the dll, the message is being sent as:
SendMessage(PbarHandle, WM_COMMAND, 0, 0)
This is supposed to trigger of my (test) button handler. But it doesnt....What might be the problem here?
Thanks,
ns
|
|
|
|
|
The wParam (argument which goes right after WM_COMMAND) in the SendMessage call should contain identifier of your button (probably IDC_BUTTONRECV).
Tomasz Sowinski -- http://www.shooltz.com
*** Vodka. Connecting people. ***
|
|
|
|
|
Its the API I am calling in my dll (its a VB dll).
LRESULT SendMessage(
HWND hWnd,
UINT Msg,
WPARAM wParam,
LPARAM lParam
);
so I think my order is okay. MFC's sendmessage takes the command first...so I'm sorry I wasnt clear that I was using the raw API...
Thanks,
ns
|
|
|
|
|
In your case, hWnd should be the handle of button's parent window, Msg is WM_COMMAND, wParam is the button ID (IDC_SOMETHING), lParam is zero.
You don't send message to button itself. Instead, message is handled by parent (usually dialog). That's why you need to pass control ID as well.
MFC encapsulates HWNDs for you and CWnd::SendMessage has three arguments.
Tomasz Sowinski -- http://www.shooltz.com
*** Vodka. Connecting people. ***
|
|
|
|
|
The button is on a CFormView form. So what is the parent? (I need to know the exact objects name, which is the parent. If you just tell me its the CView form I am going to be lost ) Do I have to do the getactiveview stuff? Then I can do an HWnd on it....
REally appreciate your help.
Thanks,
ns
|
|
|
|
|
Yes, the parent window is CFormView. You can't use GetActiveView from within VB .dll, because it's MFC method, not the Windows API function.
Could you describe the relationships between the .dll and client app in more detailed fashion?
Tomasz Sowinski -- http://www.shooltz.com
*** Vodka. Connecting people. ***
|
|
|
|
|
The client app is going to show a progressbar, (tried to put it in the status bar, but I'll use the article link you sent me instead). The VB dll is doing database processing. One operation is done in a for loop and is lengthy. I thought I could SendMEssage a progressbar in the VC client and STEP_IT for each pass through the loop. All I want from the dll is :either a value for the counter, or just a WM_COMMAND message that trigggers a CView button which then STEP_ITs the progressbar> SO for each pass thru, the progressbar advances. This is whats happening. SO far I tried using MAunders ProgressBAr in a Statusbar class to send the message to, directly from the dll. THe dll can send a PBM stepit to the VC client if the progressbar is on the form itself. (In a sample app it does anyways so it ought to work for me too). MY problem is that the progressbar isnt on the form. Its either in the status bar, or else it will be spawned by that class ( CWaitDialog)you linked me too.
I havent tried the latter yet,( it doesnt want to sendmessage to the statusbar progressbar, but will to the forms progress bar.) So I though I'd get a WM_COMMAND notification for each pass through the VB loop and step the progressbar from the handler locally.....want to try that - it might work....
Thanks,
ns
|
|
|
|
|
The problem is that CWaitDialog needs to process messages. You'd have to call CWaitDialog member functions (SetPercentComplete and Pump) periodically from .dll which is beyond VB capabilities.
I guess you should go with progress-on-status. Get the HWND of progress control, pass it to the .dll and send PBM_STEPIT messages. To ensure that progress control redraws itself, you may also call ::InvalidateRect and ::UpdateWindow.
Tomasz Sowinski -- http://www.shooltz.com
*** Vodka. Connecting people. ***
|
|
|
|
|
THe CWAitDialog wil be created on the VC side. the user presses a menu item: MAke DAtabase
THe handler creates a CWait object. All I get from the dll is the loop counter. IT does no UI generation. Unless I'm misunderstanding, if I can get my sendmessage to work, I think (optimist!) that CWait will work. Brcause then I can do stuff like:
void OnButtonREceivingMessage
{
FunctionCalledInButtonHandler;
}
void FunctionCalledInButtonHandler() each time the message is sent
{
BOOL bContinue = TRUE;
CWaitDialog dlg (&bContinue);
globalCounter +=1;
int nPercent = globalCounter something;
dlg.SetPercentComplete (nPercent);
dlg.Pump ();
}
}
Does that make sense?
Thanks,
ns
|
|
|
|
|
Yes, it should work. You may also get rid of this VB-style button-press method invocation. Why don't you use (WM_APP + n) as special message which CWaitDialog would handle and call its SetPercentComplete and Pump?
Tomasz Sowinski -- http://www.shooltz.com
*** Vodka. Connecting people. ***
|
|
|
|
|
just wary of messing with message map entries, but I shall be brave!
Thanks,
ns
|
|
|
|
|
I've been trying to sendmessage to the status bar progress bar all day today. I can send it to the progressbar on the form ,but not to the one in the status bar...
Thanks,
ns
|
|
|
|
|
Although I was able to sendmessage to progressbar directlly PBM_STEPIT. But looks like WM_COMMAND has different requirements..
Thanks,
ns
|
|
|
|
|
Everything works as advertised. You send PBM_STEPIT to control which does something in response. Controls send WM_COMMAND (or WM_NOTIFY) messages to their parents to notify parents about events.
Tomasz Sowinski -- http://www.shooltz.com
*** Vodka. Connecting people. ***
|
|
|
|
|
The sendMessage in the VB dll is not coming from a control. Its in a for loop. I'm trying to aim it at a progressbar in the VC. So maybe I cant use WM_COMMAND since its not a control sending it?
Thanks,
ns
|
|
|
|
|
Whew! It was a five day struggle, but the darn thing works now. I couldnt use the CP class that embeds the progressbar into the status bar (too bad), and I couldnt send a message triggering a button to try CWaitClass (which has the cancel feature). Just as a last straw, I did the whole business of embedding a control manually (string table and indicators and all that stuff). THis way I was able to get a good handle apparently, that the dll liked:
long CMHandle = (long)(((CMainFrame*)AfxGetMainWnd())->m_wndStatusBar.m_WzdProgressCtrl).GetSafeHwnd();
Someone is bound to ask for a cancel feature in my app, so I'll keep plugging away at the sendmessage user defined message idea. So for the moment this problem is resolved. Thank goodness!
Appreciate all the time you spent on this and the interest. Now onto the next challenge!
Thanks,
ns
|
|
|
|
|
ns wrote:
Someone is bound to ask for a cancel feature in my app,
Another reason to check out TaskTimer[^] (see the section "Responding to user input while performing a long task"). 
/ravi
Let's put "civil" back in "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
How are all these progressbars we see around implemented? They suddenly pop up so its a modeless dialog. Then the app send them messages about the current progressbar position. Am I on the right track? Then after the app is done with whatever it was tracking, the dialog gets another message that terminates it.
Thanks,
ns
|
|
|
|
|
|
Wow! Its exactly what I want. I have to get my sendmessags working though, because they tell the bar how much to move. THats been a struggle for the last 5 days!!!!!!
Thanks,
ns
|
|
|
|
|
Also see this article[^] if you'd like to be able to show your users the estimated time remaining!
/ravi
Let's put "civil" back in "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
Wondering about the SendMessage to hidden button that you taught me. (I know I know - hidden menu next time):
<
code>pView->SendMessage(WM_COMMAND,IDC_BUTTONHIDDEN1,0);</code> that works great.
But for the API to simulate a button click apparently (not tried yet) I should do:
BM_CLICK
An application sends a BM_CLICK message to simulate the user clicking a button. This message causes the button to receive the WM_LBUTTONDOWN and WM_LBUTTONUP messages, and the button's parent window to receive a BN_CLICKED notification message.
To send this message, call the SendMessage function with the following parameters.
SendMessage(
(HWND) hWnd, // handle to destination window
BM_CLICK, // message to send
(WPARAM) wParam, // not used; must be zero
(LPARAM) lParam // not used; must be zero
);
So how come the WM_COMMAND triggers the button? It does, thats for sure, but the API equivalent with WM_COMMAND doesnt.....
Thanks,
|
|
|
|
|
When the user clicks a button, the parent window is eventually sent a WM_COMMAND message with the button's id as the wParam. MFC routes this message to the appropriate handler using the message map mechanism. So you can simply post a WM_COMMAND instead of simulating a button click the hard way.
ns wrote:
So how come the WM_COMMAND triggers the button? It does, thats for sure, but the API equivalent with WM_COMMAND doesnt.....
I'm not sure I follow. What do you mean by "API equivalent with WM_COMMAND"? Assuming the button's id is IDC_BUTTONHIDDEN1, the way to execute the button's handler is:
CWnd* pWnd = ...;
pWnd->SendMessage (WM_COMMAND, IDC_BUTTONHIDDEN1);
which is what I believe you're doing.
/ravi
Let's put "civil" back in "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
