|
|
Hint: there is a small link below my signature.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Hi all,
[1]Having some 5 Client which are EXEs. And these 5 Clients need to communicate with a single Server which again is an EXE. All the clients and the single server are on same machine.
[2]Clients can send some data to Server which server should store internally.
[3]Clients can request some data which server should return.
[4]Clients need result of executing some procedure and this procedure is in server.
[5]Server need to keep track of all the client processes.
Have gone through various mechanism like :
[1]RPC which is robust but requires more work.
[2]Named pipes
[3]WM_COPYDATA
Suggestion is required regarding which IPC mechanism should be used to achive all the above listed requirements. And roughly how much effort needs to be invested.
Thanks.
|
|
|
|
|
Are the 5 Clients are instances of same client EXE.
-@SuDhIrKuMaR@-
|
|
|
|
|
No. They can be of different application.
|
|
|
|
|
If they are different applications then you can use WM_COPYDATA.It is very easy to use.
-@SuDhIrKuMaR@-
|
|
|
|
|
I have written software with your requirements, except that it could run on multiple networked machines. The approach I took was Named Pipes. I wrote a Generic Server, and a Generic Client, and, in effect, an RPC Procedure. In effect a 'SendMessage' procedure on the Client side, which gathered and wrapped all the Calling Info, created a Header, indicating where in the package each item resides, and, send it over the pipe. On the Server Side, you wait for the message, unwrap it, and present it to the function. For this to work, I created a MessageMap type of structure. For it to work better, Server and Client had only the Basic Bones in the Message Map for initial communication. At startup of the Client, it sends it's message map to the server, which the server registers.
When you have this Generic Server/Client system written, you make each app both a server and a client. Be sure though to make plenty of use of Synchronisation Objects.
N.B. The efford is always substantial, whatever route you take. I took this way because:
1. I considered RPC an overkill, and yet something else I had to learn and which Bill Gates could change on a whim.
2. Fully Debuggable, Very Few System calls you cannot debug into
Regards
Regards,
Bram van Kampen
|
|
|
|
|
My program needs to download a file off the internet to get some information needed to continue. It does not need to save the information, just needs to read it once for the next step.
I have tried
CString TempFile;
URLDownloadToCacheFile(NULL, _T("http://validurl/script.cfm?key=value"), TempFile.GetBufferSetLength(MAX_PATH), MAX_PATH, validcallback);
Once those lines run, TempFile gets filled with a valid path to a temporary file, but the file doesn't actually exist - therefore I can't open it. The following code is what I'm using now, and it works. But I don't like it because it has a hard-coded temporary filename (therefore multiple instances may conflict).
CString TempFile;
TempFile.GetEnvironmentVariable(_(T"TEMP"));
TempFile.Appened(_T("\\MyProg.tmp"));
URLDownloadToFile(NULL, _T("sameurlasabove"), TempFile, validcallback);
After those lines run, the file is created and contains the needed information. But again, it uses a hardcoded temp file, therefore multiple instances cannot run.
So now for the questions:
First of all, is URLDownloadToCacheFile failing because it's a text file generated by a script, and not a binary data file (like a jpg), therefore it doesn't cache it?
Second, what is more practical in this situation. Would you implement code to generate a "random" temporary filename that's not in use? Or should I write code that can read the file right off the internet without saving it to disk first? I don't want to shoot a fly with a cannon, but I'm not sure which is the cannon.
|
|
|
|
|
"The security attributes for the handle to the new thread. These security attributes include an inheritance flag that determines whether the handle can be inherited by child processes."
Can any 1 help me understand this?
|
|
|
|
|
Without context, I wasn't sure what you were talking about. Googling your statement, reveals that this is part of "CreateThread".
Is that what you are asking about?
It sounds like you can pass security rights to a thread and give it the same rights you have acquired somewhere else?
From: http://msdn.microsoft.com/en-us/library/ms682453(VS.85).aspx[^]
HANDLE WINAPI CreateThread(
__in_opt LPSECURITY_ATTRIBUTES lpThreadAttributes,
__in SIZE_T dwStackSize,
__in LPTHREAD_START_ROUTINE lpStartAddress,
__in_opt LPVOID lpParameter,
__in DWORD dwCreationFlags,
__out_opt LPDWORD lpThreadId
);
lpThreadAttributes [in, optional]
A pointer to a SECURITY_ATTRIBUTES structure that determines whether the returned handle can be inherited by child processes. If lpThreadAttributes is NULL, the handle cannot be inherited.
The lpSecurityDescriptor member of the structure specifies a security descriptor for the new thread. If lpThreadAttributes is NULL, the thread gets a default security descriptor. The ACLs in the default security descriptor for a thread come from the primary token of the creator.
Windows XP/2000: The ACLs in the default security descriptor for a thread come from the primary or impersonation token of the creator. This behavior changed with Windows XP SP2 and Windows Server 2003. For more information, see Remarks
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br />
Peter Weyzen<br />
Staff Engineer<br />
<a href="http://www.soonr.com">SoonR Inc -- PC Power delivered to your phone</a>
|
|
|
|
|
just use NULL. if you don't understand that you don't need to worry about security. your threads will be fine
|
|
|
|
|
Hi,
I'm a bit desperate... so I'll do the old Police thing ... S.O.S
We work on an application that has been up and running for several years now - MFC based, links with Stingray. Until recently, CCheckListBoxes worked nice and easy. A new version is about to be released and we just realized that these "@!*!# check listboxes were not displaying strings in release mode running on WindowsXP, when the display is in "Windows 2000 (classic)" theme. The string ARE there, we just can't see them.
In between versions we have split up our app into 4 dll's.. but I still don't get it, it's basically the same code....
Any help, idea or creative suggestion to commit suicide is very much welcome....
Thanks
PS. I built a small test dialog application, and it works. Seems to be a bit more complicated...
|
|
|
|
|
tsvdevteam wrote: I'm a bit desperate... so I'll do the old Police thing ... S.O.S
But it needs to be in a bottle.
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
I had that problem with plain Visual C++ 6.0 MFC apps. I tried various things and got numerous false positives. I finally gave up trying to use CCheckListBoxes with Visual C++ 6.0 and any app that needed them, I moved to Visual C++ 2003.
I'm not sure if that helps but I thought I'd pass on the fact that I fought the good fight for a reasonable amount of time but never found that magic fix that worked on 2000, XP, Vista, Theming enabled/disabled etc...
|
|
|
|
|
Well, that is fine for the source code I write myself. I did write a class to avoid using the faulty one. But, Stingray (Roguewave) uses the bad class in their customize toolbar dialog. I could mess with their source code, but I'd like to avoid doing so.
Thank you for the info !
|
|
|
|
|
That explains it All
I was just wondering what Stingray was about to do to your code\n
Advice: Before you throw a party for fellow students, LOCK UP YOUR COMPUTER
Regards
Bram van Kampen
|
|
|
|
|
Hi,
i want to update only a part of a view with UpdateAllViews().
I read that the simpliest way is to call UpdateAllViews() from the doc and pass a CRect to the view's OnUpdate().
The rect which is passed to the view's OnUpdate() ist the part which is updated.
But it wont work  , I tried it for some hours now, could you helpme? 
Perhaps you know a tut which covers this problem i only found the simple UpdateAllViews(NULL)samples ?
Here is some source from me which updates the whole view doc.cpp:
CString CMyDoc::LoadFile(CString cstrSearchString, CString *ptrArrFileNames, CString cstrFileExtension, int iZaehler)
{
m_iZaehler = iZaehler;
ptrMlf->loadmyfile (cstrSearchString + m_ptrArrFileNames[iZaehler],cstrFileExtension);
m_cstrText = ptrMlf->lf_cstrText;
UpdateAllViews(NULL);
return m_cstrAusgabe;
}
Here the code from the view.cpp:
void CMyView::OnUpdate(CView* pSender, LPARAM lHint, CObject* pHint)
{
CTheReaderDoc *pDoc = GetDocument ();
CRichEditCtrl &rCtrl = GetRichEditCtrl();
rCtrl.SetWindowText (pDoc->m_cstrAusgabe);
rCtrl.SetFont(pDoc->m_ptrFont);
rCtrl.SetModify(TRUE);
}
Many thanx & best regards
ShadowEater
|
|
|
|
|
UpdateAllViews() gives you TWO parameters that get passed to all the
CView::OnUpdate() calls.
What about passing a pointer to a CRect in one of those paramters?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
CrocodileBuck wrote: I read that the simpliest way is to call UpdateAllViews() from the doc and pass a CRect to the view's OnUpdate().
The rect which is passed to the view's OnUpdate() ist the part which is updated.
But it wont work , I tried it for some hours now
The code you posted is not trying to use a CRect so how are we supposed to know what you are trying that is not working?
led mike
|
|
|
|
|
Thx for yor quick replies,
here the code which tries to pass a pointer to CRect:
Doc.cpp:
CString CMyDoc::LoadFile(CString cstrSearchString, CString *ptrArrFileNames, CString cstrFileExtension, int iZaehler)
{
m_iZaehler = iZaehler;
ptrMlf->loadmyfile (cstrSearchString + m_ptrArrFileNames[iZaehler],cstrFileExtension);
m_cstrAusgabe = ptrMlf->lf_cstrAusgabe;
CRect *MyRect;
MyRect(100, 100, 100, 100);
CObject* pHint = NULL;
pHint = reinterpret_cast<cobject*>(MyRect);
UpdateAllViews(NULL, 1, pHint);
return m_cstrAusgabe;
}
Many many thanx and best regards
Croc
|
|
|
|
|
That code compiles?
Maybe try something simpler:
CRect MyRect(100, 100, 100, 100);
CObject* pHint = (CObject*)&MyRect;
UpdateAllViews(NULL, 1, pHint);
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Thanx,
it will work, i could now pass the CRect!
Simple is Simply the best way
But do you know what i have to do in the OnUpdate of the viw.cpp ?
The view will not automatically update only the rect area ?
I men when i print text in my view and then load new text my version of UpdateAllViews should only update the rect ???
But how?
Sorry for my stupid question  but i m really confused !
Many thanx
Croc
|
|
|
|
|
A simple call to InvalidateRect() in your OnUpdate() overrides should do it.
void CMyView::OnUpdate(CView* pSender, LPARAM , CObject* pHint)
{
InvalidateRect((CRect*)pHint, TRUE);
}
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Hi Mr. Salsbery,
i tried
InvalidateRect((LPCRECT)pHint, TRUE);
but it won't work 
Thanx for all your help
Croc
|
|
|
|
|
What does "won't work" mean?
If you're using a rect of (100,100,100,100) then nothing will
happen, since the rect has no dimensions (width and height are 0).
Try a valid rect!
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
