|
The third parameter to DialogBox is still NULL - DialogBox((HINSTANCE)g_hinst, MAKEINTRESOURCE(IDD_DIALOG1),NULL, InputBox_WndProc);
You need to specify the handle to the parent window here.
|
|
|
|
|
hi all,
i am DrawText on My Cdialog, i want to set color according to the Text Color of Title bar caption.
so is there any option to get the color of text of Title Bar.
i also chk the GetSysColor but no success is in hand..
thanks in advance.
|
|
|
|
|
|
i m tyring COLOR_CAPTIONTEXT and COLOR_INACTIVECAPTIONTEXT but it return some other color...
|
|
|
|
|
I just tried the same and those colours are both correct on my system.
|
|
|
|
|
oops sorry its my mistake...its done now..
modified 11-Feb-13 5:27am.
|
|
|
|
|
Hi,
Using the GetProcAdress I wanted to get the exported address of a function
When it returned zero I double checked with depends.exe to ensure the function was exported
I then went to assembly mode to see what happens and noticed that after the call statement a value was returned in the RAX register but there wasn't any code to move the RAX register value to my FARPROC data member
I then turned optimization off #pragma optimize("",off) and the same code generated "mov FARPROC,rax" am I missing some compiler to flag to make this happen without turning optimization off
Thanks
Thanks
|
|
|
|
|
It would help if you could post the code in your function and some of the generated assembly code.
|
|
|
|
|
Here it is
HMODULE hutil_module;
FARPROC hercgui_addr;
hutil_module = GetModuleHandle("HENGINE");
With #pragma optimize("",off)
hercgui_addr = GetProcAddress(hutil_module,"hercgui_proc");
000000005178D4BC lea rdx,[string "hercgui_proc" (518672B0h)]
000000005178D4C3 mov rcx,qword ptr [rsp+0E0h]
000000005178D4CB call qword ptr [__imp_GetProcAddress (5184A050h)]
000000005178D4D1 mov qword ptr [rsp+0C0h],rax
with optimization on
hercgui_addr = GetProcAddress(hutil_module,"hercgui_proc");
00000000514CD44B lea rdx,[string "hercgui_proc" (515A42B0h)]
00000000514CD452 mov rcx,rax
00000000514CD455 call qword ptr [__imp_GetProcAddress (51587050h)]
Thanks
|
|
|
|
|
Do you actually use
hercgui_addr later in the code? I find that if I'm looking at optimized assembly output that if I don't actually use the value for something, the extra processing code can get discarded. At a minimum, you can dump the value to console or screen to make sure the code remains in the optimized assembly output.
|
|
|
|
|
This is the next statement
strncpy(&herc_parm[0],&hercgui_addr,8);
I am running X64
I send thid address to child process
return_code = CreateProcess((LPCSTR) &herc_command[0], (LPCSTR) &herc_parm[0], (LPCSTR) &sa,
NULL,
TRUE,
(DWORD) NULL,
NULL,
NULL,
&si,
&pi);
Later in the child process I Create a Remote thread with the parent
snap_shot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS,0);
process32.dwSize = sizeof(PROCESSENTRY32);
return_cde = Process32First(snap_shot,&process32);
pid = GetCurrentProcessId();
while(pid != process32.th32ProcessID)
{
return_cde = Process32Next(snap_shot,&process32);
}
herc_process = process32.th32ParentProcessID;
my_herc = OpenProcess(PROCESS_ALL_ACCESS,FALSE,herc_process); if (my_herc == NULL)
errcd= GetLastError();
SECURITY_ATTRIBUTES sa;
LPVOID lparam;
DWORD threadid;
sa.nLength = sizeof(sa);
sa.lpSecurityDescriptor = NULL;
sa.bInheritHandle = TRUE;
lparam = NULL;
CreateRemoteThread(my_herc,
&sa,
NULL,
(LPTHREAD_START_ROUTINE) hercgui,
lparam,
NULL,
&threadid);
|
|
|
|
|
ForNow wrote: When it returned zero I double checked with depends.exe to ensure the function was exported
Did you actually check what error was being generated, as described in the function's documentation[^]?
|
|
|
|
|
Richard
look at what happens When I turn optimazation off and check for an error no code is generated
for the if (hercgui_addr = NULL) one wierd complier
On aonther issue my assignment at work I was able to resolve the 800A30EC I think thats it
by Doing app.GetActiveWorkBook however txt file wasn't displayed in the workbook in fact
a worksheet wasn't loaded I was under the impression that OpenText loads a worksheet as well
Thanks
hercgui_addr = GetProcAddress(hutil_module,"hercgui_proc");
00000000013FD44B lea rdx,[string "hercgui_proc" (14D42B0h)]
00000000013FD452 mov rcx,rax
00000000013FD455 call qword ptr [__imp_GetProcAddress (14B7050h)]
if (hercgui_addr = NULL)
errcd = GetLastError();
|
|
|
|
|
if (hercgui_addr = NULL)
This sets the value of hercgui_addr to NULL, so it is little wonder that the generated code does not look correct.
|
|
|
|
|
Thanks once I referenced hercgui eith "=="
the optimized version genereted the "mov hercgui,rax"
Thanks again
|
|
|
|
|
I'm just trying to understand the Microsoft specific modifier __interface.
According to the MSDN, "__interface implies the novtable __declspec modifier."
However, when I try to mock up code to try an verify this, Visual Studio 2008 still suggests the vtable pointer is present?
__interface ISample
{
bool Next();
bool Prev();
};
class CSample : public ISample
{
public:
bool Next()
{
return false;
}
bool Prev()
{
return false;
}
};
Am I misunderstanding what MSDN is trying to convey or am I just doing something wrong. In a nutshell, just trying to see if it's possible to enforce interface rules without needing the vtable overhead if only deriving from __interface declarations. I understand that this would not be portable code.
|
|
|
|
|
I have to think hard about this every time I look at this type of problem. I think the answer is that ISample is never concrete so it doesn't need a vtable. There is a vtable in CSample. When you call either of the 2 methods through a pointer (either CSample* or ISample*), the vtable needs are met by the concrete class.
--
Harvey
|
|
|
|
|
Thanks for responding. I guess my confusion is if __interface hints to the compiler that the base class will never be instantiated, even though __interface supposedly makes the methods pure virtual, I was hoping that the interface rules were being enforced at compile time and the virtualness of the base class declarations would not propagate up to the derived class, unless of course the derived class explicitly declared something virtual. I know that kinda flies in the face of the normal rules for virtual but I was hoping there was a way to get interface rules enforcement without literally applying the virtual rules unless explicit outside of the interface.
I was hoping that CSample, in this case, would be treated at runtime like it did not have a base class and did not have any virtual methods, and thus the compiler would discard the vtable for it as well.
Is the vtable really needed (in this scenario)?
|
|
|
|
|
novtable is used in case of hardcore optimizations with "abstract" base classes are never instantiated. An interface is always abstract by definition.
To understande novtable first you have to understand a bit more about how a derived class is instantiated and initialized. Let me explain this with a simple example:
A
/ \
B C
/ \
D E
The above drawing is a class hierarchy and we will examine the instantiation of the D class. Lets assume that A already has at least one virtual method so it has a vtable as well. What you have learnt about C++ is that "new D;" calls constructors A, C and D in this order. Now we delve into the implementation details and check out some interesting stuff. The simple truth is that the only thing that the compiler calls in case of "new D;" is the constructor of D. BUT every constructor starts with some auto generated stuff by the compiler that is followed by the "user defined constructor code".
Let's see some pseudo code:
constructor_D()
{
auto-generated: call constructor_C()
auto-generated: init the vtable to vtable-D
user-defined constructor code of D
}
constructor_C()
{
auto-generated: call constructor_A()
auto-generated: init the vtable to vtable-C
user-defined constructor code of C
}
constructor_A()
{
auto-generated: init the vtable to vtable-A
user-defined constructor code of A
}
So if we consider only the "user defined constructor code" then the order of constructor calls is indeed A C D, but if we look at the whole stuff then its D C A. Its obvious that initializing the vtable more than once for an instance is superfluous, in the above example its initialzed 3 times, first in A, then in C and finially in D. We need the initialization only in D because we created a D instance so we need the virtual methods for the D class. Unfortunately sometimes the compiler can not find out whether the vtable initialization in A and C are superfluous or not so it generates the vtable init code there, but you can add the novtable to class A and C as an optimization if you know that they will never be instantiated. In case of an interface we know that it will never be instantiated so an automatic novtable optimization is obvious, an interface will have at least one descendant to init the final vtable pointer.
In your example the ISample interface simply doesn't have a constructor and your CSample constructor looks like this:
constructor_CSample()
{
auto-generated: init the vtable to vtable-CSample
user-defined constructor code of CSample
}
This is why you have the vtable there.
There is a golden rule that calling a virtual function from a constructor directly or indirectly is a bad practice. Direct calls can be caught by the compiler, but indirect ones silently cause bugs and headaches. On indirect virtual function call I mean: you call a non-virtual function from the constructor and then that non-virtual function calls a virtual one. Why is this a problem? Lets say you call a virtual function from the constructor of C. When the constructor of C runs the vtable is initialized to the vtable of class C. This means that even if class D overrides the virtual function, the virtual function of C executes because we have only the vtable of C when constructor C runs!!! This causes a hard to find bug without crash!!! If you use the novtable with class C then the vtable is not initialized when constructor C runs so there are 3 possible scenarios:
1. The vtable pointer might be uninitialized because C and its base classes left it uninitialized so the virtual function call causes a crash.
2. One of the base classes of C doesn't have the novtable directive so it filled in the vtable. In this case if the vtable of this particular base class has an entry for the called virtual function then this virtual function will be executed (A), otherwise a crash occurs (B).
In my opinion a crash is always better and easier to find than unwanted behavior.
So, you can use novtable with any "abstract" class as an optimization. In case of novtable we can treat any classes "abstract" that won't be instantiated at runtime - for example we can use novtable relatively safely with a class whos constructor is has protected access modifier but care must be taken not to call a virtual function from the constructor directly or indirectly. Note that I worked on performance critical programs but I never reached a point where I started to use novtable to optimize. My humble opinion is that if your performance problems come from vtable initializations then you are doing something wrong. Performance problems are rather the consequences of algorithmic problems and cache-unfriendly memory access.
EDIT: you can't enforce interface rules with other mayor C++ compilers. Even if you define the __interface keyword to nothing with other compilers, you have to put there the virtual keyword for functions and either a dummy implementation or "= 0".
|
|
|
|
|
Thanks for taking the time for such a detailed response. It got me thinking about it some more and I believe I now understand why it's there. I was just hoping that the vtable wasn't even needed if the instantiated classes didn't explicitly declare anything virtual. I was hoping the __interface rules and requirements could all be enforced at compile time and the need for the vtable in the derived class could be discarded in my scenario.
Do you think if a true interface keyword existed in the C++ standard, that the virtualness of the interface would not be implied in the classes that "implement" the interfaces. Do "deriving from the interface" and "implementing the interface" mean the same thing?
|
|
|
|
|
"deriving from the interface" and "implementing the interface" are basically the same, the only subtle difference is that you usually say "implement" (but "derive" or "extend" are also okay) when the base class is an interface - the only exception is when both the subclass and the base class are interfaces because in this case documentations use "extend" or "derive". This because evident after reading some documentation about C# or java where there is sharp distinction between classes and interfaces, the VS __interface keyword is also something that mimics the behavior of C# interfaces.
What do you mean on "virtualness" of the class that implements the interface?
|
|
|
|
|
pasztorpisti wrote: What do you mean on "virtualness" of the class that implements the interface?
Sorry, just meaning that once declared virtual in base class, a method is virtual for all "derived" classes.
|
|
|
|
|
Excellent answer, better than mine. +5 for yours...
--
Harvey
|
|
|
|
|
|
Hi to all,
I am trying to implement Brian Gladman's AES Encryption in my program. But as i am new to Encryption, please guide which mode is good to use.
AES_RETURN aes_ecb_encrypt(const unsigned char *ibuf, unsigned char *obuf,
int len, const aes_encrypt_ctx cx[1]);
AES_RETURN aes_cbc_encrypt(const unsigned char *ibuf, unsigned char *obuf,
int len, unsigned char *iv, const aes_encrypt_ctx cx[1]);
AES_RETURN aes_mode_reset(aes_encrypt_ctx cx[1]);
AES_RETURN aes_cfb_encrypt(const unsigned char *ibuf, unsigned char *obuf,
int len, unsigned char *iv, aes_encrypt_ctx cx[1]);
#define aes_ofb_encrypt aes_ofb_crypt
AES_RETURN aes_ofb_crypt(const unsigned char *ibuf, unsigned char *obuf,
and i am confused on *iv what is this? I had to encrypt files as well as strings.  
Regards,
Vishal
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
