|
Why not just store the data in a file in the Local Settings area?
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
That would work for all the settings but one: the application path. I would need that path to get to the settings file.
|
|
|
|
|
I'm not sure I follow what you mean... 
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
on vc6 it's working; now trying to set it up in VS.net 2003 it does not work.
I have some header file external to my project ( from 3rd party vendor ).
c:\external\include\library_1\includes\<some header files>
c:\external\include\library_2\includes\<some more header files>
c:\external\include\library_3\includes\<some other header files>
...
I include all the header files in the StdAfx.h file :
#include "library_1\includes/hA.h"<br />
#include "library_1\includes/hB.h"<br />
#include "library_1\includes/hC.h"<br />
#include "library_1\includes/hD.h"<br />
#include "library_2\includes/h1.h"<br />
#include "library_2\includes/h2.h"<br />
#include "library_2\includes/h3.h"<br />
...
Header hA.h includes a header in library_2 h1.h like :
#include "h1.h"
In VC6, in the project settings, I set the path to
c:usr\local\include\,
c:usr\local\include\library_1\includes\,
c:usr\local\include\library_2\includes\
this seems to be working.
But when I import this into my vs.net 2003 project, the path are not recognized.
Any ideas where I need to set the path to library_2 and library_1 ?
I don't want to have to change the header files, but if I have to, I will do it.
Thanks.
Maximilien Lincourt
Your Head A Splode - Strong Bad
|
|
|
|
|
First off, I am brand spankin new to "The Code Project". I am writing in C++
using the API's for various things. Currently my biggest problems are as
follows:
1) I created a GUI with 4 gauges, 4 bargraphs and a chart. There
seems to be some sort of memory leakage(ie. GDI objects just keep climbing until it crashes.) I can't find the culprit. All objects are being deleted after use.
2) I am using COM ports to communicate with some machinery and I am trying to
find a way to verify which port is connected.
Any advice would be greatly appreciated.
|
|
|
|
|
Gr8Shag wrote: All objects are being deleted after use.
Well, obviously not 
It's hard to give advice without seeing any code.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Well, the code is rather large but if that is protocol, I'll paste it or
whatever I need to do.
Just post it here???
-- modified at 14:28 Monday 6th March, 2006
Well, as for the Memory leak - it appears that my partner found it. You guys
are amazing. One post and the problem is solved. 
TY
|
|
|
|
|
Gr8Shag wrote: You guys
are amazing. One post and the problem is solved
Christian has that effect on things. He eats a maple syrup covered bagel waves his magic wand and all GDI resources are cleaned up.
Chris Meech
I am Canadian. [heard in a local bar]
When I want privacy, I'll close the bathroom door. [Stan Shannon]
BAD DAY FOR: Friendly competition, as Ford Motor Co. declared the employee parking lot at its truck plant in Dearborn, Mich., off limits to vehicles built by rival companies. Workers have to drive a Ford to work, or park across the street. [CNNMoney.com]
Nice sig! [Tim Deveaux on Matt Newman's sig with a quote from me]
|
|
|
|
|
Gr8Shag wrote: 1) I created a GUI with 4 gauges, 4 bargraphs and a chart. Thereseems to be some sort of memory leakage(ie. GDI objects just keep climbing until it crashes.) I can't find the culprit. All objects are being deleted after use.
Post the code that does the drawing...
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
I created a windows timer in a CView object , a nd when I killed it in the destructor, the app would crash. When I kill it in onDestroy, it's fine. Why?
------- 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
|
|
|
|
|
By the time your destructor is called, the windows and the message pump are already gone ?
People that start writing code immediately are programmers (or hackers), people that ask questions first are Software Engineers - Graham Shanks
|
|
|
|
|
A timer is associated with a window. In a CWnd destructor, the window is already gone, so calling functions that operate on that window won't work.
--Mike--
Visual C++ MVP 
LINKS~! Ericahist | NEW!! PimpFish | CP SearchBar v3.0 | C++ Forum FAQ
|
|
|
|
|
I've seen in some programs that you put for example a number in an edit box, and imediately the result (may be in another edit box) appears. In general you do something and without pressing any buttons or anything the others change.
How is this done?
|
|
|
|
|
This is done in response to the EN_CHANGE notification.
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
By doing the processing in the message handler for the EN_CHANGE event for the CEdit object.
It's supposed to be hard, otherwise anybody could do it!
|
|
|
|
|
I just tried to include <fstream> in my program, and it throws this error.
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\fstream(465): error C2061: syntax error : identifier '_DebugHeapTag'
ENV: VC7.
VuNic
|
|
|
|
|
please show us a little piece of the code around where the compiler complains...
(around line 465 )
|
|
|
|
|
Hi all,
Since a few weeks I am playing with detour and winapi functions.
I hooked DirectDrawCreate and GetProcAdress. In the function GetProcAdress I want to return the adress of the api function "DirectDrawCreate" without detour does some 1 got the solution for this? Below the code I made so far:
<br />
<br />
DETOUR_TRAMPOLINE( HWND __stdcall zDirectDrawCreate(GUID* lpGUID , LPDIRECTDRAW* lplpDD , IUnknown* pUnkOuter) ,DirectDrawCreate );<br />
<br />
HWND __stdcall sDirectDrawCreate(GUID* lpGUID , LPDIRECTDRAW* lplpDD , IUnknown* pUnkOuter) <br />
{<br />
return zDirectDrawCreate(lpGUID , lplpDD , pUnkOuter);
}<br />
<br />
<br />
<br />
DETOUR_TRAMPOLINE(FARPROC WINAPI zGetProcAddress (HMODULE hModule, LPCSTR lp),GetProcAddress);<br />
<br />
FARPROC WINAPI sGetProcAddress (HMODULE hModule, LPCSTR lp)<br />
{<br />
if(HIWORD(lp))<br />
{<br />
<br />
<br />
if(!strcmp(lp, "GetProcAddress")) return (FARPROC) zGetProcAddress;<br />
<br />
}<br />
return zGetProcAddress(hModule, lp);<br />
}<br />
<br />
void Detour_PB_DirectDraw()<br />
{ <br />
DetourFunctionWithTrampoline((PBYTE)zDirectDrawCreate,(PBYTE)sDirectDrawCreate);<br />
}<br />
<br />
void Detour_PB_GetProcAddress()<br />
{<br />
DetourFunctionWithTrampoline((PBYTE)zGetProcAddress,(PBYTE)sGetProcAddress);<br />
}<br />
<br />
bool WINAPI DllMain(HINSTANCE hInst, DWORD dwReason, PVOID pvReserved)<br />
{<br />
if(dwReason == DLL_PROCESS_ATTACH) <br />
{<br />
<br />
Detour_PB_GetProcAddress(); <br />
Detour_PB_DirectDraw();<br />
<br />
}<br />
<br />
else if(dwReason == DLL_PROCESS_DETACH)<br />
{<br />
<br />
}<br />
<br />
return true; <br />
}<br />
|
|
|
|
|
Return the address of the trampoline. i.e.
DETOUR_TRAMPOLINE(FARPROC WINAPI zGetProcAddress (HMODULE hModule, LPCSTR lp),GetProcAddress);
FARPROC WINAPI sGetProcAddress (HMODULE hModule, LPCSTR lp)
{
if(HIWORD(lp))
{
if(!strcmp(lp, "GetProcAddress")) return (FARPROC) zGetProcAddress;
else if (!strcmp(lp, "DirectDrawCreate")) return (FARPROC)&zDirectDrawCreate;
}
return zGetProcAddress(hModule, lp);
}
If you look at the machine code for the trampoline it will consist of a few bytes from the detoured API followed by a jump. Don't let this fool you; calling it will have the same effect as the original API.
Also I think the following:
(FARPROC) zGetProcAddress
Should be:
(FARPROC)&sGetProcAddress
Steve
|
|
|
|
|
But If I am right then you retour the adress of the detoured function. I want to return the adress there of the unmodified api "DirectDrawCreate"
|
|
|
|
|
Detours works by overwriting the target function - The address of the original function is no longer the address of the original function. Detours copies the overwritten data into the trampoline and then puts in the trampoline to the original function after the overwritten code. In short calling the trampoline (as my code did) has the effect of calling the original function.
Steve
|
|
|
|
|
I know how detours works. But I want the adress of the unmodified api"DirectDrawCreate" before I hook those functions.
The question is how can I do that.
Do I have to get it with:
int DirectDrawCreate = (int)GetProcAddress(LoadLibrary("ddraw.dll"), "DirectDrawCreate");
Then read the bytes and copy them with CopyMemory()
And then hook the api's
|
|
|
|
|
Here's how I use detours:
DETOUR_TRAMPOLINE( BOOL WINAPI Tram_EnableWindow(HWND hWnd, BOOL bEnable),
EnableWindow )
BOOL WINAPI My_EnableWindow( HWND hWnd, BOOL bEnable )
{
return Tram_EnableWindow(hWnd, bEnable);
}
void ApplyDetours()
{
DetourFunctionWithTrampoline((PBYTE)Tram_EnableWindow, (PBYTE)My_EnableWindow);
}
void RemoveDetours()
{
DetourRemove((PBYTE)Tram_EnableWindow, (PBYTE)My_EnableWindow);
}
Because of the way Detours works, the address of the API before the detours is applied is the address of the modified function after it is applied - This is why it's do powerful as the hook function is called regardless of the calling mechanism (unlike IAT patching for example). The address of the original function after the detours has been applied is the address of the trampoline function. I don't know what you mean when you say, "Then read the bytes and copy them with CopyMemory()" - Detours takes care of all this for you.
Steve
|
|
|
|
|
A program that I use detects I use detours on "DirectDrawCreate" They use "GetProcAdress" to detect it. detour make jumps 0xE9 or 0x90 thats wot they see.
IAT patching sounds like a solution for this problem can you show me a example maybe ?
|
|
|
|
|
IAT patching will only work if the DLL is not dynamically loaded. Is this the case? To check you the export table of the .EXE and see if it contains the API using "Depends.exe" or some such tool.
Steve
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
