|
I did this.
BOOL CFieldPane::OnShowControlBarMenu(CPoint point)
{
return FALSE;
}
.. and the context menu doesn't appear anymore. Thanks David
|
|
|
|
|
I simply overrode CDockablePane::OnContextMenu(CWnd* /*pWnd*/, CPoint /*point*/) to have the function do nothing and just return. Now when I right-click, the only context menu I see is the one from my CDialog window that I have embedded into my CDockablePane window. Before I did this, the CDockablePane context menu would pop up immediately after I selected an item from my CDialog window's context menu.
|
|
|
|
|
Hello folks, I'm encountering a problem. Doing message-passing, I'm sending/receiving buffers from various/mixed architectured machines (32 and 64 bits). I first tried to use this as a buffer skeleton :
typedef struct{
int nCount;
short nMode;
sHue sColor;
char* pTest;
char aData[10];
}sStack,*psStack;
On a 32 bits platform, if aData is grown to 12, it fits the whole struct size (12 bytes from offset 20 = 32), thus growing it to 13 push the struct's end to 36 (4 bytes alignment).
However I *NEED* the struct to be exactly the same size, whenever this code runs on a 32 bits machine or, you might have guessed it, a 64 bits one. So I tried :
#pragma pack(8)
typedef struct{
[...]. }sStack,*psStack;
#pragma pack()
Yet it just doesn't works like expected on a 32 bits build. The struct's size is still 32 bytes, whereas I expected at least 36 (pTest pointer using 8 bytes, thus aData lying at offset 24, hence growing the struct to 34 bytes, aligned to 36 bytes).
stdcall or cdecl calls should remains set to 32 or 64 bits accordingly to the native platform, that means a ((psStack)buff)->pTest instruction shouldn't need to be casted for suiting 32 or 64 bits build. I just need the pointers in struct to be casted to the size of an __int64 (with the needed 4 padding bytes) !
Any luck someone to have a hint, a trick, or just the full answer ? Thanks anyway...
Kochise
In Code we trust !
|
|
|
|
|
Reading elsewhere, seems there is a 'dirty tricky trick' that might do the job (unless verified more thoroughfully) :
typedef struct{
int nCount;
short nMode;
sHue sColor;
char* pTest;
__declspec( align(8))
char aData[10];
}sStack,*psStack;
Do you understand that ? However that doesn't works in every compiler, I need something more portable, such like a WORKING #pragma pack option...
Kochise
In Code we trust !
modified on Friday, July 17, 2009 7:32 AM
|
|
|
|
|
Hi Kochise,
The 32 bit pointer is 4 bytes and the 64 bit pointer is 8 bytes. Why not store the pTest pointer in a 64 bit integer?
typedef struct
{
int nCount;
short nMode;
sHue sColor;
__int64 pTest;
char aData[10];
} sStack,*psStack;
This will be 40 bytes on both 32 and 64 bit platforms.
Best Wishes,
-David Delaune
|
|
|
|
|
This is the sort of case where I really wish C++ had Ada record representation clauses[^].
Anyway - I suspect #pragma pack(8) doesn't do what you think. Specifically, the docs[^] say:
Specifies the value, in bytes, to be used for packing. The default value for n is 8. Valid values are 1, 2, 4, 8, and 16. The alignment of a member will be on a boundary that is either a multiple of n or a multiple of the size of the member, whichever is smaller.
As a monitor (as opposed to a solution ), I'd suggest using a static assert (either Microsoft[^] or Boost[^] or it's easy to build your own[^]) to verify that you and the compiler agree what the size of the structure is...
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Yeah, the root of the problem is that I'm currently writing a generic linked-in driver for Erlang that should adapt to any kind of platform, be it 32 or 64 bits. Imagine the client side to be 64 and the server side to be 32 bits, of course the pointers provided in the structs can only be used locally, yet if the server needs a data chunk from the client side, it just have to request it using its handle (the pointer). That's why both side MUST have the same struct layout, so that the 32 bits server could catch up the valid 64 bits pointer from the raw piece of data extracted from the up-coming message, then send it back in a 'hands-up and gimme your memory' kinda request (handshake).
I imagine it would be kind to pack the whole struct in a #pragma pack(1) fashion for message-passing, yet rendering it useless for run-time usage due to alignment fault that could arise. And packing/unpacking structs while they are sent/read is NOT the solution, the best would be to get them correctly shaped from the very beginning, the extra (wasteful) padding bytes included :/ Problems arises as the size but also the alignment of data change between a 32 and 64 bits architechture, what makes things a bit over complicated to my taste : http://docs.hp.com/en/5966-9844/ch03s02.html
I would like to avoid requiring the use of an extra library, because one might lead to require another one, leading to a complete mess. I'm a macro freak, and if some well defined macros do the job, I'm pretty for that kind of solution.
Kochise
In Code we trust !
modified on Friday, July 17, 2009 11:50 AM
|
|
|
|
|
Kochise wrote: I imagine it would be kind to pack the whole struct in a #pragma pack(1) fashion for message-passing, yet rendering it useless for run-time usage due to alignment fault that could arise
IIRC, x86 doesn't actually care about alignment - it's more for performance issues. Certainly this little program runs on x86 and x64, using non-word alignment:
int main()
{
char x[] = {1,2,3,4,5,6,7,8};
int* pp = (int*)(x+1);
std::cout << std::hex << (*pp) << std::endl;
}
Alternatively - here's another thought - bit-fields:
typedef struct{
int nCount : 32;
int nMode : 16;
int sColor : 8;
int pTest : 32;
int aData0_3 : 32;
int aData4_7 : 32;
int aData8_9 : 16;
}sStack,*psStack;
The array's been reconfigured slightly, but you could work around that.
Another option - serialize the struct to a byte-stream when sending, deserialize on the way back.
sStack Deserialize(BYTE* pBuffer, size_t nBytes)
{
_ASSERTE(nBytes >= 4 + 2 + 1 + 8 + 4 + 10);
sStack s;
s.nCount = *(int*)pBuffer;
return s;
}
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
When sending data between systems you will have two concerns:
1. endianness
2. structure packing
We'll assume endianness isn't an issue, or is already handled.
The only use for passing a pointer to a system is for the receiver to use it as an opaque handle to pass back to the sender at a later time.
As such, Randor gave the correct solution.
I would just add that you can make it more code friendly by using an anonymous union:
#pragma pack(push, 8)
typedef struct{
int nCount;
short nMode;
sHue sColor;
union {
char* pTest;
__int64 hTest;
};
char aData[10];
} sStack,*psStack;
#pragma pack(pop)
Also, always specify the packing for these types of structures.
...cmk
The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack
|
|
|
|
|
Yeah, I'm slownly working toward a solution to the problem, yet some stuff should still find an issue :
1- #pragma pack(8) align on a 8-byte boundary members of size >= 8, it doesn't add padding byte (what is in fact not a problem)
2- #pragma pack(1) align on a 1-byte boundary every members, nice for sending/receiving the struct as a frame. However that show the problem of software alignment fault on FPU members (float, double) and members whose size is greater than the current architechture word
3- #pragma pack(2) might lift up the problem upon most cases, but FPU members still get troubles
4- anonymous union is a nice stuff, yet I not always own the headers. Understand I work with compiled third party libraries and their header file. I work with struct coming out from these header files, and while I need the native format to deal with the library, I'd like to use the struct definition as a skeleton for my message's declaration as well. I 'just' need to enforce that the format of my message will be both 32 and 64 bit compatible (best is packing on 2 with 64 bits pointer).
#include <<foreign_lib.h>>
int test_struct(foreign_struct* frame)
{
#pragma pack(2)
struct foreign_struct sFrame;
#pragma pack()
if(send_frame(frame, sizeof(foreign_struct))
== send_frame(&sFrame, sizeof(sFrame)))
return (int) TRUE;
else
return (int) FALSE;
}
int main(int argc, char *argv[])
{
return test_struct(get_struct());
}
But thanks for you offer, good stuff to know !
Kochise
In Code we trust !
|
|
|
|
|
For your case, you will have to create your own copy of the struct that uses a format similar to that Randor or I suggested. There is no way you can fix this by packing.
The struct contains a pointer; a 32bit system will see this as 4 bytes, a 64bit 8 bytes. This is the crux of your problem, you can't do anything about it.
Also, you may want to read http://en.wikipedia.org/wiki/Data_structure_alignment[^] ... in particular the bottom part on Default packing and #pragma pack. [EDIT] Doesn't have to do with your problem, but usefull to know. [/EDIT]
Good luck.
...cmk
The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack
|
|
|
|
|
I had a in-process dll which is injected in IE (dll developed in vc6.0).
This dll shows affect in windowsVista IE& whwn protected mode is OFF, but it doesnot show its effect when protected mode is ON.
What may be the causes fior this?
Can anyone suggest something?
|
|
|
|
|
svt gdwl wrote: protected mode
The last time I heard this I was using Windows 3.1 on DOS.
|
|
|
|
|
humm does windows 3.1 has IE ?
|
|
|
|
|
I´m trying to use some Icelandic characters in a program:
wchar_t *unichars = L"áéíóúýðöæþÁÉÍÓÚÝÐÖÆÞ";
std::wcout << unichars << std::endl;
The output I get in the console isn't great:
ßΘφ≤·²≡÷µ■┴╔═╙┌▌╨╓╞▐
Any idea on what is going wrong?
Jon
|
|
|
|
|
Jon wrote: Any idea on what is going wrong?
Set your locale to Icelandic:
_tsetlocale(LC_ALL,L"Icelandic");
Best Wishes,
-David Delaune
|
|
|
|
|
Thanks for the reply, that does help the console output (although it still isn't quite right).
I think the actual problem I was having was the encoding dev studio was using to save the file. Somehow the characters appear fine in the editor but only compile correctly when I saved the file in "Unicode - codepage 1200" format.
Jon
|
|
|
|
|
Jon wrote: codepage 1200
There is no codepage 1200. Icelandic uses code page 1252 (Western European) so you shouldn't have to change your language settings at all. I think you're getting things messed up somehow with Unicode and Ansi/OEM strings.
|
|
|
|
|
I am sure it is the file encoding, the original file is encoded in Western and if I open the file in a text editor the string reads:
"abdefghijklmnoprstuvxyzáéÃóúýðþæö"
through some dev studio magic the editor there shows the correct values (but it doesn't run correctly):
"abdefghijklmnoprstuvxyzáéíóúýðþæö"
If I change the file to UTF-16 then the text editor and the runtime all agree. Could it be that the file is using MBCS?
I'm using dev studio 2008, if you select file->save as, then click the arrow by the save and select "save with encoding...", one of the options is "Unicode - Codepage 1200".
Looking this up on wikipedia shows that this is:
# 1200 — UCS-2LE Unicode little-endian
Jon
|
|
|
|
|
Jon wrote: if I open the file in a text editor
Which editor?
|
|
|
|
|
If I open it with SciTE, it reports the encoding as "code page property" and the string isn't shown correctly. If I select UTF-8 as the enoding it shows correctly. I'm guessing the c++ compiler is reading this file in ascii giving the problem. There isn't a BOM on this file which is what was going wrong I guess.
Jon
|
|
|
|
|
In addition to David's suggestion - If you are using the console as output you need also CharToOem() or CharToOemBuff()
|
|
|
|
|
The console was only for testing, the font has to be set correctly as well I think. Anyway it's all working again now.
Jon
|
|
|
|
|
1. Using Visual Studio?
2. Hope the laguage settings from control panel are changed to icelandic.
|
|
|
|
|
That's not entirely necessary I think, although that would probably ensure the default file encoding was correct.
Another approach is to specify the unicode characters by number, something like:
wchar_t *unichars = L"\u00FE\u00D1...
This would work (if I knew all the codes) but wouldn't be very readable.
Jon
|
|
|
|
|