|
Hi,
Is there any machenism to check the socket status (alive or dead )?
|
|
|
|
|
What do you mean by "alive" and "dead"?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
If there is any doubt about the condition of a socket, it's best to simply Close() it and open a new one.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
john5632 wrote: Is there any machenism to check the socket status (alive or dead )?
Send a request and get a response.
|
|
|
|
|
Hi all,
I am trying to map logical drive to physical drive i.e. when i pass D: then it should get that which Physical drive does D: belongs to.
I am using IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS for achieving my goal. My problem is it is returning error code 87 INVALID_PARAMETER.
I am not getting that what i am doing wrong
here is my code
CString str = _T("\\\\.\\\\D:");
HANDLE h = CreateFile(str, GENERIC_READ, FILE_SHARE_READ|FILE_SHARE_WRITE,NULL,OPEN_EXISTING,0,NULL);
if(INVALID_HANDLE_VALUE != h)
{
VOLUME_DISK_EXTENTS sd;
DWORD dwRet;
ret = DeviceIoControl(h, IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS, NULL, 0, &sd, sizeof(VOLUME_DISK_EXTENTS), &dwRet, NULL);
if(ret != 0)
{
AfxMessageBox(_T("Success"));
}
else
{
DWORD d;
d = GetLastError();
}
}
|
|
|
|
|
Use this (single backslash in front of device name / drive letter)
CString str = _T("\\\\.\\D:");
|
|
|
|
|
Your pathname is incorrect, it contains two backslash characters after the dot rather than one, as described here[^]. You should check the return value from your CreateFile() call before proceeding.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
after passing one also it is giving same error
_T("\\\\.\\D:")
CreateFile is returning correct handle but DeviceIoControl is returning 0.
|
|
|
|
|
Did you check that CreateFile() was successful?
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
yes CreateFile was successfull. But DeviceIoControl was returning 0.
|
|
|
|
|
I just tested your code and it works fine on Windows 7, but I need to run as administrator for it to work.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
i am also running it on win 7 I have provided it with admin rights also. I have made a dummy code and it works fine but when i implement it in my main application it gives same error.
|
|
|
|
|
VCProgrammer wrote: but when i implement it in my main application it gives same error.
Which suggests there is something else happening in your main application; time to get the debugger working to track what is happening and what may be different between the two programs.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
You may try to use a larger buffer just to check if this avoids the error.
Which VS version did you use (there may be an alignment problem when including winsock2.h from the VS 2003 platform SDK)?
|
|
|
|
|
when i increased buffer it started working but it gives wrong result and crashes saying sd buffer is being corrupted.
ret = DeviceIoControl(h, IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS, NULL, 0, &sd, (sizeof(VOLUME_DISK_EXTENTS)*8), &dwRet, NULL);
|
|
|
|
|
Then you should check the lpBytesReturned value and compare it with the structure size to see why.
|
|
|
|
|
lpBytesReturned is returning 32 bytes
and when i write
DWORD d = sizeof(VOLUME_DISK_EXTENTS); it gives 24 in variable d.
Then i multiply the size by 2, it starts working but gives incorrect result.
|
|
|
|
|
32 is the VOLUME_DISK_EXTENTS structure size when using 8 byte alignment. It seems that your alignment settings are different (check sizeof(VOLUME_DISK_EXTENTS)). If they differ, you must use 8 byte alignment here. Otherwise you will access the wrong structure fields.
|
|
|
|
|
Can you please tell me how to use 8 byte allignment my
DWORD d = sizeof(VOLUME_DISK_EXTENTS);<pre> is returining 24 value
|
|
|
|
|
First check your general C++ code settings of your project. The structure alignment must be the default of 8 (compiler command line option /Zp8).
If this is OK, the alignment is changed somewhere in a header or source file using the #pragma pack() statement or including one of the Pshpack<n>.h files.
A candidate is the winsock2.h header file of the platform SDK delivered with VS 2003 that contains a bug (lines 24+):
#if !defined(WIN32) && !defined(_WIN64)
#include <pshpack4.h>
#endif
Winsock2.h without the bug looks like this (from Server 2003 R2 SDK):
#if !defined(WIN32) && !defined(_WIN64)
#include <pshpack4.h>
#define _NEED_POPPACK
#endif
|
|
|
|
|
Thanks a lot it solved my problem....
|
|
|
|
|
I have been racking my brain trying to figure out how to resolve a duplicate function error (LNK2005) and have been unsuccessful. I have followed direction on the following link as well: http://msdn.microsoft.com/en-us/library/72zdcz6f(v=VS.80).aspx Attached is a printscreen of where the error occurs. The following are issues I have come across:
1. One thing I noted in the output build report is that after invoking the linker with LINK.exe, one of the linker parameters that prints is /incremental:no, though when I look under Solution Explorer\Properties\Configuration Properties\Linker\General\Enable Incremental Linking the setting is Yes(/Incremental). Is there a setting somewhere that is causing an over-ride of the setting? I have done a build/clean for the project.
2. I have specified under Solution Explorer\Properties\Configuration Properties\Linker\Input\Ignore Specific Library the mfcs90ud.lib file. I added it back as an additional dependency. Though I still have problems with this lib file.
#pragma once
#define WIN32_LEAN_AND_MEAN
#include "stdafx.h"
#include "MetaDLL_6.h"
#using <mscorlib.dll>
using namespace System;
using namespace System::Globalization;
using namespace System::Runtime::InteropServices;
using System::String;
#define MT4_EXPFUNC __declspec(dllexport)
#pragma managed
String *ansi_to_managed(char *date_time)
{
return Marshal::PtrToStringAnsi(date_time);
}
#pragma unmanaged
BOOL APIENTRY DllMain(HANDLE hModule, DWORD ul_reason_for_call, LPVOID lpReserved)
{
return TRUE;
}
#pragma managed
MT4_EXPFUNC void __stdcall gDateTime(char *date_time, int *year, int *month, int *day, int *hour, int *minute, int *second, int *millisecond)
{
String *myDateTimeValue = S"02/16/1992 12:15:12.253";
String *expectedFormats[] = {S"MM/dd/yyyy HH:mm:ss.FFF"};
IFormatProvider* culture = new CultureInfo(S"en_US", true);
DateTime myDateTime = DateTime::ParseExact(myDateTimeValue, expectedFormats, culture, DateTimeStyles::AssumeLocal);
*year = myDateTime.Year;
*month = myDateTime.Month;
*day = myDateTime.Day;
*hour = myDateTime.Hour;
*minute = myDateTime.Minute;
*second = myDateTime.Second;
*millisecond = myDateTime.Millisecond;
}
|
|
|
|
|
OK, I give up, what error did you get?
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
I'm trying to understand how this thing works.
I have an application that can receive filename arguments like :
(A)app.exe file.txt /myFlag anotherfile.txt
file.txt will be loaded and anotherfile.txt will be used after the file (file.txt) is loaded.
or
(B)app.exe /myFlag anotherfile.txt
no file will be loaded but anotherfile.txt will be used nonetheless.
when parsing the command line arguments with the CCommandLineInfo class I get (probably good result) weird result.
The member CCommandLineInfo::m_strFileName is (according to MSDN) :
Stores the value of the first non-flag parameter on the command line.
In example A, m_strFileName is "file.txt" and in example B m_strFileName is "anotherfile.txt" ???
in example B, I don't have a non-flag parameter; but the m_strFileName is assigned to the parameter of the flag (anotherfile.txt).
code:
void MyCommandLineInfo::ParseParam(const char* pszParam, BOOL bFlag, BOOL bLast)
{
if ( bFlag )
{
if (_stricmp(pszParam,"myFlag") == 0)
{
m_FlagFound = true;
m_ExpectFileNext = true;
}
}
else
{
if ( m_ExpectFileNext)
{
m_MyFile = pszParam;
m_ExpectFileNext = false;
}
}
CCommandLineInfo::ParseParam( pszParam, bFlag, bLast );
}
Question :
In the B case, is there a way to have CCommandLineInfo not have m_strFileName be assigned like it should not be since there is no non-flag argument to my commandline.
Thanks.
Max.
Watched code never compiles.
|
|
|
|
|
app.exe /myFlag anotherfile.txt
In this case myFlag is a flag parameter and anotherfile.txt is a non-flag parameter, in fact it's the first one, so it will be placed in CCommandLineInfo::m_strFileName as stated in MSDN.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
