|
Thanks for the reply. Im getting and error with these...
typedef bool (*Type_InitMotoBee)();
typedef bool (*Type_SetMotors)(int on1, int speed1, int on2, int speed2, int on3, int speed3, int on4, int speed4, int servo);
typedef void (*Type_Digital_IO)(int *inputs, int outputs);
HINSTANCE MHtbDLL=LoadLibrary(_T("mtb.dll"));
Type_InitMotoBee InitMotoBee;
Type_SetMotors SetMotors;
Type_Digital_IO Digital_IO;
InitMotoBee = (Type_InitMotoBee)GetProcAddress(MHtbDLL, "InitMotoBee");
SetMotors = (Type_SetMotors)GetProcAddress(MHtbDLL, "SetMotors");
Digital_IO = (Type_Digital_IO)GetProcAddress(MHtbDLL, "Digital_IO");
This is where the program calls the DLL, makes pointers, etc.
After I use SetMotors(); so many times, the program is terminated for an access violation... I cant figure it out. If i comment out everything that envolves the DLL, my program works perfectly.
Thanks,
David
|
|
|
|
|
Check for any uninitialized or dangling pointers inside SetMotors.
Check if there is any difference in behavior in Debug and Release builds.
Also set the warning level to the highest level in the project properties.
«_Superman_»
I love work. It gives me something to do between weekends.
|
|
|
|
|
How exactly would i Check for dangling pointers in SetMotors? If its any help, I can tell you that When i run the app in 32bit windows xp OS, the app closes after two successful SetMotors(); commands. In 64bit windows vista OS desktop, the app runs well for quite a while before closing for the same reason. I'm checking for release/debug differences now.
|
|
|
|
|
Are you allocating memory dynamically?
If so, check if they are being released properly.
Also, check for buffer overflows.
If you're using string functions, use the secure version that end with _s.
«_Superman_»
I love work. It gives me something to do between weekends.
|
|
|
|
|
Sorry, I'm new at including DLL's. I have seen "Buffer Overflow" show up as an error, but from what i can tell I fixed that. I'm pretty sure that when that occured, the compiler (Visual Studio 2008) failed to compile the app and gave me the buffer overflow error. that is no longer the case. I am not allocating memory dynamically for the DLL. there is no difference between Release and Debug. It is handling itself after I call the DLL, make the pointers, and GetProcAddress. I just use the functions...
the functions are used as follows:
SetMotors(x,x,x,x,x,x,x,x,x)
InitMotoBee();
|
|
|
|
|
It seems that the access violation is due to Dangling pointers. These kind of error will not be repeatable 100% ,since will be depending on size of your RAM ( when your OS tries to get back the memory which is assigned to some one else).If you have Dev-Partner with your studio , you can find the code problems or try to make sure that there is delete() for every new().You can use run time checker for this task , It's evaluation version may help you in Finding leaks.
It's not enough to be the best, when you have capability to be great....
|
|
|
|
|
I want to hook keboard events of an application, and that hook is associated with a ThreadID - NOT global hook. So I put the KeyboardProc() , and the InstallKeyboardHook() functions, BOTH in a DLL.
In the DllMain() function, I call to install the hook like this:
KeyboardProc()
{
//something
}
InstallKeyboardHook()
{
//something
}
BOOL APIENTRY DllMain( HMODULE hModule,
DWORD dwReason,
LPVOID lpReserved
)
{
switch (dwReason)
{
case DLL_PROCESS_ATTACH:
InstallKeyboardHook();
break;
case DLL_PROCESS_DETACH:
UnhookWindowsHookEx(hHook);
break;
}
return TRUE;
}
The DLL is loaded by the desired hook application.
It's loaded, the SetWindowsHookEx() success, but nothing happen when i press some key in the application main window.
So why ? and is it wrong when i put the install code and hook proc both in the same DLL for self install ?
Thanks very much!
|
|
|
|
|
Ensure that the thread id belongs to the same process.
How are you getting the thread id?
Some hooks can only be global.
If you're installing the low level keyboard hook, it can only be global.
Look at the remarks section of the SetWindowsHookEx[^] function.
«_Superman_»
I love work. It gives me something to do between weekends.
|
|
|
|
|
I'm using keyboard hook, not the low level version.
And I find out the thread ID by the tool help functions, like this:
dwPID=GetCurrentProcessId();
hSnapshot=CreateToolhelp32Snapshot(TH32CS_SNAPTHREAD,0);
te32.dwSize=sizeof(THREADENTRY32);
bResult=Thread32First(hSnapshot,&te32);
while((te32.th32OwnerProcessID!=dwPID)&&bResult)
{
te32.dwSize=sizeof(THREADENTRY32);
bResult=Thread32Next(hSnapshot,&te32);
}
But it didn't work ! 
|
|
|
|
|
Why don't you use GetCurrentThreadId[^] to get the current thread id.
I would recommend you put the hooking code into the application directly and get it working before writing it as part of the DLL.
«_Superman_»
I love work. It gives me something to do between weekends.
|
|
|
|
|
I want to hook the main thread of the application. But I'm not sure that call GetCurrentThreadID() in the context of a DLL will get me the desired thread.
In fact I tried that API, but the result is still the same.
Thank you!
|
|
|
|
|
Hi, I wrote an ActiveX in Visual Basic 6 that have a form with the purpose to act like a pop-up menu and to be used with any language. The form contains a WebBrowser. I have two situations:
1. When the form is shown in a modal way it works fine in both VB and VC++;
2. When the form is shown in a non modal way it only works in VB, the VC++ test app doesn't show the form and when the test app is closed the error message appears: "The instruction at 0x43dd085d referenced the memory at 0x00000138. The memory cannot be read" (translated from brazilian portuguese). A form with no WebBrowser doesn't crash, but doesn't show the form anyway!
The objective is make the form appears like a pop-up menu, so the modal way of showing the form forces the user to select an option or close the form like closing a window, pressing the close button, doens't allowing a click outside the activex form.
How can it works in a non modal way to any language?
Thanks, best regards!
modified on Tuesday, June 30, 2009 3:24 PM
|
|
|
|
|
Hi,
May i know why we need to use only 72 in the below function
lfHeight = -MulDiv(PointSize, GetDeviceCaps(hDC, LOGPIXELSY), 72);
I had a look in msdn where it was not explained...
|
|
|
|
|
one point = 1/72 of an inch
|
|
|
|
|
if u don"t mind can u be a little more clear...
|
|
|
|
|
GetDeviceCaps(hDC, LOGPIXELSY) gives you the number of pixels per inch for the device. (pixels/inch)
there are 72 points in an inch. (points/inch)
the other variable is points.
so (points * (pixels / inch)) / (points / inch) = pixels = height of text.
|
|
|
|
|
Are you asking What is a point?[^] Usually we express the size of the font in points. See the link.
-Sarath.
"Great hopes make everything great possible" - Benjamin Franklin
|
|
|
|
|
kumar sanghvi wrote: if u don"t mind can u be a little more clear...
Point (typography)[^]
Best Wishes,
-David Delaune
|
|
|
|
|
I created a Deployment applicaton via the Wizard to deplay my Visual Studio 2005 .Net application. The application uses several ActiveX controls. I have included them and registered them in the target PC.
However when I run the application having installed it on the target PC the hour-glass is visable for a few seonds then reverts back the the default cursor.
Are they any way of finding out the reason for this - I am toally blind to the problem. I did try and run from a DOS window, but still nothing.
On the deveopment PC the Installer works OK.
Regards,
Andy.
grahamfff
|
|
|
|
|
Grahamfff wrote: However when I run the application having installed it on the target PC the hour-glass is visable for a few seonds then reverts back the the default cursor.
I had very similar issues when I was testing a dialog based application which was using ActiveX controls that were not registered on the target platform. Are you absolutely sure that all your ActiveX controls are registered properly in the target system ?
|
|
|
|
|
Hi
I made some modification to MDI Application. The View's "OnDraw" will never be called.
How can I fix it?
Best regards,
|
|
|
|
|
Two wild guesses:
1. Invalidate () is never called, so no message to redraw the view is sent.
2. OnDraw () is being overridden by a derived class.
Showing the modifications you made might help with diagnosing the problem.
|
|
|
|
|
Besides. CView::OnDraw() is called by OnPaint() as a result of WM_PAINT message for screen painting in addition to OnPrint() for printing. You should be beware of this if you've done modification to WM_PAINT handler, too.
Standard paint routine is below.
void CView::OnPaint()
{
CPaintDC dc(this);
OnPrepareDC(&dc);
OnDraw(&dc);
}
|
|
|
|
|
I did not modify OnPaitn().
Best,
|
|
|
|
|
OnDraw() won't be called also for some view classes which require special drawing (like CFormView, CHtmlView, CCtrlView) although they are descendant of CView.
You need to give more info, as Alan said also.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
