|
EVEN IF I USE _declspec(dllexport) ,it is of no use to define the exxported function with extern"C".AS THERE NO INTERFACE PROBLEM DLL EXTENSION AND APPLICATION
but it is must in DLL Regular
|
|
|
|
|
Hi, I've not found any information on this anywhere, so any ideas you can give me will be helpful.
I'm using Visual Studio .net 2003, and I have a problem.
The problem is, whenever I try to view the contents of a struct that i've allocated whilst stepping through the code, every part of it appears to be undefined, yet, when the code accesses it, and prints various bits, it works fine. It just appears to be a problem of the debugger attaching to it.
The situation is this. I have one large struct that contains sub structs. I allocate sub structs on a per required basis, initializing the memory to zero after allocating it.
My Project uses C# as a front end, and c++ with .net extensions as a DLL. The DLL isn't really c++, but is C code compiled as C++ (using the project properties), so doesn't use any classes.
It is quite a large project, with the main file running to 5,000 lines, so I don't want to undertake a conversion to C++ .net without knowing that there is nothing I can do to avoid it.
To me, it appears to be a debugger problem. Are there settings that control this sort of thing?
Any ideas?
Thanks,
Dave Smith
|
|
|
|
|
Dave J Smith wrote:
The problem is, whenever I try to view the contents of a struct that i've allocated whilst stepping through the code, every part of it appears to be undefined, yet, when the code accesses it, and prints various bits, it works fine. It just appears to be a problem of the debugger attaching to it
You must initialize the struct, preferably by using new and a constructor instead of malloc. It's not a problem, It's just C++.
|
|
|
|
|
Hi,
when I use remove("c:\test.txt") the file is deleted, but can still be found in the recycle bin.
Is there a way to delete a file permanently ?? So that it is removed but not into the recycle bin ?
THx
|
|
|
|
|
|
|
I think you must have confused yourself, because remove simply calls DeleteFile, which does not move items into the Recycle Bin.
Perhaps you have a program running which intercepts file deletions?
Stability. What an interesting concept. -- Chris Maunder
|
|
|
|
|
Some applications, like the "Windows Picture and Fax Viewer" do not allow multiple instances to be launched. In this case, if I use CreateProcess or ShellExecuteEx to launch another instance, what happens is that the existing instance receives the document (in this case a .gif file), replacing the one that was being shown before.
The problem is that, if I use ShellExecuteEx, the process handle returned is already signaled and the WaitForSingleObject does not block until the viewer is closed. If I use CreateProcess, the same thing happens with both the process and the thread handles.
The MSDN says that ShellExecuteEx may return NULL in this case, but it doesn't.
My code is as follows:
CString sType = _T(".gif");
CString sFile = _T("c:\\temp\\logo1.gif");
TCHAR pszOut[1024];
DWORD pcchOut = 1023;
HRESULT ret = AssocQueryString(ASSOCF_INIT_DEFAULTTOSTAR |ASSOCF_REMAPRUNDLL,
ASSOCSTR_COMMAND,
sType,
"open",
pszOut,
&pcchOut);
CString sCmd;
sCmd.Format("%s",pszOut);
sCmd.Replace("%1",sFile);
// Launch the viewer
STARTUPINFO si;
PROCESS_INFORMATION pi;
ZeroMemory( &si, sizeof(si) );
si.cb = sizeof(si);
ZeroMemory( &pi, sizeof(pi) );
if (CreateProcess( NULL,
sCmd.GetBuffer(),
NULL,
NULL,
FALSE,
0,
NULL,
".",
&si,
&pi ))
{
WaitForSingleObject( pi.hProcess, INFINITE );
}
CloseHandle( pi.hProcess );
CloseHandle( pi.hThread );
The first time this code executes, the "Windows Picture and Fax Viewer" is launched and the gif is displayed properly. If I leave the viewer running and try to execute the code again, but with a different .gif file, the file is replaced in the viewer but the returned handles are signaled, which means that the WaitForSingleObject returns immediately.
I've noticed, that the process returned by CreateProcess and ShellExecuteEx is always signaled if a previous instance of the viewer is running, even if it was started in the command line by the user. Therefore, the possibility of this effect being caused by me not closing handles (which I do) or doing something wrong the first time I launch the viewer, for example is not true.
The command line to launch the "Windows Picture and Fax Viewer" is something like this:
rundll32.exe c:\windows\system32\shimgvw.dll,ImageView_Fullscreen C:\temp\logo.gif
Because it runs in a dll.
Any thoughts?
Lula Capixaba
|
|
|
|
|
What's happening here is that the newly created process is detecting the existence of the existing process, sending it a message to update the display, then the new process simply exits. Because the process has exited, it is signalled. This is due to code in the program itself - there's nothing you can do about it.
Stability. What an interesting concept. -- Chris Maunder
|
|
|
|
|
Thanks, Mike.
This explains everything. But it also means that there is no safe way to wait for a process to terminate. Suppose an instance has been started manually by the user. Now, because your application does not know there is one instance of the viewer running, you try to launch one and wait for it to terminate. Just as you've described, it will return immediatelly and your application will think that the process has terminated... which is true, in some sense, but the viewer is still running with your file in it. In other words, if you are waiting for the application to terminate to free resources (deleting temporary files, for instance), you will do it prematurely.
How would you implement this?
Lula Capixaba
|
|
|
|
|
See my post about this in your other post about your ShellExecuteEx woes...
|
|
|
|
|
I'm dynamically applying transparency to a bitmap I'm displaying (i.e., I'm making the background colour transparent using a mask).
The bitmap is user-sizable and I want to highlight it 'on mouse over'. So I managed to create a region from the mask and use it to FrameRgn. This works well when I leave it 'on' permanently. However, I only want the frame to display when I'm over the non-transparent areas on the picture.
Easy, I thought, I'll use PtInRegion. However, I can't seem to get it to work - my MouseMove code never thinks a point is in the bitmap region.
Can anyone with any experience give me any pointers?
Also, does anyone know how to 'undraw' a FrameRgn? Once it is drawn, it doesn't seem to wnt to go away...
|
|
|
|
|
well i dunno anthing abt PtInRegion.....but i can give u totally new way of doing it.....but u have to do it from scratch.....
derive a class from the CStatic and subclass it by embedding the WM_MOUSEMOVE and the WM_TIMER message on to it.....
then.....draw a static control then using the wizard,assign an object say m_obj(thru ddx and linked to the class that u have just derived)and using thiz load the image on to the ststic control by using the LoadImage() ..or anyother ....
in the OnMouseMove add the following code....
if(m_showframe==FALSE)//declare a bool variable and set it to Fiale in the constructor.....
{
ModifyStyle(SS_BITMAP,SS_GRAYFRAME);
m_showframe=TRUE;
m_update=TRUE;
}
in the Ontimer()...use the following code...
CPoint p(GetMessagePos());
ScreenToClient(&p);
// Get the bounds of the control (just the client area)
GetClientRect(rect);
// Check the mouse is inside the control
if (!rect.PtInRect(p))
{
KillTimer(m_nTimerID);
m_timeronce=0;
ModifyStyle(SS_GRAYFRAME,SS_BITMAP);
m_showframe=FALSE;
m_update=TRUE;//add in a timer in ur main dialog.....to keep checking for m_update if set the timer in the main dialog should redraw
}
hope thiz idea helpz u ......
cheerz.....
"faith, hope, love remain, these three.....; but the greatest of these is love" -1 Corinthians 13:13
|
|
|
|
|
It is to ask that if somebody has any idea that how we can write a video codec and what are the basics for writing it and what should be the prior knowledge for this.
waiting for reply
|
|
|
|
|
Here is a quick question for you. I have a program which I have embedded within a program. I am basicall trying to achieve a sort of security wrapper to the second embedded program. Anyway, I can write the embedded program to disc and execute it there, then delete it when done, but I would prefer to hold it im RAM. Is there any method by which a program can be held in RAM and executed?
Any thoughts and comments would be well received.
Many thanks
|
|
|
|
|
If the second program is embedded in the first as a resource, maybe something like this will help. (NOTE: I don't really know that this is even plausible, just a concept I came up with in my head).
Anyway, how about reading all the bytes of the 2nd executable into a byte array, find out where the address is for the wndproc or initinstance function, make a function pointer member in the first executable, then set the address of the function pointer to that address in the byte array (offset from the first byte, of course), and execute it. Does that make any sense?
My articles
www.stillwaterexpress.com
BlackDice
|
|
|
|
|
Thanks for the post. I have been pondering along a similar line of thought myself. I'll give it a go later and see what occurs. Sounds like a plan though
u6ik
|
|
|
|
|
Don't even waste your time thinking about this. The loader has a huge amount more to do than merely copying bytes into memory and then calling something.
Anyway, how would you know what to call? It's certainly not WndProc or InitInstance!
The opinions expressed in this communication do not necessarily represent those of the author (especially if you find them impolite, discourteous or inflammatory).
|
|
|
|
|
Although not a trivial task, it is indeed possible. It requires knowledge of the PE file format. See here. There is Web site referrred to in one of the C++ threads but I am unable to find it right now.
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
|
|
|
|
|
If the wrapped file is already in a binary/exe format when imported into the VC++ resource hex table, then exporting that file to memory in binary form should load it to memory in the correct format ie a binary exacutable, the PE format is automatically taken care of. As long as the start of that memory location can be referenced as an exe in some way, all should run okay, shouldn't it?
V interesting links, thanks
u6ik
|
|
|
|
|
This is true for the most part. The executable file on disk is very similar to what the module will look like after Windows has loaded it.
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
|
|
|
|
|
Hi... I got a weird problem here : ). I'm made a VC++ 6 DLL (Simple Win32 DLL Project). It's a DLL that installs a system-wide hook for the keyboard. I used keyboard because it's quite easy, my final purpose is to monitor messages with WH_GETMESSAGE. Anyhow, even this doesn't work.
My main Application is a VB6 Application. I will call the DLL from there. As you know, in order for a hook to work, you have to give it an address for a callback function which the hook will call each time it catches a keyboard event or message. The trick in my DLL is that the callback ain't here. I pass to the DLL (from VB) a parameter obtained from VB with the AddressOf operator. The parameter is the address of a VB function. Practically, I`m setting up the hook in VC++, but the callback function is in VB : ). I use "AddressOfCallBackFunction" parameter below to achieve this.
#include "stdafx.h"
#include "winuser.h"
HANDLE hInstance;
HHOOK hhookHooks;
const int WH_KEYBOARD = 2;
BOOL APIENTRY DllMain( HANDLE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
hInstance = hModule;
switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
case DLL_THREAD_ATTACH:
case DLL_THREAD_DETACH:
case DLL_PROCESS_DETACH:
break;
}
return TRUE;
}
int HookSystem(int AddressOfCallBackFunction);
int UnHookSystem(int HookID);
int HookSystem(int AddressOfCallBackFunction)
{
hhookHooks = SetWindowsHookEx(WH_KEYBOARD,
(HOOKPROC) AddressOfCallBackFunction,
(HINSTANCE) hInstance,
0);
return (int)hhookHooks;
}
int UnHookSystem(int HookID)
{
int iResult = 0;
iResult = UnhookWindowsHookEx((HHOOK)HookID);
if (iResult == 0) return 0; else return 1;
}
The VB code is simple and short.
In a module I got this...
Public Declare Function HookSystem Lib "D:\Lucru\Test\ASDClock.dll" (ByVal AddressOfTheCallBackFunction As Long) As Long
Public Declare Function UnHookSystem Lib "D:\Lucru\Test\ASDClock.dll" (ByVal HookID As Long) As Long
Public Function KeyboardCallback(ByVal Code As Long, ByVal wParam As Long, ByVal lParam As Long) As Long
MsgBox Code
End Function
And in the Form I got this.
Dim test As Long
test = HookSystem(AddressOf KeyboardCallback)
Surprise surprise! When VB reaches test = HookSystem(AddressOf KeyboardCallback) guess what? Error : BAD DLL CALLING CONVENTION. However, great must be your amazement when you hear that the hook IS ACTUALLY INSTALLED. The Application crashes, I must stop it, but the hook is succesfully installed.
As I learned, the error I just wrote above occurs when there are data type inconsistencies between VB and the DLL (or wrong number of parameters). Weird, because this is not the case. Long in VB = int in C++. The number of parameters is correct too.... Passing the parameters by ByVal is also correct. So anybody know what could be the problem?? Because I sure don't know. I've been using VB for quite some time...
The .DEF file for the VC++ DLL is :
LIBRARY ASDClock
DESCRIPTION "Testing some hook."
EXPORTS
HookSystem @1
UnHookSystem @2
Hm... I'm in the dark here : ).
-= E C H Y S T T A S =-
The Greater Mind Balance
|
|
|
|
|
Hi !
No, a calling convention error is not because the parameters you pass are wrong. A calling convention describe in fact which part will clean the stack after the function has been called: the program which calls the dll or the dll itselfs. VB and C++ uses different calling conventions: for VB it is the standard calling convention (__stdcall) and for C++ it is the the C calling convention.
So, here your HookSystem and UnHookSystem functions have the C calling convention in the dll but VB calls them with it own calling convention. So, you have to change the calling convention of these functions inside your dll: just add a __stdcall :
<br />
int __stdcall HookSystem(int AddressOfCallBackFunction);<br />
int __stdcall UnHookSystem(int HookID);<br />
<br />
int __stdcall HookSystem(int AddressOfCallBackFunction)<br />
{ <br />
....<br />
}<br />
int __stdcall UnHookSystem(int HookID)<br />
{<br />
....<br />
}
You could also use APIENTRY as it is defined as __stdcall
|
|
|
|
|
Hi Cedric : ). Thanks a lot for your answer. That solved the problem!
-= E C H Y S T T A S =-
The Greater Mind Balance
|
|
|
|
|
Hi everybody,
I'm planning to write a multi platform driver in order to capture
applications on a desktop and send them to FlashComm server.
I know that I may use Camtasia, but I'm planning an open source
project and I would like to implemet my own drivers.
I have to be able to select my screen output if you click on a flash movie and go to properties. There you can select all available cameras from a dropdown menu. My goal is that my screen output can be selected here.
Anyone with solutions
Tom Lismont
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
