|
Here is a quick and dirty hack at it. Hopefully, this can handle date of any size. I have done no testing of it but it might work.
char *HexDisplayValue( char *buffer, void *value, size_t bytecount )
{
char *pbuf = buffer;
BYTE *chval = (BYTE *)value;
for( size_t index = 0; index < bytecount; ++index, ++chval )
pbuf += sprintf( pbuf, "%02X", *chval );
return buffer;
}
The Ten Commandments For C Programmers
|
|
|
|
|
Hmmm, I dunno. %X expects a 4-byte unsigned int, but you're passing a single-byte unsigned char. Perhaps you need to cast it:
char *HexDisplayValue( char *buffer, void *value, size_t bytecount )
{
char *pbuf = buffer;
BYTE *chval = (BYTE *)value;
for( size_t index = 0; index < bytecount; ++index, ++chval )
pbuf += sprintf( pbuf, "%02X", (unsigned int)(*chval) );
return buffer;
}
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"
|
|
|
|
|
sprintf is an varargs function - things <4 byte will be extended to 4 bytes (and floats to double) by the caller.
"Der Geist des Kriegers ist erwacht / Ich hab die Macht" StS
sighist | Agile Programming | doxygen
|
|
|
|
|
peterchen wrote:
sprintf is an varargs function - things <4 byte will be extended to 4 bytes (and floats to double) by the caller.
Really? I've never read that anywhere.
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"
|
|
|
|
|
|
Right, thanks
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"
|
|
|
|
|
|
Are you looking for the internal representation (Rick's post would give you that), or the "mathematically correct" reporesentation?
"Der Geist des Kriegers ist erwacht / Ich hab die Macht" StS
sighist | Agile Programming | doxygen
|
|
|
|
|
Mathetically correct..
I need the integer part of a "double" data,
though the integer part might not be 4-bit aligned..
|
|
|
|
|
If an __int64 is not enough, thigns get a bit tricky:
Use modf() to separate the whole part, then use frexp() to split the value into mantissa m and exponent n, so that value = m * 2n. The rest is left as an excercise
(there's some heave point shifting involved here, but I have no better idea)
"Der Geist des Kriegers ist erwacht / Ich hab die Macht" StS
sighist | Agile Programming | doxygen
|
|
|
|
|
Hello all
I'm developing a small utility using MFC Dialogs. For this Utility I'm providing a setup option which will unable the user to customize the utility. But the problem I'm facing once the setup properties are set and If the utility is closed down,It looses all it's state. The user again has to provide the properties when want's to use the utility. Can any one help me in this. Please provide me with some example code for persisting object properties like checkboxes, radio buttons etc.
thanks for your help
Hari.
|
|
|
|
|
You can store information to the registry. There are plenty of tutorials around on how to do this. Basically, you need to use GetProfileInt()/SetProfileInt() or WriteProfileString()/WriteProfileString() in your application class, eg.
AfxGetApp()->WriteProfileInt(_T("MyRegistryKey"), _T("MyRegistryValue"), m_MyIntValue) Hope this helps,
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"
|
|
|
|
|
Isn't it better in new application to use registry functions like RegOpenKey , and all these ? I was pretty sure GetProfileInt and so on are now stated as obsolete in the MSDN ? (I must admit that the latter are far more easy to use than the former ...)
~RaGE();
|
|
|
|
|
I think you're getting a little confused
GetProfileInt() etc. are members of the CWinApp class and internally use RegOpenKey() etc. to do the dirty work as long as you call CWinApp::SetRegistryKey() .
The functions you're thinking of are GetPrivateProfileInt() etc. and are, as you pointed out, obsolete
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"
|
|
|
|
|
Hey guys. I just have to say, I love this site.
Hopefully someone can help me. I have a shell context menu extension using ATL in VC++. With it, I can select some Mp3's and choose my context menu item and it renames them to the way I want. Sometimes this is a lengthy process due to id3 tag renaming, so I'd like to display a progress bar. Can anyone suggest how to do this? I'm not familiar at all with windows and dialog boxes in c++, so a lot of detail would help. Thanks
|
|
|
|
|
Could someone please explain to me how design-time license works. I have been doing a lot of research on the net regarding this, but am not satisfied with what I have found. There is an article on this website that talks about it briefly.
http://www.codeproject.com/useritems/msflexgrid_in_cop_ctrl.asp?target=design%7Ctime%7Cruntime%7Clicense#xx460936xx
Only this article the guy registers a license for his control in the code itself, but where did he get the license key?
I would like to use mschart.ocx, but when I try to instantiate it in the code it says that I require a design-time license. Now currently I have office97 on my machine and so I did not have mschart.ocx. I downloaded it off the net and stuck it my my system32 directory and registered the ocx.
Here is a question, lets say that at somepoint I do get the so called design-time license for mschart.ocx. Will I be able to use it since I am only running office97? or do I require office xp installed on my macine in order to use it?
As you can see there is a lot I don't know. PLease help enlighten me.
Thank you.
Sincerely,
Mardigin
|
|
|
|
|
Oops The link I meant to paste is:
http://www.codeproject.com/useritems/MSFlexGrid_In_Cop_Ctrl.asp
Sorry about that.
Mardigin
|
|
|
|
|
Okay, I used the license key requestor to try and discover the license key for mschart.ocx
This app can be downloaded at http://support.microsoft.com/default.aspx?scid=kb;en-us;Q151771
However it says that mschart.ocx does not have a license.
This is basically what I wish to do. I wish to embed an excel spreadsheet and chart into an application build using MFC. I wish my users to only require office 97 at best installed. Is this a possability? Are there ActiveX controls compatible for excel97 spreadsheet and chart?
Mardigin
|
|
|
|
|
Hi, all
How do you “point” a function pointer to an array of byte code? I have converted a series of assembly instructions to byte codes (I don’t want to use inline assembly), and want my function pointer to point to that array of byte codes. The problem is that the VC++ compiler won’t cast from chars to the defined function pointer. The following code might explain better:
<br />
int (* FuncPtr)(int x, int y);
char ByteCode[] = {...};
<br />
FuncPtr = ByteCode;
The problem is that VC++ won’t covert from char array to the function definition. I tried adding “(void *)” when pointing but it still wouldn’t convert.
|
|
|
|
|
It seems I was logged out when I posted this...
Anyhow can anyone help me
Aidman » over and out
|
|
|
|
|
I have done this in the past and it has worked very well. As previously noted, it is very risky.
In my case, I used this technique to invoke bits of machine code generated at run time by compiling a script language on the fly.
BYTE CodeBuf[] = { ... };
typedef int (*CodeFunc)();
CodeFunc func = (CodeFunc)CodeBuf;
int returnvalue = (*func)( arg1, arg2 );
The Ten Commandments For C Programmers
|
|
|
|
|
Thanks, but why is it risky?
Aidman » over and out
|
|
|
|
|
Anonymous wrote:
The problem is that the VC++ compiler won’t cast from chars to the defined function pointer
I'm not surprised. This is an extremely dangerous thing to do, and should be avoided if at all possible. Is there any reason why you don't want to use inline assembly? You do realise that you can write a function as a separate assembly language file and link it with the rest of the program, don't you?
If you have to do this (and I strongly recommend that you don't), then you have to cast to the exact type.
typedef int (*FUNCPTR)(int, int);
FUNCPTR FuncPtr;
char ByteCode[] = {...};
FuncPtr = (FUNCPTR)ByteCode; although, I'm not sure if the compiler will let you do this. It may simply not want to cast a non-function pointer to a function-pointer, and I don't blame it
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"
|
|
|
|
|
Ok thanks
Ryan Binns wrote:
This is an extremely dangerous thing to do, and should be avoided if at all possible
Why is it dangerous and should be avoided? What can go wrong? Becouse the only diffrens I can see is that you have a function in your data memory area instead of the code area.
What else am I missing?
Aidman » over and out
|
|
|
|
|
Aidman wrote:
Why is it dangerous and should be avoided? What can go wrong? Becouse the only diffrens I can see is that you have a function in your data memory area instead of the code area.
What else am I missing?
I think a couple of things were pointed out below. But there are a few problems:
1. The Visual C++ compiler uses certain registers that it expects to be preserved between function calls. If they're not preserved, then errors can be introduced into the program.
2. By default, the data memory area can be read/written, but can not be executed from. You have to change the access permissions of the data area so that it can be executed from. This is done by Windows to prevent malicious programs from compiling code in memory (to bypass virus scanners) and then executing it.
3. If you use the wrong calling convention, the stack can be corrupted and when the function returns, the program may start executing at the wrong place, causing access violations, and possibly crashing the computer.
4. If you accidentally overwrite this array with other data, then the code will obviously become corrupted and will cause problems if you then execute it as a function. The code memory space is protected from this by Windows, again using access permissions (which can be changed, btw).
5. What if somebody hacks your program after it's loaded and changes the data in this array? This is a big security hole. The code memory is protected from writing by Windows (as I said above), but the data memory is not.
Basically, if you know exactly what you're doing, then it's no more dangerous than any other code, as long as you seriously think about what can go wrong. If you're not sure exactly how things are handled, then I'd recommend doing it another way. If it's static code, then either use the inline assembler or a separate assembly language file, and let the compiler sort everything out. If the code is dynamically compiled by your program, then consider compiling it to a DLL and loading it with LoadLibrary() (a bit more difficult, but a lot safer). In general, executing code from data memory is not a good idea because of the security concerns and possibility of data corruption.
Hope this explains things better
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"
|
|
|
|