|
something like this?
cstrFormat.Format("%I64", *n64Address);
|
|
|
|
|
Thanks,
You sent me down the right path.
cstrFormat.Format("%I64d", *n64Address); works
|
|
|
|
|
Hi,
I am using VC7. and make thumbnails of images when we call Bitmap::FromFile(L"C:\\Test.bmp") and return value store in Bitmap pointer. It return 0x0000000 address and we get error code 8. I have included gdiplus.h header file and GdiPlus.lib file.
But it is working well with other downloaded sample program
|
|
|
|
|
need to check your code. can you post code snippet here
|
|
|
|
|
I have fully checked and also only call that funcyion
but problem still
|
|
|
|
|
Do u have the "GdiplusStartup"?
|
|
|
|
|
Hi,
I am using VC7. and make thumbnails of images when we call Bitmap::FromFile(L"C:\\Test.bmp") and return value store in Bitmap pointer. It return 0x0000000 address and we get error code 8. I have included gdiplus.h header file and GdiPlus.lib file.
But it is working well with other downloaded sample program
ghy
|
|
|
|
|
Hi,
I am using VC7. and make thumbnails of images when we call Bitmap::FromFile(L"C:\\Test.bmp") and return value store in Bitmap pointer. It return 0x0000000 address and we get error code 8. I have included gdiplus.h header file and GdiPlus.lib file.
But it is working well with other downloaded sample program.
ghy
|
|
|
|
|
HI,
How can i change the width of Crect variable..
ie CRect rect;
need to change the width of rect...
|
|
|
|
|
InflateRect (n,0);
or, it's only four members...
rc.left -= 3;
rc.right += 3;
Iain.
I have now moved to Sweden for love (awwww).
If you're in Scandinavia and want an MVP on the payroll (or happy with a remote worker), or need cotract work done, give me a job! http://cv.imcsoft.co.uk/[ ^]
|
|
|
|
|
HI Guys iam converting a CString to LPSTR iam getting only first charcter what can any body suggest me how to get complete string I tried the folowing i did n't get it
CString str=_T("Hello");
LPSTR ptr=str.GetBuffer(0);
iam getting only first character into ptr and tried other also its not working
LPSTR ptr=str.GetBuffer(str.GetLength());
|
|
|
|
|
Please, read the documentation about the GetBuffer to understand why you should never call this function without knowing what it does.
Furthermore, CString provides a cast operator that returns the same type as the GetBuffer function.
And how are you checking that you only get the first character ? Why do you need to store that into a LPSTR variable ?
|
|
|
|
|
Cedric Moonen wrote: CString provides a cast operator that returns the same type as the GetBuffer function.
CString has an LPCTSTR operator, whereas GetBuffer()returns an LPTSTR (which is not const). 
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
you need to call release buffer also 
|
|
|
|
|
I bet the content of CString is Unicode, and LPSTR is a multibyte string.
Try casting to LPTSTR instead.
Even better, if you don't support Win98 and older versions, just drop this "T" stuff and always use wide strings instead.
|
|
|
|
|
Whenever I right-click on my CDockablePane, a context menu (Floating, Docking, Tabbed Document, Auto Hide, Hide) appear. How do I disable this?
|
|
|
|
|
Your in luck! I am currently working on a CDockablePane derived class. You need to overide CPane::OnShowControlBarMenu[^]
Just tested it and it works. The really wierd thing is... the MSDN says:
TRUE if the menu can be displayed; otherwise, FALSE.
But... I had to do the exact opposite! Can you confirm this in your code?
Best Wishes,
-David Delaune
|
|
|
|
|
CFieldPane is derived from CDockablePane.
BOOL CFieldPane::OnShowControlBarMenu(CPoint point)
{
return TRUE;
}
Nothing happens. The context menu still appear 
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
