|
From MFC dlg app. I post message
CWnd* pWnd = FindWindow(NULL, _T("Osiris"));
HGLOBAL hGlobal = ::GlobalAlloc(GHND, 64000);
LPVOID pMem = (LPVOID)::GlobalLock(hGlobal);
::memcpy(pMem, (LPVOID)"AAA", 4);
::GlobalUnlock(hGlobal);
pWnd->PostMessage(0x450, (WPARAM)hGlobal, GetSafeHwnd());
In the other MFC dlg app. I reciving
LRESULT COsirisDlg::OnUser(WPARAM pWparam, LPARAM pLparam)
{
HGLOBAL hGlobal = (HGLOBAL)pWparam;
LPVOID pMem = ::GlobalLock(hGlobal);
// GlobalFree(pMem);
DWORD dwErr = 0;
if(!pMem)
dwErr = GetLastError();
TCHAR* pChar = (TCHAR*)pMem;
error is always 6 - bad handle.
Why it could be?
Thanks.
We yesterday got drunk with Bacchus ...
|
|
|
|
|
Why are you not using the WM_COPYDATA message? Passing data to another application is what it is designed for.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
Thanks David. I don't want SendMessage I need to Post
When you use post message. In msdn mentioned you need to use send. I try post it not works.
We yesterday got drunk with Bacchus ...
|
|
|
|
|
Given that constraint, you'll need to use some other form of IPC (e.g., the clipboard, DDE, memory-mapped file, pipes). The problem is not sending/posting the message between the two, but allowing one process to allocate memory and have the other access it.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
I think GlobalAlloc allow access memory across process?
In classicall clipbord you use GlobalAlloc. I even found my old C code where I do exactly what I doing now. I thought I foregot something. I understand memory-maped files but information I passing not worth it. It just one small array.
I'll use copule tries. Can't it believe it not work. Thanks.
If will have any ideas/sugestions why
GlobalAlloc
GlobalLock
GlobalUnlock
--------------
another process
--------------
0x0000 = GlobalLock !!! FAIL (WHY)
Let me know.
Thanks.
We yesterday got soberb with Bacchus ...
|
|
|
|
|
Alex_Y wrote:
I think GlobalAlloc allow access memory across process?
A pointer from GlobalAlloc() is only good in one process' address space.
See here for more.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
Thanks. Yes Microsoft as ususal did some magic around WM_COPYDATA, and nobody knows this magic. Because in 16-bit and in VS5 you was not able to access to structure. You was forced to use GlobalAlloc. I had server 32bit VS5 and client 16bitVS4. But that functionality scilently disappiared and WM_COPYDATA not requiring global handle anymore. Magic
Thanks a lot.
We yesterday got drunk with Bacchus ...
|
|
|
|
|
Alex_Y wrote:
I think GlobalAlloc allow access memory across process?
If I remember correctly that was possible in 16bit windows but it does not work with 32bit windows.
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
"Obviously ??? You're definitely a superstar!!!" - mYkel - 21 Jun '04
"There's not enough blatant self-congratulatory backslapping in the world today..." - HumblePie - 21 Jun '05
Within you lies the power for good - Use it!
|
|
|
|
|
Thanks I think you right I used to use it in 16bit compiler, but nobody mentioned it the help
Thanks.
We yesterday got drunk with Bacchus ...
|
|
|
|
|
I want to have an application with multiple views upon a single document. My idea is to derive different types of ChildViews so that they can look at the data in different ways. For example, open a 'spreadsheet' and see columns rows in one view and a graph in another view.
Is it better to start with the MFC AppWizard making a 'Single document' and then try to wedge in multiple views? Or is it better to start with 'Multiple Document' and then constrain user to a single open document with multiple views?
An alernative is to have a multiple document interface with each type of document sharing a single, different type of view. I really have four different types of data I was planning to store in a single document.
It has been a LONG time since I did this - 1995
I forget which way was more optimal
|
|
|
|
|
I always use MDI in such cases it more flexible.
We yesterday got drunk with Bacchus ...
|
|
|
|
|
Is there a mechanism to associate multiple view types with a document type, assuming I am now using CMultiDocTemplate and the MDI with document/View support?
It would still be nice to support multiple documents and different types of views for some of the document types.
Awhile back I seem to recall a project I wrote where I might have been doing SDI and I was able to get a 'new widnow' menu item going where the user could select a specific view window type to look at the data a certain way (like New Table Window, New Graph Window, etc.). Has anyone seen an example of doing that for an MDI application with multiple document types?
|
|
|
|
|
>>Has anyone seen an example of doing that for an MDI application >>with multiple document types?
Create MDI in the wizard and find place where you AddTemplate
if you create another document+frame+view you can again call AddTemplate with new classes you created. As many time you call AddTemplate with new set document+frame+view you will have more supported document types.
>>Is there a mechanism to associate multiple view types with a >>document type, assuming I am now using CMultiDocTemplate and >>the MDI with document/View support?
I guess only AddView
Call this function to attach a view to the document.
void AddView(
CView* pView
);
// CMyView derived from CView
CMyView* pMyView = new CMyView(...);
pDoc->AddView(pMyView);
Everyting is coocking in DocTemplate
We yesterday got drunk with Bacchus ...
|
|
|
|
|
My doc has three views and the views are contained within CChildFrame objects .
I want the user to use the file menu to open and close the documents but not kill the view separately . I do not want the user to kill View A using the x mark ?
What is a clean way of doing this ?
Does overriding onClose in CChildFrame by commenting out CMDIChildWnd::OnClose() work . When the framework is closing the project , I want the call to be made , but I have no knowledge of this in this class .
void CChildFrame::OnClose()
{
// TODO: Add your message handler code here and/or call default
//CMDIChildWnd::OnClose();
}
Is this safe under both conditions ? what are the alternatives ?
Engineering is the effort !
|
|
|
|
|
Can you use/adjust windows styles of frame to eleminate cross(x) button or disable it on the title bar no your views?
We yesterday got drunk with Bacchus ...
|
|
|
|
|
Hi all,
I'm getting following error while my program calling another program.
My program just call the other .exe program using ShellExecuteEx().
Both program are on the same network drive but different location.
"JIT Debugging failed with the following error: 0x800405a6"
How can I fix it?
|
|
|
|
|
How are you calling ShellExecuteEx() ? Is the message from your program or the other?
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
|
|
I don't really know what I expected to see there...
|
|
|
|
|
|
I'm working on a bit of code that manages files and directories with operations such as copy, delete, archive to removable media, etc. If the program encounters an error while performing one of these operations, I want to be able to give the user some information as to the nature of the error, such as file not found, directory not found, access failure, invalid path, etc.
However, many of the functions I'm using, such as SHFileOperation, return only "successful" or "unsuccessful", and I can't find a way to get any information on the nature of the error on an "unsuccessful" return. Any ideas?
|
|
|
|
|
|
Where is it documented that SHFileOperation() uses GetLastError() ?
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
It isn't. I incorrectly assumed SHFileOperation() called SetLastError() .
/ravi
My new year's resolution: 2048 x 1536
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|