|
The task manager does not promise cleanup when you end the process from the Processes tab. In fact, it wafrns you that some DLL's may not shut down, etc, etc.
The only reason someone would want to "End Process" on your app is because your app crashed and locked up. The only fix for that is writing better code so that the user doesn't have to use the "End Process" button.
------- sig starts
"I've heard some drivers saying, 'We're going too fast here...'. If you're not here to race, go the hell home - don't come here and grumble about going too fast. Why don't you tie a kerosene rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
I am trying to have a overlapped blocking pipe write so that I can have either data sent signal or a timeout signal... The code I have written is as follows
<br />
DWORD dwMode = PIPE_READMODE_MESSAGE | PIPE_WAIT;<br />
BOOL bSuccess = ::SetNamedPipeHandleState(m_hPipe, &dwMode, NULL, NULL);<br />
and my pipe write function have code
<br />
OVERLAPPED op = {0};<br />
op.hEvent = CreateEvent(NULL, TRUE, FALSE, NULL);<br />
<br />
bSuccess = ::WriteFile(m_hPipe, lpBufferPos, dwToWrite,<br />
&dwNumberOfBytesWritten, &op);<br />
<br />
if(bSuccess)<br />
{<br />
return TRUE;<br />
}<br />
else<br />
{<br />
m_dwLastError = ::GetLastError();<br />
if(m_dwLastError == ERROR_IO_PENDING)<br />
{<br />
switch(WaitForSingleObject(op.hEvent, m_dwTimeOut))<br />
{<br />
case WAIT_OBJECT_0:<br />
return TRUE;<br />
break;<br />
case WAIT_TIMEOUT:<br />
m_dwLastError = ::GetLastError();<br />
return FALSE;<br />
case WAIT_FAILED:<br />
m_dwLastError = ::GetLastError();<br />
return FALSE;<br />
break;<br />
}<br />
}<br />
else<br />
{<br />
return FALSE;<br />
}<br />
} <br />
}<br />
The problem that I am facing is that all my Write to pipe function calls keeps returning with TRUE code and the corresponding first Read call in the child process remains locked at the WaitForSingleObject call and then after some write pipe operation in the parent process Read returns with "More data is available" error.
Can anyone direct me what I am doing wrong.
|
|
|
|
|
PS> what I need is a blocking write with a timeout so that if no read is performed for a specified time the thread unlocks.
|
|
|
|
|
Hi there! The thing I would like to know is how to lock and unlock a single variable, such as int or double? All these semaphores and events must be declared within a class, but how can I do it with simple types?
|
|
|
|
|
You still have to use at least a Critical Section to lock against while accessing the simple type.
Ant.
I'm hard, yet soft. I'm coloured, yet clear. I'm fruity and sweet. I'm jelly, what am I? Muse on it further, I shall return! - David Williams (Little Britain)
|
|
|
|
|
Hmm, I've found InterlockedExchange and I guess that's what I need. By the way, what will happen if I read variable's value in one thread and write to it from another thread using InterlockedExchange, something like this:
bool yes_no; //Common variable
void Thread1Func()
{
bool tmp;
tmp=yes_no;
}
void Thread2Func()
{
InterlockedExchange((LPLONG)&yes_no,true);
}
So, if thread 1 get's to yes_no first is it going to work correctly?
|
|
|
|
|
Assuming that Thread 1 has to wait until Thread 2 has updated the data then no it is not guaranteed to work.
Have you thought about using events?
Wait for the event in Thread 1 (before the read of the variable) then signal the event in Thread 2 after the variable update.
This will ensure the data is current when Thread 1 comes to read it.
Ant.
I'm hard, yet soft. I'm coloured, yet clear. I'm fruity and sweet. I'm jelly, what am I? Muse on it further, I shall return! - David Williams (Little Britain)
|
|
|
|
|
Can i delete an object using free(); which was allocated using operator new ?
|
|
|
|
|
xcavin wrote:
Can i delete an object using free(); which was allocated using operator new ?
I think the first question is why you would want to. Mixing C and C++ memory allocation isn't exactly the best way of writing solid code.
Michael
CP Blog [^]
|
|
|
|
|
Michael P Butler wrote:
the first question is why you would want to.
I never want to do that. But this was asked to me in an interview. I replied the object's destructor will not be called when free() is used.
I just wanted to know if there is any other views on this issue.
|
|
|
|
|
This is correct, the class destructor isn't called if you attempted to use free(), and therefore your answer is NO!
Ant.
I'm hard, yet soft. I'm coloured, yet clear. I'm fruity and sweet. I'm jelly, what am I? Muse on it further, I shall return! - David Williams (Little Britain)
|
|
|
|
|
I opend an INF file by SetupOpenInfFile.
To query values and fields of keys I used SetupGetLineText and SetupGetStringField.
I know entry section name. So I can enumarate all other section and key values.
But how can I get a key name by its index number in known section?
We know that INF file structure is same as:
[Section1]
Key1=value1
key2=value2
...
|
|
|
|
|
I have 2 class - CUserDlg,CMenuDlg. I collect a string value from CUserDlg and pass/use this value to/in CMenuDlg.
I define the variable as Public in CUserDlg and Collect value for it.
Public : CString szName;
UserDlg.Cpp:
szName = "Hai";
CDialog::EndDialog(0);
CMenuDlg dlg;
dlg.DoModal();
and close CUserDlg screen and calls CMenuDlg screen.
I define CUserDlg object in MenuDlg header file.
CUserDlg* UserData;
And when I access UserData->szName in CMenuDlg.Cpp file, i get only NULL value.
Pls help me out.
|
|
|
|
|
sugumar wrote:
I define CUserDlg object in MenuDlg header file.
CUserDlg* UserData;
And when I access UserData->szName in CMenuDlg.Cpp file, i get only NULL value.
Where do you assign the original CUserDlg pointer to the UserData pointer. I usually pass the pointer via the constructor, but your code doesn't appear to do that.
Roughly,
UserDlg.cpp
CUserDlg::OnOK()<br />
{<br />
CMenuDlg dlg(this)<br />
dlg.DoModal()<br />
}
CMenuDlg.h
class CUserDlg;<br />
<br />
class CMenuDlg : public CDialog<br />
{<br />
public:<br />
CMenuDlg(CUserDlg* pUserDlg, CWnd* pParent = NULL);
<br />
private:<br />
CUserDlg* m_pUserDlg;<br />
}
CMenuDlg.cpp
#include "UserDlg.h"<br />
<br />
CMenuDlg::CMenuDlg(CUserDlg* pUserDlg, CWnd* pParent)<br />
{<br />
m_pUserDlg = pUserDlg;<br />
}
Then when you want to access szName
void CMenuDlg::SomeFunc()<br />
{<br />
CString temp = m_pUserDlg->szName;<br />
}
Michael
CP Blog [^]
|
|
|
|
|
thanks for your immediate response and which also solves my problem.Tnahk You Michael
|
|
|
|
|
Did you try it to see if you could?
------- sig starts
"I've heard some drivers saying, 'We're going too fast here...'. If you're not here to race, go the hell home - don't come here and grumble about going too fast. Why don't you tie a kerosene rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
As you might know 'new' and 'delete' are C++ keywords for memory allocation and deallocation.
But these small words do more than just memory management.
'new' will call the constructor for the object being created and 'delete' will call the destructor for the object being destroyed. This means that if you create a dynamic object with 'new' and free the memory for that object using 'free', your destructor will not get called and resources allocated by your object will not be freed.
Technically I suppose you could use 'free' given that your class doesn't have to free up any memory in its destructor, but then you have another problem.
When building for Debug some extra bytes will get allocated using 'new' to be able to discover memory leaks and so forth. If you don't use 'delete' at least this memory checking won't work and there is a great risk that the application will crash.
In short:
ALWAYS use 'delete' when you have allocated memory using 'new'.
Using 'free' when deallocating memory allocated using 'new' might work under VERY special circumstances but trying to use this technique would be begging for problems in my opinion.
--
Roger
|
|
|
|
|
Thanks. My 5 marks.
Espically for that Debug build problem.
|
|
|
|
|
I posted the following in the VB forum but nobody seems to be interested (or has the ability to help).
------------------------------------
I've written a DLL in VC6 (C++), and I think it's going to be used by a VB programmer. Knowing this ahead of time, I return variants from all exported functions.
I've tested the DLL with a C++ program, but I don't have VB installed and don't care to install it, so I'm looking for some help from someone that already has VB installed and knows how to use the language.
1) What do I need give the VB programmer in terms of info about the exported functions in the DLL?
2) Can someone here download and try the DLL in a VB program? If so, go here to download the DLL (includes the C++ test program source):
http://www.paddedwall.org/john/programmer/code/d3dlltest.zip
The DLL is designed to find different versions of the racing sim I play on the PC. It does this by looking for specific registry entries. For all but maybe one other person here, the DLL should reveal that none of the sims are installed.
[EDIT]
This DLL is not a COM DLL. It is not an ActiveX DLL. It will never be either of the those. Don't bring it up. Don't suggest it. Don't argue the point, because I'm truly not the least bit interested. I will not treat suggestions along those lines with sensitivity, caring, or kind remindeers. I'm not asking for opinions, different ways to do something, or anything like that. I am asking for facts in response to the questions I posted in this message. You have been warned.
[/EDIT]
------- sig starts
"I've heard some drivers saying, 'We're going too fast here...'. If you're not here to race, go the hell home - don't come here and grumble about going too fast. Why don't you tie a kerosene rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
1) What do I need give the VB programmer in terms of info about the exported functions in the DLL?
The header file should be enough. Note that your exports will need to be in CDECL (assuming your dll is a non-ActiveX one...)
'--8<------------------------
Ex Datis:
Duncan Jones
Merrion Computing Ltd
|
|
|
|
|
The DLL is NOT an activeX(crement) DLL.
I used a def file for exports and did the following for each exported function:
VARIANT PASCAL EXPORT FunctionName()
VB doesn't use header files (that I know of) so that reference kinda confuses me.
As far as I can tell, the PASCAL macro expands out to "__stdcall".
What I need is for someone to try using the DLL from a VB program. All of the exported functions are tested in the sample app enclosed in the RAR file.
------- sig starts
"I've heard some drivers saying, 'We're going too fast here...'. If you're not here to race, go the hell home - don't come here and grumble about going too fast. Why don't you tie a kerosene rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
VB doesn't use header files (that I know of) so that reference kinda confuses me.
No - but you can convert the C++ function def from the header file into a VB import declaration.
e.g.:-
<br />
<br />
BOOL SymGetSearchPath(<br />
HANDLE hProcess,<br />
PSTR SearchPath,<br />
DWORD SearchPathLength);<br />
becomes
<br />
Public Declare Function SymGetSearchPath Lib "dbghelp.dll" ( _<br />
ByVal hProcess As Long, _<br />
ByVal SearchPath As String, _<br />
ByVal SearchPathLength As String) As Long<br />
'--8<------------------------
Ex Datis:
Duncan Jones
Merrion Computing Ltd
|
|
|
|
|
John Simmons / outlaw programmer wrote:
I've written a DLL in VC6 (C++), and I think it's going to be used by a VB programmer. Knowing this ahead of time, I return variants from all exported functions.
If you really want to make it easier for VB programmers, build a com dll instead.
|
|
|
|
|
I didn't say I was trying to make it "easier" for VB programmers - I said I wanted to make sure it could be used. I'm a C++ programmer and I'm willing to expend a little effort to ensure that VB programmers can use the DLL, but I'm not going to do it at the expense of making it more difficult to use the same DLL in a C++ program.
I don't do COM unless absolutely necessary. COM is a burden on the system, a hack on the registry, and a lot more difficult to use in C++ (my preferred programming environment).
I gave a nod to the lack of suffient intrinsic types in VB by returning variants, and that's about as far as it will probably go. Now, back to the two questions I originally asked...
1) What do I need to tell the VB programmer in terms of using the DLL?
2) Can someone here that writes VB code try the DLL for me to make sure it in fact can be used in VB?
------- sig starts
"I've heard some drivers saying, 'We're going too fast here...'. If you're not here to race, go the hell home - don't come here and grumble about going too fast. Why don't you tie a kerosene rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
John Simmons / outlaw programmer wrote:
I didn't say I was trying to make it "easier" for VB programmers - I said I wanted to make sure it could be used.
Then you don't need to do anything, I am sure it could be used in its original form.
|
|
|
|