|
I have a tree control on a dialog bar and I add some nodes into the tree bar on right clicking the tree control.
My problem is when I right click a node, the particular node is selected and immediately the selection jumps to other nodes.
It behaves very peculiarly. The right click doesnt select the actual node instead the selection jumps to other nodes.
How do i prevent this from happening.
Thanx in advance.
laiju
|
|
|
|
|
I have been working on a DLL w/ a basic CDialog. At this point, my dialog can be loaded with my testerApp and appears to work (can drag arround click buttons etc), but there appears to be something odd going on when switching to the module state.
When the my dll's CWinApp::InitInstance() is called, this is 0x101c8640. In calls to the dll's exported funcs this is 0x0012fdac (the same as my tester app). Any ideas on what I am doing wrong?
<br />
BOOL CWM_Script_DLLApp::InitInstance()<br />
{<br />
CWinApp::InitInstance();<br />
dlg = NULL;<br />
return TRUE;<br />
}<br />
<br />
extern "C" void CWM_Script_DLLApp::createDialog(void)<br />
{<br />
AFX_MANAGE_STATE(AfxGetStaticModuleState( ))<br />
if(dlg == NULL){<br />
dlg = new CTestDlg(CWnd::GetDesktopWindow(),this);
dlg->Create(CTestDlg::IDD);<br />
dlg->ShowWindow(SW_SHOW);<br />
}<br />
else{<br />
dlg->SetActiveWindow();<br />
}<br />
}<br />
<br />
void CWM_Script_DLLApp::killTestDlg(void)<br />
{<br />
dlg = NULL;<br />
}<br />
<br />
|
|
|
|
|
I'm trying to compile an app (that used to compile without problems, but recently just stopped). The errors I'm getting relate to using balloons with a tray icon. Example errors:
error C2065: 'NIIF_INFO' : undeclared identifier
error C2065: 'NIIF_ERROR' : undeclared identifier
error C2039: 'dwInfoFlags' : is not a member of '_NOTIFYICONDATAA'
C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\shellapi.h(500) : see declaration of '_NOTIFYICONDATAA'
Despite the latest platform sdk being installed on the system and the correct directories included the directories tab under options, VC++ still only wants to use the old include file. I've even tried including #define _WIN32_IE 0x501. Suggestions on how to get it to work? I hope its not something simple I've overlooked.
Thanks
modified 12-Jul-20 21:01pm.
|
|
|
|
|
Are the PSDK includes at the top of the list, so they get searched first ?
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Yeah, they're on top already.
modified 12-Jul-20 21:01pm.
|
|
|
|
|
Try adding these lines to your stdafx.h:
#define _WIN32_WINNT 0x0501
#ifndef WINVER
#define WINVER 0x0501
#endif
/ravi
My new year's resolution: 2048 x 1536
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
|
Now I get thread and other API errors in addition to the other ones. I don't get what changed, it just stopped compiling without any changes I'm aware of.
modified 12-Jul-20 21:01pm.
|
|
|
|
|
In some dynamic scenarios, I'm accustomed to calling LoadLibrary and GetProcAddress to load and call a function at runtime. However, in those cases the function pointer is defined in my code that specifies the function's signature. What if I don't know the signature?
Let's say I don't know the DLL and function name until runtime. Obviously, I can call the GetProcAddress as it simply requires a FARPROC address. However, how will I be able to call the function and pass params to it at this point?
One possibility is directly controlling the stack in code since I can't define what I want in code and have the compiler do that for me. Any ideas?
Cheers,
Tom Archer - Archer Consulting Group
"So look up ahead at times to come, despair is not for us. We have a world and more to see, while this remains behind." - James N. Rowe
|
|
|
|
|
Tom Archer wrote:
Let's say I don't know the DLL and function name until runtime. Obviously, I can call the GetProcAddress as it simply requires a FARPROC address. However, how will I be able to call the function and pass params to it at this point?
Do you know the number and types of parameters the function takes?
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"
|
|
|
|
|
The DLL name, function name and parameter and return info are all passed to me via XML elements.
Cheers,
Tom Archer - Archer Consulting Group
"So look up ahead at times to come, despair is not for us. We have a world and more to see, while this remains behind." - James N. Rowe
|
|
|
|
|
Here goes..
//define your func
typedef DWORD (__stdcall *pFunction)(DWORD, DWORD, etc etc);
pFunction MyruntimeFunc;
//call it
int execute(char * runtimelib, char *runtimefunc)
{
char *TmpPtrToRuntimeFunc,MyRuntimeLib[150] ;
strcpy(MyRuntimeLib,runtimelib);
TmpPtrToRuntimeFunc=runtimefunc;
hLib = LoadLibrary(MyRuntimeLib);
if(hLib)
{
MyruntimeFunc = (pFunction)GetProcAddress(hLib,TmpPtrToRuntimeFunc);
if(MyruntimeFunc)
{
MyruntimeFunc(Param1,param2....);
return 0;
}
}
return -1;
}
//Hope it helps
|
|
|
|
|
I think this is not exactly what he is looking for (if I understood it well). The number and types of arguments are only known at runtime thus it is not possible to use a typedef for the function...
|
|
|
|
|
If you dont know the params either, two solutions
1. as you said... manipulate the stack itself. asm required. push each param onto the stack and call the func address. get ret value from eax.
2. Run-time compilation. Check "http://www.c-sharpcorner.com/Code/2003/Feb/RuntimeCompiler.asp" for a sample.
|
|
|
|
|
munawar1968 wrote:
1. as you said... manipulate the stack itself. asm required. push each param onto the stack and call the func address. get ret value from eax.
Agreed. But this is precisely what I don't know how to do.
Cheers,
Tom Archer - Archer Consulting Group
"So look up ahead at times to come, despair is not for us. We have a world and more to see, while this remains behind." - James N. Rowe
|
|
|
|
|
Thanks for the reply, but this was precisely what I said I can't do as I don't know the fcn signature until runtime.
Cheers,
Tom Archer - Archer Consulting Group
"So look up ahead at times to come, despair is not for us. We have a world and more to see, while this remains behind." - James N. Rowe
|
|
|
|
|
Tom Archer wrote:
The DLL name, function name and parameter and return info are all passed to me via XML elements.
Can you be certain they're correct? If the parameter info is wrong, then disaster could follow. Also, are you certain of what the calling convention is (C vs pascal etc.) as this affects how you should call it.
If you're sure it's safe, then the easiest way is probably to push the parameters on the stack in the right order and then call the method directly - some assembly required. It won't be very easy because you'll have to make sure that any intermediate operations you do in between pushing parameters (such as loading the next value, checking its type etc...) don't modify the stack (or at least leave it in the same state it began in). The return value (if there is one) will always be held in the EAX register (for an 8-bit to 32-bit return value) or EDX:EAX for a 64-bit value. For structures, I believe the EAX register hold the address of the return structure, but I'm not certain.
The other option is to dynamically compile some code that does the same thing, but again you'll run into difficulties passing the parameters.
One way I've had success in passing arbitrary parameter lists in the past is to assemble a block of memory that looks like the stack should, and then allocate space on the stack and copy the memory into it just before you call the function - much easier than managing pushes at the right time.
It would be much easier if you could narrow down the types and number of parameters a bit.
Anyway, I hope that helps a bit.
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"
|
|
|
|
|
Hi Ryan,
The client is responsible for the function desc. If it sends the wrong data, then it's expected that bad things will happen. I kinda figured that inline assembler would be needed to push the params onto the stack, but that's exactly what I don't know how to do.
Cheers,
Tom Archer - Archer Consulting Group
"So look up ahead at times to come, despair is not for us. We have a world and more to see, while this remains behind." - James N. Rowe
|
|
|
|
|
Tom Archer wrote:
I kinda figured that inline assembler would be needed to push the params onto the stack, but that's exactly what I don't know how to do.
OK. I'll give a few examples. Hopefully you can extend them.
Say you've got the address of a function in a variable called funcPtr and you need to pass a float and an int and the function returned a char, then you could do something like this (assuming C style calling convention):
char callFunction(void *funcPtr, float parm1, int parm2)
{
__asm push parm1
__asm push parm2
__asm call funcPtr
}Of course this can be extended for more arguments, and it should work for doubles (64-bit values) as well. I'm not sure how it works for values less than 32 bits. I think the compiler pushes an entire zero-extended 32-bit value, so you'll need to take that into account (store smaller values in a 32-bit temporary variable first).
You should be able to put this in a loop as follows:
char callFunction(void *funcPtr, int *values, int numValues)
{
for (int i=0; i<numValues; i++)
{
__asm push values[i]
}
__asm call funcPtr
}It should work alright, but I have never had to do this, so I'm not 100% certain. If it has trouble with the array index, assign values[i] to a temporary variable first (make sure it's local to the function, not the for loop, or you'll have problems with stack corruption).
As I mentioned before, another way I've done it is to allocate a block of memory for the actual parameter contents as they would appear on the stack, and the copy it all in one go. It makes the inline assembly much easier and predictable:
char callFunction(void *funcPtr, void *stackPtr, int stackSize)
{
__asm sub esp,stackSize
__asm mov esi,stackPtr
__asm mov edi,esp
__asm mov ecx,stackSize
__asm rep movsb
__asm call funcPtr
}This version I have taken directly from some code I have written and tested, so I know it works. This is what I would recommend doing, as you can then assemble the stack information without using inline assembly (pointer arithmatic is much easier to understand  ) and just copy the data and call the function using a simple consistent method.
[edit]If you use the last technique, remember that for the C calling convention the parameters are passed in such a way that the highest address has the right-most parameter.[/edit]
Hopefully that gives you enough information to get it working.
Cheers,
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 just realised my first two examples were wrong  The parameters should be pushed in the opposite order for both of them. The third is still correct though.
Sorry about that 
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"
|
|
|
|
|
Thanks Ryan for all your help.
Cheers,
Tom Archer - Archer Consulting Group
"So look up ahead at times to come, despair is not for us. We have a world and more to see, while this remains behind." - James N. Rowe
|
|
|
|
|
hi
Check out "Smashing the Stack for fun and profit" by Aleph One. great docu for understanding stack manipulation with lots of codes snippets . http://www.phrack.org/phrack/49/P49-14.
xx
|
|
|
|
|
Brilliant stuff. Thanks!
Cheers,
Tom Archer - Archer Consulting Group
"So look up ahead at times to come, despair is not for us. We have a world and more to see, while this remains behind." - James N. Rowe
|
|
|
|
|
Well, just wild guess and I tried it just today at morning, but under some limitations you can go (probably) this way:
If you can stick with the C call convention (no pascal, at least I think), and you can specify fixed type for return parameter, you can define the function signature as follows:
typedef DWORD (__stdcall *pFunction)(...);
Then you can call it in this way:
int execute()
{
MyruntimeFunc = (pFunction)GetProcAddress( NULL,"TestFunction");
MyruntimeFunc( 1 );
return -1;
}
extern "C"
{
__declspec( dllexport ) DWORD TestFunction( DWORD ard )
{
int x = 0;
return 0;
};
}
Because TestFunction knows what to look for on the stack, she'll find it. You only have to make you sure that you'll put the correct types (very important, (BYTE)1 is here not the same as (DWORD)1 ) in correct order.
It's just a morning idea, before I finally wake up, but maybe it will help you. I tested it inside one single .exe file, so maybe some of my assumptions are bad. But at least I tried
|
|
|
|
|
Hi,
is it possible, to start an executable file as a child process? And if not, how can i get an handle on the program I've started?
thanks, Michael
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
