|
I'm not sure what you want to look at on the stack. automatic variables? Return pointers?
That's all that's there that is useful info. If you use the disassembly window while debugging
you can see how compiled code is manipulating the stack. My assembly skills are too rusty to
provide any sample code 
What kind of handles are you referring to? Operating system handles like HWND, HANDLE, etc.?
OS handles in Windows are opaque - they have no meaning to the user except that they represent
some object in the system. You can't, as a programmer, make any assumptions about the type
or contents of a handle. A handle could be a simple value, a structure, a pointer to a structure,
an index, etc.
You asked about the size of a handle. What do you need to know? The size of a HANDLE object?
Mark
|
|
|
|
|
thanks for your reply..
what i mean to read in the handle, is sections is the most important, and then mutant, file and events..
about the stack, i need to know the stack information about a thread thats is running with the EXE. for example a thread stack:
ntkrnlpa.exe!KiUnexpectedInterrupt+0xf0
win32k.sys+0x2fa0
win32k.sys+0x37a6
win32k.sys+0x37c3
ntdll.dll!KiFastSystemCallRet
firefox.exe!JVM_GetJSSecurityContext+0x2d9e6
firefox.exe+0x1012
kernel32.dll!RegisterWaitForInputIdle+0x49
i need to monitor the stack of this thread in way to monitor...
when i mean about the size of 0x0001e000 is that because i dont know what means all that number "0x0001e000" i dont have a clue... 
thanks for the help would be apreciate, im looking more for a tuturial that could explain how to work with threads and handles read this kind of information from a file
|
|
|
|
|
I'm not sure about the stack stuff, but handles I can help with.
van-ux wrote: when i mean about the size of 0x0001e000 is that because i dont know what means all that number "0x0001e000" i dont have a clue...
My previous point was that it's not for you to know. It's not documented and Microsoft can choose
to change what it represents at any time. You may find some documentation online about certain
Windows handles but it's really not useful - it can change at any time.
"0x0001e000" is probably an address...but maybe it's an index. Maybe it's bit flags.
Handles and Objects[^]
DLLs, Processes, and Threads[^]
|
|
|
|
|
thanks for the links m8, i have a look, and i have something to read now  thanks
btw i saw that handles are contained inside the objects, and the objects contain all information about the handles asuel... you know a good tuturial or book that could help me in this case just by chance, otherwise i will google it...
the book i mean for programming...
thanks great post
|
|
|
|
|
van-ux wrote: you know a good tuturial or book that could help me in this case just by chance, otherwise i will google it...
I don't know of any specific titles offhand, sorry
|
|
|
|
|
I am trying to change font size in an edit box with the following code. There seems to be a limit on the size I can get, regardless of the params in font.CreatePointFont. The max seems to be about 14 point bold. How can I get a larger size?
CFont font;<br />
font.CreatePointFont(920, "Garamond");<br />
CFont *pFont = (&font);<br />
GetDlgItem(IDC_EDIT_Utility)-> SetFont(pFont, TRUE);
|
|
|
|
|
How are you checking to see if you get the requested size?
You could try checking the created font to see the attributes of the created font:
CFont font;
font.CreatePointFont(920, "Garamond");
LOGFONT logfont;
font.GetLogFont(&logfont);
Is that the way you've coded to create the font? If so, if "font" goes out of scope then the
fonts handle (HFONT) is destroyed.
Mark
|
|
|
|
|
Hi,
I have created a SDI with FormView. The data from the view can be stored into a file and when the file is clicked, it opens directly into the formview with the edit boxes automatically filled.
Now, when one file/document is open, if the user selects File-New from the menu, a new document opens and all the fields on the Form get reset (set to zero). The previously open document gets closed.
I would like to ask the user if he would like to save the data before opening a new document.
I have put this option when the Exit button is clicked, but am not able to figure out how to open a new document after the saving process is over.
Please help!
Fortitudine Vincimus!
|
|
|
|
|
Override CDocument::OnCloseDocument().
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good, use it!!!
|
|
|
|
|
AH!! This works ... Is it the correct way?
I added this in the MainFrame Class:
void CMainFrame::OnFileNew()
{
CSFPAView *pFV = (CSFPAView *)GetActiveView();
if (pFV->DoBeforeExit())
{
CSingleDocTemplate * pTemplate = (CSingleDocTemplate *) GetActiveDocument()->GetDocTemplate();
pTemplate->OpenDocumentFile(NULL);
}
}
Fortitudine Vincimus!
|
|
|
|
|
Tara14 wrote: I would like to ask the user if he would like to save the data before opening a new document.
If the document contents have not changed, no prompt is necessary. Otherwise, look at the SetModifiedFlag() method.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Hello everybody. Recently I coded a client-server application and put it in the start up folder. Everything works perfect except for the log file. The problem is this: When the computer starts up the log file opens fine according to file.is_open(), however, nothing gets written to the file. This only happens on start up. If I open it myself the log file works fine and records everything. But when placed in the startup folder to open itself it fails??? What could be the problem?? This has been annoying me forever and any help would be appreciated. Thanks in advance everybody!!
by the way: using windows XP, VC++ 7
-- modified at 16:01 Tuesday 6th February, 2007
|
|
|
|
|
Are you using the complete path or a relative path when specifying the name of the log file when you open it?
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good, use it!!!
|
|
|
|
|
|
Try using an absolute path instead.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
thank you very much works fine now
|
|
|
|
|
Hi,
I am running visual C++ 6.0 MFC. I need to have a secondary thread marshal an interface pointer using CoMarshalInterThreadInterfaceInStream(REFIID riid, LPUNKNOWN pUnk, LPSTREAM* pStm); The interface is used to automate Excel. I want my primary thread to access the interface using CoGetInterfaceAndReleaseStream(LPSTREAM pStm, REFIID riid, LPVOID* ppv); What I need to know is how do I find riid, the reference to the identifier of the interface to be marshaled?
Thanks,
Buck
|
|
|
|
|
AFAIK the REFIID is declared in the header file for the object you are using. I am not familiar in automating Excel but I know there are several articles here on CP that cover the subject. Do a search.
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good, use it!!!
|
|
|
|
|
I have been searching the web for 6 hours and all I can find are references to CoMarshalInterThreadInterfaceStream() and CoGetInterfaceAndReleaseStream() but I cannot find ANY real examples. Where does the COM interface store this REFIID? I need to find out how to get the REFIID so I can pass it into these two functions.
Buck
|
|
|
|
|
If you've #imported the typelib then you can add the import directive named_guids to the import statement.
Then you will find the IID in the .tlh file.
Otherwise you could marshal the IDispatch interface, unless you're using the v-table part of Excel's dual interfaces. Just use IID_IDispatch as REFIID.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
|
|
|
|
|
That Just gives me an IID_IDISPATCH undeclared identifier error. I have a thread that I want to be able to cancel and then allow the primary thread to save the excel file and quit the excel application. I searched my entire disk for *.tlh and found no files.
void C65602::RunTestThread()
{
DWORD result;
HRESULT hr;
hr = CoInitialize(NULL);
pTests->pOutput->OpenWorksheet();
pTests->pOutput->OutputMainHeader();
CoMarshalInterThreadInterfaceInStream(IID_IDISPATCH, NULL, &pStream); // IID_IDISPATCH ERROR HERE
... DO THREAD PROCESSING ...
CoUninitialize();
AfxEndThread(0, TRUE);
}
void COutput::OpenWorksheet()
{
m_App.CreateDispatch("Excel.Application");
}
|
|
|
|
|
BuckBrown wrote: That Just gives me an IID_IDISPATCH undeclared identifier error
IID_IDispatch, not IID_IDISPATCH. C/C++ identifiers are case sensitive.
What do you intend to do in your thread and why do you think you need a threading solution?
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
|
|
|
|
|
Sorry yeah,
I have tried to declare this various ways (depending on the sparse examples I'm looking at)
IDispatch dispatch;
IID_IDispatch dispatch;
DISPID dispatch;
LPDISPATCH dispath;
None of them work the way I want. It either compiles and does not work or it fails to compile because it cannot convert IDispatch* to __GUID*. I have tried casting but havent found one yet.
I am looking at trying m_App->lpDispatch->QueryInterface() function. There are a couple of reasons why I want a secondary thread. The secondary thread might take from 10 minutes to over an hour. I wanted a way to allow the user to cancel the test from the same user interface (in this case a tab page) that launched the test. The secondary thread can create and output to an Excel file and then save the file and quit the Excel automation before it dies. If the user clicks on the 'Cancel Test' button I want the primary thread to perform the save and quit. This is why I need to marshal the interface pointer out of the secondary thread and get it from the primary thread.
|
|
|
|
|
Ok...
First, a couple of suggestions and things to consider:
1. I'm a little suspicious about your reasons for using a second thread. You're performing some kind of tests from your secondary thread. How do you know when a test has finished and what the result of the test was? Perhaps this could be done from the primary thread, it depends on how your tests works. I'm not saying that it's wrong, I'm just saying "think about it because it will save you a lot of trouble".
2. To me it would feel more natural if the primary thread was responsible for launching Excel as out-of-process automation server. I suspect that you should get a filename from the user which requires interfacing with the GUI and that shall always be done from the primary thead. It's also a common guideline for each thread that creates COM servers to process messages. In your case the Excel proxy would reside in your secondary thread which I suspect doesn't process messages. If you launched Excel from your primary thread, then you would have the message pump for free. 
3. If you continue with your solution to launch Excel from your secondary thread and let the primary thread do the saving stuff to Excel, it won't work if your secondary thread doesn't process messages. You risk facing a nasty deadlock if you try to exit your thread, calling ::CoUninitialize(), before the primary thread has released its interface to Excel. This is because the RPC service, which handles the marshalling between apartment boundaries, sends messages to the proxies and stubs in the different apartments. Sending a message means to wait until the receiving thread has processed the message and if it doesn't your sending thread will deadlock.
Now for how to set up the marshalling and the use of IID_IDispatch:
Declare an IStream* variable in your class. This is going to be used when you're calling ::CoMarshalInterThreadInterfaceInStream() and ::CoGetInterfaceAndReleaseStream().
The code from which you marshal an interface would look something like this:
HRESULT hr;
hr = ::CoMarshalInterThreadInterfaceInStream( __uuidof( IID_IDispatch ), lpDispatch, &m_stream );
if( FAILED( hr ) )
{
}Now the lpDispatch interface is ready to be fetched from another thread.
The code in the other thread would look something like this:
HRESULT hr;
IDispatch* lpDisp;
hr = ::CoGetInterfaceAndReleaseStream( m_stream, __uuidof( IID_IDispatch ), (void**)&lpDisp );
if( FAILED( hr ) )
{
lpDisp = NULL;
}Now you have a marshalled IDispatch interface.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
|
|
|
|
|
Thanks for the input. I have printed it off for my binder. The __uuidof cast is completely alien to me. In the meantime I have decided to try this with a UI thread. The reason I'm trying to do this with a thread is basically to learn how to use threads. So far I have not been very successful at it. So now I have a user interface thread but it has a few problems of its own when it needs to display a dialog box (application crashes). I will post this problem as something new.
Thanks again.
Buck
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
