|
See this article.
/ravi
"There is always one more bug..."
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
It is so good!
Maybe it is not a dream!
|
|
|
|
|
Hi folks, I'm writing a software package that runs on NT/2K/XP.
It consists of a service that always runs, plus a UI app that runs while a user is logged on. The service needs to send notifications to the UI app.
So far I have been using BroadcastSystemMessage() to do this and it works, EXCEPT when I have multiple users logged onto XP via fast user switching.
In that case, it seems as if the service only broadcasts to the first logged on user's session; the sessions that logged on later don't seem to get the broadcast.
My service's call to BroadcastSystemMessage() looks like this:
DWORD dwRecipients = BSM_ALLDESKTOPS|BSM_APPLICATIONS;
BroadcastSystemMessage(BSF_POSTMESSAGE|BSF_IGNORECURRENTTASK|BSF_NOHANG, &dwRecipients, MSG_TO_MONITOR, msgtype, 0 );
As I said, the above code works in NT/2K and even XP when only one user is logged on, but when more than one user is logged on XP, it only seems to broadcast to the current user.
I have a feeling that I should be using some other API to get my message through to all user sessions. I've looked at the WTS... API stuff for terminal services, but there doesn't seem to be anything that sends messages (there is a badly-named routine WTSSendMessage, but it shows a messagebox, it doesn't actually send a message).
So, any IPC/XP geeks out there have any advice? At this point I'm thinking of using global objects as semaphores and having a thread in the UI app wait for them and then send messages to it's main window, but I hope there is something simpler...
Thanks,
Alex Benenson
Alex Benenson
alex@sashazur.com
|
|
|
|
|
What if the app running in each client session made a uniquely named named-pipe. You could base it upon user name, or perhaps the client session ID and some other data (like you program name or company name, as advocated by Microsoft). Then your service opens the pipe as well, and the two send data back and forth?
|
|
|
|
|
All i get is the windows directory without he UniHP added
i tried many different configurations... 
CString winDIR = GetWindowsDirectory();
CString addSTR = "UniHP";
//CString fDIR = winDIR + "\\UniHP";
CString fDIR = winDIR + "\\" + addSTR;
MessageBox(fDIR,"Caption",0);
shotgun
|
|
|
|
|
It could be because you are using a CString object when you need a plain char*.
Fortunately CString has an operator converting your string to LPCSTR, so afaik you only need to add an explicit (LPCSTR) before "fDir" in the call to MessageBox.
You made a beginners mistake and now you won't do it again. Right?!
If any one question was to be contributed to Microsofts infinite stupidity re. MFC, this would be the one!
|
|
|
|
|
Dear All
I have this basic doubt - if I have a number of textboxes with in a static Group, is it possible for me to cerate an array to refer to them instead of creating memebr variables for each & every box.
example : assuem there are 3 text boxes , tehn
can i jsut say m_Textboxes[3] isntead of saying m_textboxes1, m_textboxes2, m_textboxes3.
Pl. suggest
Thanks
regards
Sankar
|
|
|
|
|
Tah urgah &foo mutt
bar 47 -> 42
enth mpi jag not gilla
[7%
Fatta?!
I think I have to spell it out. If you can't get a question understandable (and I do appreciate language barriers as I'm no English speaker myself) you will get no response.
Did you use a machine translation engine that tried to engage in some eastern to english translation?
Please check your question for spelling mistakes like "then" becomes "tehn", to begin with. Sorry for being a complete bastard, but without even displaying this amount of interest in your question (to spell these word correctly, which I don't dubt you can do), how much interest do you think people possibly answering it would pay to your question?
/Mike
|
|
|
|
|
Thanks for ur suggestion.
|
|
|
|
|
Thanks for ur suggestion.
I think "ur" was to be "your". 
But to get back to your problem: Yes, you can put edit controls as a group inside "something", so long as you yourself make that "something" a collections class, providing your own operator[] and such.
++luck;
|
|
|
|
|
If you want to refer to them as a collection in order to easily enable/disable them, check out this article.
/ravi
"There is always one more bug..."
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
Yes, you can do this. If you are using the MFC DDX_.. method, you need to declare your member variables etc outside of the AFX_DATA comment flags in the .h fiel of your dialog/class.
You also need to put the DDX_Control etc calls outside the the AFX_DATA_MAP entries in the DoDataExchange function:
DDX_Control(pDX, IDC_TRAYNAME4, m_TrayName4);
DDX_Control(pDX, IDC_TRAYNAME3, m_TrayName3);
DDX_Control(pDX, IDC_TRAYNAME2, m_TrayName2);
DDX_Control(pDX, IDC_TRAYNAME1, m_TrayName1);
DDX_Control(pDX, IDC_TRAY4_TEXT, m_Label4);
DDX_Control(pDX, IDC_TRAY3_TEXT, m_Label3);
DDX_Control(pDX, IDC_TRAY2_TEXT, m_Label2);
DDX_Control(pDX, IDC_TRAY1_TEXT, m_Label1);
DDX_Control(pDX, IDC_STANDARDS_TRAY_SGA, m_StandardsBack);
DDX_Control(pDX, IDC_STANDARDS_TRAY_LDA, m_StandardsLeft);
DDX_Control(pDX, IDC_THUMB1, m_QueuePos[0]);
DDX_Control(pDX, IDC_THUMB2, m_QueuePos[1]);
DDX_Control(pDX, IDC_THUMB5, m_QueuePos[2]);
DDX_Control(pDX, IDC_THUMB6, m_QueuePos[3]);
Roger Allen
Sonork 100.10016
yet to be identified being from the planet Paltinmoriumbanfrettybooter
|
|
|
|
|
I added a tab control to my dialog box using the dialog editor in VC++. I cannot figure out how to add a tab to the control. I have attempted to use TabCtrl_InsertItem(hTemp, 0, &tci); where hTemp is gotten by GetDlgItem(hWndMain, Tab_1); under the WM_INITDIALOG, but the hTemp is always NULL. I can understand this because the control isn't created yey. if I do the same steps using a button to run them, then the tab will show up on the Tab Control. But I need it to show up when the window is created. Can anyone show me a way to do this or point me in the right direction for this? I have been working on it for the past 4 hours and can't figure it out. Thx for the help.
Quinn
Me is very frustrated and pissed off at coding... But that just makes me feel more like a gawd when I beat the computer into submission.
|
|
|
|
|
as a first point, why not follow Joseph Newcomer's advice and never use GetDlgItem (or at least, not again this year). Create a member variable in class wizard to go with your control. He has an article about that on this site. That might take care of all your problems, if we're lucky.
|
|
|
|
|
I was poking around in the MFC source code and found the following line:
pCmdUI->SetCheck(!!m_bHelpMode);
Very strange. Any idea why the !! is used? I thought it may be some weird optimization performance thing then I found the line:
ASSERT(!!GetView()->GetRichEditCtrl().GetModify() == !!bModified);
And of course optimization in an ASSERT is quite pointless.
Anybody hazard a guess?
Joel
|
|
|
|
|
The construct will ensure that direct comparisons to TRUE will evaluate correctly (so long as TRUE is defined as !FALSE)(which it should be).
Of course, you shouldn't be doing direct comparisons to TRUE anyway... My thoughts are these lines were written by some dipshit maintenance programmer straight out of a party school, but hey, maybe this passes for wit at MS... 
--------
Well actually they are sort of interesting Nish, on Nudes
|
|
|
|
|
I guess that this's a way for cripted code... for esample:
asm{
mov ax,1
NOP
NOP
NOP
mov bx,ax
...
};
this's equal to:
asm{
mov ax,1
mov bx,ax
...
};
because NOP don't work operations.
|
|
|
|
|
yah but we used to write stuff like that for diff reasons
either the code was self-modifying at run time
or its a virus with space for random mutations to fool the pattern matchers ... errrrr not that i know anything about writing viruses
---
situations to avoid #37:
"good morning ... how many sugars do you take in your coffee ... and what was your name again?"
|
|
|
|
|
! returns a bool, so !!x returns true if x != 0, false if x == 0. Basically it turns a non-bool into its bool equivalent.
--Mike--
Actual sign at the laundromat I go to: "No tinting or dying"
Like the Google toolbar? Then check out UltraBar, with more features & customizable search engines!
My really out-of-date homepage
Big fan of Alyson Hannigan and Jamie Salé.
|
|
|
|
|
This is the one I'm going with, converting BOOL to bool in a compact form. Still both examples in MFC do not seem to need to do this!
Joel
|
|
|
|
|
One of the many reasons I don't spend much time poking around inside of MFC. I'm afraid I might learn something I don't want to know.
"There's a slew of slip 'twixt cup and lip"
|
|
|
|
|
I've seen some comments here mixing Windows SDK BOOL and C++ bool.
To make that part perfectly clear, the second "!" inverts the logic of the statement it's applied to, first converting "m_bHelpMode" to a C++ bool and then negating that bool. The first "!" then negates/inverts that bool. So once "!m_bHelpMode" is evaluated the value of the expression is a plain C++ bool.
The whole expression if then converted to int (since according to MSDN SetCheck takes an int).
What it really says (or should say) is
pCmdUI->SetCheck(m_bHelpMode != FALSE ? 1 : 0);
Since as we all know true evaluates to the integral value 1 and false evaluates to the integral value 0.
You then touch on the area of optimizations. However mad it seems, MSVC6 actually generates different code for the following functions (go ahead, try both /O1 and /O2)!
bool foo1(int a) { return a == 0; }
bool foo2(int a) { return (a == 0) ? true : false; }
I'd love to see if this part of the MS Compiler optimizer has been fixed in VC7!
|
|
|
|
|
I think a lot of people forget that SetCheck isn't a BOOL. It is actually a tri-state. Like you said, the '!!' forces a 0 or 1 value.
The other example is doing the same thing.
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|
|
Hi.
I am working on my first "real" Windows program. I am at a point in the implementing process where I see a need to multithread one specific job. I will give a good example of something that is very similar to what I am to implement. I will then give my thoughts on a possible solution. I have no prior experience with multithreading, but Jeff Prosise's book does wonders.
I am design a dialog box with a progress bar *very similar* to
the one you see when you download a file using IE. When you download a large file (your download bandwidth is slow), you can see the progress of the download process. The process bar is easy to implement. The part that makes IE progress bar special is you can *still use* IE during the download process. The key is multithread.
Here is my design.
-----
-User activate a feature (via menu)
-View creates a dialogbox w/ progressbar (position 0)
-Dialogbox sends a message to MainFrm.
-MainFrm redirect message to View
-View calls function in Document to begin data processing
-View also passes the function a pointer to dialogbox
-Document starts a new thread (worker thread)
-Thread begin processing data
-Thread sends message back to Document when applicable
-Document calls updated progressbar via pointer to dialog
-----
Again, this is my first experiment with multithread. Is there anything wrong with the design above? I left some small features out. I will include it soon.
Thanks,
Kuphryn
|
|
|
|
|
Some details are missing to make a full evaluation of this approach, but IMHO the possibility of a deadlock is lurking in your design.
If your dialog features a cancel button, and you implement it like this:
void CProgressDialog::OnCancel()
{
signal the thread to die;
wait for the signal to die with WaitForMultipleObject or some similar API;
}then there's a possible deadlock here. Suppose the user presses the Canel button and CProgressDialog::OnCancel is called. If right after the thread is signalled to die the thread happens to be in an update call to the document, and the updating process involves sending (explicitly or implicitly) some message to CProgressDialog, then you've hit a deadlock, as the thread won't answer the termination signal until it's returned from the update call, and CProgressDialog won't process any further messages until it returns from CProgressDialog::OnCancel. You got it? In general, to avoid such deadlocks between a worker thread and the GUI part of a program, it is advisable to have the worker thread post messages to the GUI instead of sending them in a blocking fashion.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
