|
I see exactly the same problem in my code.
This problem occurred when I migrated to visual studio 2008 and attempted to execute the code using a release build.
The same code does not crash in debug build in VS 2008.
Has anyone been able to figure out the cause of the problem?
Thanks
David Schumaker
|
|
|
|
|
Good day,
Were you able to fix your problem ? I'm having the same kind of problem when porting to VS2008.
Thanks.
Max.
This signature was proudly tested on animals.
|
|
|
|
|
I had the same problem when porting from VS2005 to VS2008.
I avoided it using dynamic allocation something like this:
std::vector *v;
v = new ???;
v->push_back(***)
This works in both debug and release mode ^^
|
|
|
|
|
typedef void *HANDLE;
is there a type "HANDLE" in Visual c++?
i could not find any information about this type?
Thanks
|
|
|
|
|
yes.Already there in winnt.h
|
|
|
|
|
MSDN:
HANDLE Handle to an object.
This type is declared in WinNT.h as follows:
typedef PVOID HANDLE;
Of one Essence is the human race
thus has Creation put the base
One Limb impacted is sufficient
For all Others to feel the Mace
(Saadi )
|
|
|
|
|
Hi,
Is there a possibility to create a named pipe server within an (SDI) MFC app without using threads, maybe even with MFC classes?
It would be great if I could just create a named pipe object and receive a message/notification (to my SDI client window) when a client connects.
Connecting from other clients should be blocked until the first request is finished. (So no threads and critical sections are needed).
Is there anything that can solve this?
Thank you,
Niki
|
|
|
|
|
It might be simpler to use a mailslot than a named pipe.
You can send an alert to the client with a window message - like WM_COPYDATA, then the client responds by sending the data through the mailslot.
This is about as simple as it gets in Win32.
If you want hand holding, use .NET instead.
|
|
|
|
|
Thank you, I thought about Mailslots already. But the problem is the size: I need to request data up to a 1 MB.
|
|
|
|
|
I don't see anything in the docs that say that you can't send 1 MB messages to a mailslot.
You just specify zero for the intended message size when you create the mailslot, and it then allows messages of any size.
|
|
|
|
|
|
|
|
On second thought, the absolute easiest way for you to do this is what you already mentioned:
Use the WM_COPYDATA window message.
Yes it requires you to create and manage a window for purposes of receiving the message, but it just doesn't get any easier.
|
|
|
|
|
WM_COPYDATA...hmm, the first problem is within my (ATL) DLL where I hav no MFC. I created a window and a handling routine with plain Win32. First problem: I have a completely different scope and control flow inside my WndProc. I can't get an easy way to access my (ATL) object within my WndProc. Global variables are very ugly too.
Second problem: I tried it but it does not work. This is what I've done:
In my IInternetProtocol Start routine, I create a WindowClass and create a dummy window with CreateWindow. After that, there is the normal event loop.
Inside my WndProc, I use WM_CREATE to find the window of my MFC app and send WM_COPYDATA as a request.
This request is processed successfully by my MFC app; and now I immideatly send back an answer to the dummy window with WM_COPYDATA again.
But now I have a strange endless loop: There are tons of requests to my MFC app now. When I do not send back a WM_COPYDATA to the DLLs dummy window I get only one request.
But anyway, I think this technique is very slow (too slow) and not very robust, isn't it?
A third thought: What about sockets? Is there an MFC abstraction that works as mentioned?
Regards,
Niki
|
|
|
|
|
nobaq wrote: What about sockets? Is there an MFC abstraction that works as mentioned?
CAsyncSocket uses window messages for socket notifications by default, so I'd say yes.
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
nobaq wrote: Second problem: I tried it but it does not work.
If it doesn't work, then there is something wrong in your implementation. Post the code and we can take a look.
|
|
|
|
|
|
I am trying to create a C++ dll using Visual Studio 2008 and am running into many dead ends. I've created a project using the template for a dll and can't figure out where to put my code. It's all giberish. I've also searched the net and the Code Project for an example and can't find one. Can anyone direct me to an example project which creates a simple dll?
|
|
|
|
|
Actually the template does a good job, showing how to export some symbols. What are your doubts about?
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]
|
|
|
|
|
I can't figure out where to put my code.
|
|
|
|
|
A DLL is just a (dynamically loaded) code library. For instance a C -like DLL (like Win32 DLL s) is just a collection of exported functions. It may contain as well internal (i.e. not exported) functions and variables (usually is not advisable to export variables, there are, of course, exceptions).
Hence you've just to write useful exported functions (you may need also to put some initialization code inside DLLMain ).
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]
|
|
|
|
|
Hello,
I'm writing on a database application where the data is stored as HTML code (incl. images, JavaScripts and StyleSheets) in an SQlite database. The data is displayed in an MFC application with CHtmlView.
I can't use dynamic document writing via OnBeforeNavigate2 because I need my images and scripts to be stored in the database too. So I have written a very simple "Asynchronous Pluggable Protocol" for this. I need to register this handler (a DLL) globally with regsvr32.
But now I do not want to split my application logic into the exe and the DLL; instead, I want the whole application logic to reside in the MFC exe. Including the load procedure for a specific HTML page/images from the database.
So my idea is: In my app, I navigate with CHtmlView to myapp://<pageid>. Then my protocol handler is called. This DLL now requests the actual data from the running MFC application. The MFC app in turn loads the specific data from the SQLite database and passes the data back to the DLL.
The big question now is: What is the simplest method (IPC) to request data (up to a few MB) from a running application?
A great thing would be if the DLL could just call a defined function from the running exe like:
void getContent(int pageID, char *buffer, int *len);
or better:
void GetContent(char *url, char *buffer, int *len);
But I guess this is not easy. So I rely in IPC. But IPC is a very complex topic; I have no experience with it in Windows. Additionally, synchronization is a complicated issue too.
How would you solve this problem?
Is there a simple method that fits to my description?
WM_COPYDATA would be possible but unfortunately the Pluggable Protocol does not have a message queue. And I also need to pass the URL to the application when requesting a specified content.
Thank you for any hints!
Niki
|
|
|
|
|
How about using sockets or pipes?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
|
|
|
|
|
Hi,
The main problem is that I have no experience with these. But at first glance they seem to be too complicated.
I need no Networking support, it should just go fast & simple. Sockets are really oversized for that.
Problem with shared memory: I need complex caching structures and synchronization.
I would seek for an IPC method that works very simple like a remote-process function call and which is blocking: I request something in my MFC app and get the answer directly; the DLL should be blocking while this process is done.
I have experimented with WM_COPYDATA. But here I need to create a dummy window inside my DLL, send WM_COPYDATA to my MFC app to request the data and in turn send another WM_COPYDATA back to the DLL with the actual data. Too much complexity and oversize I also need to copy the data a few times.
Named Pipes: I do not know them exactly but is this really simple for my case? How do I manage the server part in my MFC app? Do I need a separate thread for this? Does this work when there are requests done simultanely?
Niki
|
|
|
|