|
work with BSTR. Best is CComBSTR class, it help to ferget annoying stuff. 
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
Good day Friends!
Here comes a new challenge!
Need to discuss whether it is right or what?
My problem is that the challenge sent by the server should be 8 bytes as i read from the documentation. As i decode the hash send by the server and Extract Challenge from it, it gives me only 7 characters including null character.
should i generate the response by using that 7 byte challenge or somewhere i am wrong.
is the challenge must be 8 bytes?
In short my question is:: can a challenge be less than 8 bytes?
|
|
|
|
|
Aabid wrote: My problem is that the challenge sent by the server should be 8 bytes as i read from the documentation. As i decode the hash send by the server and Extract Challenge from it, it gives me only 7 characters including null character.
The documentation says that authentication is base64 encoded data. It looks like this:
AUTH NTLM <base64encoded type 1 message>
334 <base64encoded type 2 challenge message>
<base64encoded type 3 response>
235 NTLM authentication successful
For details see The NTLM Authentication Protocol[^], at the end is another example for SMTP.
/M
Webchat in Europe ![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif) Now with 26% more Twitter
modified on Wednesday, March 24, 2010 10:39 AM
|
|
|
|
|
hi,
i have a multibyte application.nw i m setting its tooltip with
_mbstowcsz(pTTTW->szText,buffer, sizeof(pTTTW->szText)/sizeof(pTTTW->szText[0]));
which is showing garbage.any alternative?
|
|
|
|
|
Are you sure the tooltips are set to use Unicode? Take a look at the sample code here[^].
txtspeak is the realm of 9 year old children, not developers. Christian Graus
|
|
|
|
|
i m using exactly the same code as in ur example but still tooltips are showing garbage.My application is multibyte.
|
|
|
|
|
you cant mix Multibyte and Unicode without conversions!!! 
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
Member 590310 wrote: i m using exactly the same code as in ur example
I did not provide an example, I pointed you to the MSDN page describing how to achieve what you want to do. Have you coded it exactly as shown? Have you run it through the debugger to ensure your conversion is working correctly?
txtspeak is the realm of 9 year old children, not developers. Christian Graus
|
|
|
|
|
yes i debugged it PTTW->sztext is setting correctly but when i run it garbage is shown in tooltips..my question is that PTTW->sztext is for unicode apps so wat shud be done if app is multibyte.
|
|
|
|
|
Take a look at the page I posted in my previous answer, it shows clearly how to use multi-byte or Unicode for tooltips, and which pointers are used for each type.
txtspeak is the realm of 9 year old children, not developers. Christian Graus
|
|
|
|
|
yes i have read that there is no clue for multibyte it only deals with ANSI or unicode but i need to handle multibyte as my application is multibyte for some reasons.
|
|
|
|
|
ANSI is a subset of multibyte. Windows function calls that end with 'A' handle multibyte as well as ANSI, those that end in 'W' handle wide (Unicode) characters. The sample clearly shows how to code the tooltip methods in order to handle multibyte or Unicode.
txtspeak is the realm of 9 year old children, not developers. Christian Graus
|
|
|
|
|
hi,
how i can set multibyte tooltips to toolbars.any function for multibyte tooltips?
|
|
|
|
|
See the link in my answer to your question above.
txtspeak is the realm of 9 year old children, not developers. Christian Graus
|
|
|
|
|
I wrote something like this :
<br />
MD2Mesh::Frame* md2Frame = (MD2Mesh::Frame*)buffer;<br />
uint8* tmp = buffer + 40;<br />
MD2Mesh::Vertex* vtx = (MD2Mesh::Vertex*)tmp;<br />
md2Frame->vertices = vtx;<br />
The value of "vtx" is changed after the line "mdFrame->vertices = vtx"
U can look at the following debugging table:
| vtx | 0x00434140 {v=0x00434140 "ÐBÄ" normIdx=0 } | origin::MD2Mesh::Vertex * |
after line "mdFrame->vertices = vtx" it becomes like this :
| vtx | 0x00434140 {v=0x00434140 "@AC" normIdx=0 } | origin::MD2Mesh::Vertex * | | md2Frame->vertices | 0x00434140 {v=0x00434140 "@AC" normIdx=0 } | origin::MD2Mesh::Vertex * |
Do u have any ideas ?
|
|
|
|
|
It looks like you've got some cyclic thing going on.
You're setting vtx to something inside md2Frame. But vtx is cast from tmp which is obtained by manipulating buffer. But buffer is cast to md2Frame, in which you are trying to set this value...
I can't say for certain that's the problem, but wouldn't hurt to sort this out properly first.
Almost, but not quite, entirely unlike... me...
|
|
|
|
|
What is type of the buffer? Is it uint8*?
What expected by buffer + 40?
See, buffer + 1 would point to next unint8 position in the buffer. Is that what intended?
|
|
|
|
|
You haven't given us all the types and class/structure definitions involved.
You are also using a mess of casts and potential aliasing issues. You have to know what you are doing and be very careful to get this kind of stuff right.
anbluemoon wrote: MD2Mesh::Frame* md2Frame = (MD2Mesh::Frame*)buffer;
Apparently, buffer is a SomeType_T *buffer set to the address of a block of allocated memory. What is SomeType_T? How big a block of memory? What is a MD2Mesh::Frame? How big is a MD2Mesh::Frame?
Also if MD2Mesh::Frame is not a pod type, you are dead without properly constructing it via its constructor.
anbluemoon wrote: uint8* tmp = buffer + 40;
MD2Mesh::Vertex* vtx = (MD2Mesh::Vertex*)tmp;
Your magic number could be subject to breakage due to changes. Additionally, it hides your intent. Also don't forget about alignment issues and padding that the compiler can insert in structs.
md2Frame now points to the beginning of the buffer.
vtx now points inside the buffer.
anbluemoon wrote: md2Frame->vertices = vtx;
You have now changed part of the contents of the buffer.
vtx has not changed at all. It is however a pointer, and what it points to in the buffer has changed because you wrote code to change it.
Evidently, MD2Mesh::Frame.vertices is 40 * sizeof(SomeType_T) bytes from the beginning of the structure.
Please do not read this signature.
|
|
|
|
|
Here is data structures:
<br />
typedef unsigned char uint8;<br />
<br />
class MD2Mesh<br />
{<br />
struct Vertex<br />
{<br />
uint8 coord[3],<br />
normalIdx;<br />
};<br />
<br />
struct Frame<br />
{<br />
float translation[3],<br />
rotation[3];<br />
char name[16];<br />
Mesh::Vertex* vertices;<br />
};<br />
<br />
};<br />
At first I tried to do something like :
MD2Mesh::Frame* md2Frame = (MD2Mesh::Frame*)buffer
to get the values from the buffer without initializing the pointer and I managed to get the values of translation, rotation and name but the vertices address didn't point to the "buffer + 40(size of translation + rotation + name)" so i just pass the the address of vtx which is buffer + 40
|
|
|
|
|
Again you forgot to mention the type of buffer?
|
|
|
|
|
Hallo,
I upgraded from Visual Studio 2005 to Visual Studio 2008, and converted my Project from from VS2005 to VS2008.
But now I get an Error in the following lines:
LOGFONT lFont;
NONCLIENTMETRICS ncm;
ncm.cbSize = sizeof(NONCLIENTMETRICS);
VERIFY(SystemParametersInfo(SPI_GETNONCLIENTMETRICS,
sizeof(NONCLIENTMETRICS), &ncm, 0));
lFont = ncm.lfMessageFont;
In Windows XP SystemParametersInfo() returns false, and there are the following Values in ncm after executing the SystemParametersInfo() Function:
Screenshot
When I open my Project in Windows 7, it works without problem. In XP I get an access exeption in msvcr90d.dll when I ignore the failed execution of SystemParametersInfo.
Can someone help me?
Thank you!
|
|
|
|
|
I would guess NONCLIENTMETRICS has grown... And VS2008 will default WINVER to a later (higher) value, so the size you have compiled is the "bigger" one.
You pass the size of the structure to SystemParametersInfo - and the later OS can handle the earlier structure. But the earlier OS can't handle the later structure.
Doing a little digging...
http://msdn.microsoft.com/en-us/library/ms724506%28VS.85%29.aspx[^]
typedef struct tagNONCLIENTMETRICS {
UINT cbSize;
int iBorderWidth;
...
LOGFONT lfMessageFont;
#if (WINVER >= 0x0600)
int iPaddedBorderWidth;
#endif
} NONCLIENTMETRICS, *LPNONCLIENTMETRICS;
You can see my theory is probably right.
XP has no idea what to do with the oversized structure you're giving it...
If you want to be compatible with XP, define WINVER to an appropriate value (0x501 I thiiiink) before including the header files.
Good luck,
Iain.
I have now moved to Sweden for love (awwww).
|
|
|
|
|
Thank you, VS2008 sets WINVER to Windows Vista. I now set WINVER in the stdafx.h files of my DLLs to WinXP and now it works.
This is the greatest forum in the world! 
|
|
|
|
|
Joschwenk666 wrote: This is the greatest forum in the world!
This is just a tribute!
(you're welcome, glad I helped)
Iain.
I have now moved to Sweden for love (awwww).
|
|
|
|
|
Hi,
I have some code that is as old as the hills and has always worked. It just gets the name of the file to save using the common control Save As dialog:
BOOL GetFileToSave(HWND hwnd, TCHAR *lpstrFileName, DWORD filter)<br />
{<br />
static char szFilter[MAX_PATH_LENGTH], szExtension[12];<br />
BOOL temp;<br />
char *file, *path;<br />
temp = FALSE;<br />
file = malloc(MAX_PATH_LENGTH);<br />
path = malloc(MAX_PATH_LENGTH);<br />
<br />
if (file && path)<br />
{<br />
GetFilter(szFilter, szExtension, filter);<br />
ofn.nFilterIndex = 1;<br />
ofn.lpstrDefExt = szExtension;<br />
ofn.lpstrFilter = szFilter;<br />
<br />
GetPathName(file, path, lpstrFileName);<br />
ofn.hwndOwner = hwnd;<br />
ofn.lpstrFile = file;<br />
ofn.lpstrInitialDir = path;<br />
ofn.Flags = OFN_HIDEREADONLY | OFN_PATHMUSTEXIST | OFN_OVERWRITEPROMPT;<br />
EnableAllWindows(FALSE, 0);<br />
temp = GetSaveFileName(&ofn);<br />
EnableAllWindows(TRUE, 0);<br />
if (temp) strcpy(lpstrFileName, ofn.lpstrFile);<br />
}<br />
if (file) free(file);<br />
if (path) free(path);<br />
<br />
return temp;<br />
}<br />
<br />
I have SOME users on Windows 7 only who find that the Save As dialog can take up to 30 seconds before it allows the OK button to be pressed. In this time it seems to work normally, but it just not respond to OK being pressed.
This code works fine on all our W7 machines, and I suspect some problem with the enumeration of the attached drives. BUT, can anyone see any weakness in the code? As I say, only a few users with W7 report this issue, the vast majority don't get this, but I'm open to any suggestions about improving the code.
- Mark
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
