|
I have a class derived from CWinThread, which have a CWnd* member which would recieve message from the thread. In the class also has a socket member,it would send network message to the CWnd* member.
I use such class in a Dialog,it works well.But when the main dialog create a new child dialog and show it using DoModal() function, and I want to make the child dialog correspond to the thread message and network message. In the child dialog,I send data to somewhere,but the class does send the data when the child dialog closed. Why?
Thanks
Good Luck.
|
|
|
|
|
Why?
Perheps, because the child dialog is modal.
In the child dialog,I send data to somewhere,
Please, specify more details. What do you actualy do? How do you send?
--
=====
Arman
|
|
|
|
|
I feel like a bit of a newbie asking this, but I have never had to access elements on the main form from outside it before.
So here it is: I need to access a textbox from a cpp file .... the textbox is on the main form which is initialized in the main function ... with the usual Application::Run.
in the main cpp file:
..........................................
#include "Form1.h"
int main(array<system::string ^=""> ^args)
{
Application::Run(gcnew Form1());
Form1::textBox1->Text = "some text";
}
...........................................
This doesn't work of course, because I am referencing the header class itself, and not the form instance .... but what is the form instance ????
now ... I know I could use ...
Form1^ myForm = gcnew Form1;
myForm->ShowDialog();
except that gcnew objects cannot be declared globally, and I need to access some of the form elements from other parts of the code, not main().
So I'm stuck .... any help would be appreciated.
Thanks
Aaron
|
|
|
|
|
aaron_leese wrote: any help would be appreciated.
Try here.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Your code is 100% Managed and you must ask on the correct forum.
|
|
|
|
|
I get the following linker error:
error LNK2019: unresolved external symbol "__declspec(dllimport) public: ...
...with this code:
typedef int (MainWindow::*MainWindowPtr)(void);
CallbackWrapperSpecific<MainWindow, MainWindowPtr, int>* cbPtr = new CallbackWrapperSpecific<MainWindow, MainWindowPtr, int>(this, &MainWindow::DoWork);
I'm implementing an extended version of a functor (Link), and for some reason, I still get the linker error even though I'm exporting my symbols in the following header file:
#ifndef CALLBACKWRAPPER_H
#define CALLBACKWRAPPER_H
#ifdef _EXPORT
#define THREADAPI __declspec(dllexport)
#else
#define THREADAPI __declspec(dllimport)
#endif
template <class Type>
class THREADAPI CallbackWrapperBase
{
public:
virtual Type Execute() = 0;
};
template <class ClassPtr, class Callback, class Type>
class THREADAPI CallbackWrapperSpecific : public CallbackWrapperBase<Type>
{
public:
CallbackWrapperSpecific(ClassPtr* pClass, Callback pCallback);
Type Execute();
ClassPtr* m_classPtr;
Callback m_callbackPtr;
};
#endif
Anyone know why this still happens?
-- modified at 16:45 Monday 11th June, 2007
|
|
|
|
|
Just check to see that you have not defined the THREADAPI in your calling module too.
|
|
|
|
|
In my calling project, in Visual Studio project options, I have not included _EXPORT as part of the preprocessor defines, but in every other project, I have.
|
|
|
|
|
|
Hmm... that's probably something I should've known but have never heard of. I learn something new everyday!
Thanks.
|
|
|
|
|
I am trying to do a GetModuleHandle of another dll from my own dll and do a FreeLibrary. But its not working.
Why?
How can I make termination of another dll from my own dll work.
Rajdeep
|
|
|
|
|
rajandpayal wrote: But its not working.
What's not working, GetModuleHandle() or FreeLibrary() ? Keep in mind that calling FreeLibrary() does not affect other processes using the same DLL.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
GetModuleHandle works. FreeLibrary is not taking the dll away. The concerned dll remains loaded.
As fyi the dll from where I am calling GetModuleHandle and then FreeLibrary is NOT the one which
loaded the dll to begin with.
But this should work. Isnt it??
|
|
|
|
|
rajandpayal wrote: But this should work.
No, it shouldn't. Why would you think otherwise?
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
OK. Fine. Excuse me for being ignorant.
I want to understand this a bit more.
What is making this not to work?
|
|
|
|
|
rajandpayal wrote: What is making this not to work?
It's not designed to work that way. You're doing nothing wrong. See here for more on reference counts, address spaces, etc.
Perhaps if you explained what you're ultimately after, someone could offer an alternative solution.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
We are seeing some memory leaks in our apps which are getting difficult to track down
even with using various tools like purify, boundschecker. mem validator etc..
I was actually trying to see if just by releasing a particular (from another dll in that process) dll, it helps..
But I realize that it wont help much since memory leaks usually result from we not freeing up heap allocations... And heap is process wide..
|
|
|
|
|
rajandpayal wrote: We are seeing some memory leaks in our apps
If you have memory leaks, forcing the DLL to close will not keep the memory leaks from happening (after all, the memory has already leaked at that point). You have to find the place(s) where you're not freeing up a pointer. Running the DLL under the debugger (assuming you have the source code for the DLL) should indicate a general location where the memory leaks are occurring.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997 ----- "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Are there any functions that when given an error number returned from WSAGetLastError() and GetLastError() will return a char * to a descriptive string for that error. I am using unmanaged C++. This is what I would like to be able to do:
cout << strerror(WSAGetLastError()) << endl;
-- modified at 16:57 Monday 11th June, 2007
|
|
|
|
|
Check out FormatMessage() .
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
hdcX holds an image consisting of two colors (say black and white). You can BitBlt to hdcX as a destination. However, you cannot BitBlt *from* hdcX as a source. You cannot select a pattern (hbitmap) brush into hdcX either (although you can select a solid brush). Also, hdcX does not support floodfill.
You want to BitBlt hdcA to only the white areas of hdcX, and hdcB to only the black areas of hdcX.
How do you do it.
-- modified at 16:29 Monday 11th June, 2007
|
|
|
|
|
I don't think you can do it directly. You'll probably need at least one extra bitmap and the use of MaskBlt. Have fun
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
I have variable that stores hwnd of a particular windows. I want to retrieve path to the executable file that created this window. How can I do it? I'm not very much familiar with winapi so I think the steps are to retrieve the process that created the window and then executable path. Is there any other way to do it? what function will I need? Thanks
|
|
|
|
|
For NT 4.0+ this combination of APIs may help...
#include <psapi.h>
...
DWORD dwProcessId;
::GetWindowThreadProcessId(hwnd, &dwProcessId);
HANDLE hProcess = ::OpenProcess(PROCESS_VM_READ | PROCESS_QUERY_INFORMATION, FALSE, dwProcessId);
TCHAR szPathname[MAX_PATH];
::GetModuleFileNameEx(hProcess, NULL, szPathname, MAX_PATH * sizeof(TCHAR));
::CloseHandle(hProcess);
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
Thanks I'll try it but I will have to convert that to c# first.
After posting this I found GetWindowModuleFileName Function which takes in hwnd of the window and return the full path and file name of the module associated with the specified window handle so can it be solution?
|
|
|
|