|
Have you seen this[^].
Regards,
Rane
|
|
|
|
|
Wow! that was really helpful. I don't think my issue was that "elongated". Anyways, I had an idea to do it myself but was looking out for a way which can save me from saving un-necessary info in xml apart from ctrl ID names.
Thanks
Cage
|
|
|
|
|
Is your link correct ? Because I'm coming to a post which is a question ("how to filter the packets enter in to our network in VC++?") and has nothing to do with the original question .
|
|
|
|
|
The link I posted earlier was an incorrect link and the correct link is here[^]
Regards,
Rane
|
|
|
|
|
The answer is up to you. We have no way of giving any solid recomendations without lots more information. As Rane implied, you are asking us for a lot of work, which you won't get...
Does the xml file describe control positions and names? You could read in the xml file, and give the first control you find ID=100, second one ID=101, and so on. Store this name->ID mapping in a (gasp) map container. When you want to look up a control by name later, look up the ID in that map.
And that's just one idea.
Iain.
|
|
|
|
|
Sorry if my query was vague. Perhaps, I deserved a "can you give more details" type reply rather than a rude "goto this URL and "
As for your idea which is more constructive than Rane's, let me give some more detail.
Ctrl IDs are autogenerated by compiler and may get over-written so I don't want to store them in the XML. What I was thinking is to store ID Names
IDC_X1 in the xml and then retrieve the ctrl ID corresponding to the string "IDC_X1".
May be it has a very simple solution which didnt click in my mind but is it "asking too much" or "getting my homework done" type question ?
Thanks
Cage
|
|
|
|
|
cagespear wrote: Ctrl IDs are autogenerated by compiler
It is generated by the resource editor, not by the compiler. It means that once your UI is done and you don't touch it anymore, you can recompile your project as many times as you like and the Ids won't be changed. Furthermore, nothing prevents you to open the resource file with a text editor and assign the Ids yourself manually (you have to take care about not assigning an existing value).
So, I think using the control Id in your xml is perfectly fine (and that's the way I would follow).
If you design your UI, adding new controls won't change the Id of existing controls (AFAIK because I never saw something like that happening).
|
|
|
|
|
Cedric Moonen wrote: you can recompile your project as many times as you like and the Ids won't be changed
I was not referring to re-compilation changing the Ids, here's my case -
My resource file has more than 30k records and there are lots of merge operations happening on RC because so many people are working on the same project everyday. A lot of times there is a clash on IDs on which a developer has to change the Ids to make them unique. That is why we were reluctant to use numeric IDs. May be there is no easy way to go about it, but we will/are trying to somehow use ID name itself and not numeric ID.
Regards
Cage
|
|
|
|
|
I'm sorry, I made a mistake: the Ids are defined in the resource.h file, not in the rc file. So, you don't even need to open it with a text editor, you can open the resource.h file directly and check the Ids or assign them yourself.
|
|
|
|
|
cagespear wrote: I have a requirement in MFC where I have a number of controls whose names are stored in the xml file.
What's the 'name of the control' ? Controls doesn't have a name, they have an Id and maybe a title. The Id is unique. I guess you are talking about the Id that you supply in the resource editor (like IDC_MYCONTROL) ? Is that what you are talking about ? If yes, then there is no way (AFAIK) to convert such a 'string' into the real Id. The thing is that these Id's are in fact simple #define that will be replaced by the preprocessor by a numerical value. Can't you use the numerical value directly ? Open your resource file with a text editor and you can directly look at the numerical values of the Ids. That is the easiest solution I think (if I understood you correctly).
|
|
|
|
|
You are right Cedric, I intended to convert "IDC_MYCONTROL" into its numeric ID equivalent. The reason - I didnt want to use numeric IDs directly was because they are generated by the compiler and may be duplicated/get changed while working on the resource file.
Thanks a ton for taking an extra effort to understand a rather vague question posted by me(I should have given exact details, my bad). I had lost all hopes after Rane gave me an answer which certainly made me feel low about the question I asked.
Thanks again!
Cage
|
|
|
|
|
As your problem becomes clearer, you might want to have a look at the following article by Anna-Jayne Metcalfe:
Resource ID Organiser Add-In for Visual C++ 5.0/6.0/.NET[^]
Updated versions are at her companies website:
http://www.riverblade.co.uk/products/resorg/downloads.html[^]
I can't believe you'd really need 30,000 IDs though. You can reuse control IDs if they're on different windows / dialog boxes. The only trouble I have with many dialogs spread across many DLLs is to make sure dialog IDs are unique. Now, if you have 30000 dialogs, start running and screaming now.
Iain.
|
|
|
|
|
When will GetUserName() Win32 API fail,other than inadequate buffer size?
The application is run by a service at startup,and occasionally the GetUserName() fails (returns false). However most of the times it gives the correct user name.
Can any shed some light on this?
|
|
|
|
|
You can call GetLastError()[^] in case of a failure to find out what went wrong.
Many are stubborn in pursuit of the path they have chosen, few in pursuit of the goal - Friedrich Nietzsche
.·´¯`·->Rajesh<-·´¯`·.
[Microsoft MVP - Visual C++]
|
|
|
|
|
I did that, but its really very hard to replicate it. I was asking for any particular scenario that might have caused the function to fail.
Any peculiar experiences regarding the function use?
Anyways Thanks.
|
|
|
|
|
No, I don't have any peculiar experience with the function. But I suggest that you log all the failures (with reasons) and that would be a good way to analyse what goes crazy.
Many are stubborn in pursuit of the path they have chosen, few in pursuit of the goal - Friedrich Nietzsche
.·´¯`·->Rajesh<-·´¯`·.
[Microsoft MVP - Visual C++]
|
|
|
|
|
It fails when computer username is set as UnknownUser
|
|
|
|
|
Whats your operating system?
|
|
|
|
|
#include <windows.h>
#include <stdio.h>
#include <detours.h>
#include
#include
#include <math.h>
#include <process.h>
#include <mmsystem.h>
#include <tlhelp32.h>
#include <vector>
#pragma comment(lib, "glu32.lib")
#pragma comment(lib, "opengl32.lib")
#pragma comment(lib, "winmm.lib")
#define Client_GLDRAWELEMENTS 0x4E5DA2
typedef void ( WINAPI *GLDRAWELEMENTS_TYPE )( GLenum iMode, GLsizei iCount, GLenum iType, const GLvoid *pvIndices );
DWORD g_dwGlDrawElements = NULL;
void WINAPI glDrawElementsHook( GLenum iMode, GLsizei iCount, GLenum iType, const GLvoid *pvIndices )
{
// Here you can filter any textures using g_pszTextureName
CAST( GLDRAWELEMENTS_TYPE, g_dwGlDrawElements )( iMode, iCount, iType, pvIndices );
}
// Redirect
bool WINAPI DllMain(HINSTANCE hDll, DWORD dwReason, PVOID pvReserved)
{
if(dwReason == DLL_PROCESS_ATTACH)
{
g_dwGlDrawElements = *( DWORD * )Client_GLDRAWELEMENTS;
*( DWORD * )Client_GLDRAWELEMENTS = PtrToUlong( glDrawElementsHook );
return true;
}
else if(dwReason == DLL_PROCESS_DETACH)
{
}
return false;
}
Here are the errors thnx if any could help me
C:\Documents and Settings\ivor\Desktop\project\main.cpp(35) : error C2065: 'CAST' : undeclared identifier
C:\Documents and Settings\ivor\Desktop\project\main.cpp(35) : error C2275: 'GLDRAWELEMENTS_TYPE' : illegal use of this type as an expression
C:\Documents and Settings\ivor\Desktop\project\main.cpp(27) : see declaration of 'GLDRAWELEMENTS_TYPE'
|
|
|
|
|
Please format your code properly using the "code block" tag and using the '<' and '>' symbols just above the emoticons. Your code is unreadable.
|
|
|
|
|
Try changing the glDrawElementsHook function as follows:
void WINAPI glDrawElementsHook( GLenum iMode, GLsizei iCount, GLenum iType, const GLvoid *pvIndices )
{
GLDRAWELEMENTS_TYPE *myFunc;
myFunc = MessageBox;
(*myFunc)(iMode, iCount, iType, pvIndices );
}
You just need to change the indicated line so it points to the correct function
Here's a trivial example:
typedef int ( WINAPI msgBoxFunc_Type )( HWND hwnd, LPCSTR, LPCSTR, UINT);
void DrawOKMB( char *title, char *text )
{
msgBoxFunc_Type *myFunc;
myFunc = MessageBox;
(*myFunc)(NULL, text, title, MB_OK);
}
|
|
|
|
|
Thnx for very good post but still i got 1 error
main.cpp
C:\Documents and Settings\ivor\Desktop\project\main.cpp(35) : error C2275: 'GLDRAWELEMENTS_TYPE' : illegal use of this type as an expression
C:\Documents and Settings\ivor\Desktop\project\main.cpp(27) : see declaration of 'GLDRAWELEMENTS_TYPE'
it should be this i dunno why the code block ignores it
includes should be stdio.h detours.h vector tlhelp32.h mmsystem.h process.h math.h
#include <windows.h>
#include <stdio.h>
#include <detours.h>
#include
#include
#include <math.h>
#include <process.h>
#include <mmsystem.h>
#include <tlhelp32.h>
#include <vector>
#pragma comment(lib, "glu32.lib")
#pragma comment(lib, "opengl32.lib")
#pragma comment(lib, "winmm.lib")
#define Client_GLDRAWELEMENTS 0x4E5DA2
typedef void ( WINAPI *GLDRAWELEMENTS_TYPE )( GLenum iMode, GLsizei iCount, GLenum iType, const GLvoid *pvIndices );
DWORD g_dwGlDrawElements = NULL;
void WINAPI glDrawElementsHook( GLenum iMode, GLsizei iCount, GLenum iType, const GLvoid *pvIndices )
{
GLDRAWELEMENTS_TYPE *CAST;
CAST( GLDRAWELEMENTS_TYPE, g_dwGlDrawElements )( iMode, iCount, iType, pvIndices );
}
bool WINAPI DllMain(HINSTANCE hDll, DWORD dwReason, PVOID pvReserved)
{
if(dwReason == DLL_PROCESS_ATTACH)
{
g_dwGlDrawElements = *( DWORD * )Client_GLDRAWELEMENTS;
*( DWORD * )Client_GLDRAWELEMENTS = PtrToUlong( glDrawElementsHook );
return true;
}
else if(dwReason == DLL_PROCESS_DETACH)
{
}
return false;
}</vector></tlhelp32.h></mmsystem.h></process.h></math.h></detours.h></stdio.h></windows.h>
|
|
|
|
|
Ahr - that thing with the #includes being cut from the post - when you're editing the post, you have to go through and replace all instances of < & > with the characters supplied when you hit the < or > buttons below the edit box. If you don't, text between < and > will be treated as an HTML block. (not just plain text)
As for the code - it's the whole CAST thing that's giving rubbish results
void WINAPI glDrawElementsHook( GLenum iMode, GLsizei iCount, GLenum iType, const GLvoid *pvIndices )
{
GLDRAWELEMENTS_TYPE *CAST;
CAST( GLDRAWELEMENTS_TYPE, g_dwGlDrawElements )( iMode, iCount, iType, pvIndices );
}
Here, like this, I believe. - Just chuck the CAST away and use the function pointer like I suggested earlier.
void WINAPI glDrawElementsHook( GLenum iMode, GLsizei iCount, GLenum iType, const GLvoid *pvIndices )
{
( g_dwGlDrawElements )( iMode, iCount, iType, pvIndices );
}
|
|
|
|
|
It says the following error if i try above
C:\Documents and Settings\ivor\Desktop\project\main.cpp(40) : error C2064: term does not evaluate to a function
void WINAPI glDrawElementsHook( GLenum iMode, GLsizei iCount, GLenum iType, const GLvoid *pvIndices )
{
( g_dwGlDrawElements )( iMode, iCount, iType, pvIndices );
}
|
|
|
|
|
Ok, please forgive me - I never really had a close look at all of the code together.
Have a look at the definition of g_dwGlDrawElements, it's defined as a DWORD?!?
I can't see all of the code in your first post because of the issue with the < and > characters, but if you'd care to post the whole lot I'll take another look at it.
I did find some code like yours, over here: http://forum.gamedeception.net/showthread.php?p=100284[^] They might be good value when it comes to looking at this problem. About 1/2 way down, somebody mentions that the code is just performing the same basic function as GetProcAddress, though their code actually overwrites pointers, etc, etc. I had immediately thought of this function when I found out your code need function pointers. It's usually a pretty neat and clean thing to do.
In any case, you can chuck a zip over at savefile.com or post the whole code here and I'll take another peek.
|
|
|
|
|