|
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
|
|
|
|
|
hmmm, ok, not what I understood.
I thought non flag parameters were parameter with no flag before them.
??
Watched code never compiles.
|
|
|
|
|
If you read the documentation[^] it explains that any parameter that uses a - or / prefix is a flag parameter, all others are non-flag. Command line parameters are separated by spaces and have always been treated in this way since the early days of Unix and C. Within your application you can choose to apply the meaning of /myflag to the next parameter in sequence but that is something that your app needs to be coded for.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
It seems you misunderstood the non-flag term. With
app.exe /myFlag anotherfile.txt
myFlag is a flag and anotherfile.txt is a non-flagged parameter.
To use values with flags, one option is to separate the value using the assignment character without any spaces:
app.exe /myFlag=anotherfile.txt
Your parser must then extract the value.
If you want to use space separated values, you may add member variables to your CCommandLineInfo derived class storing the flag if it has required or optional values. With the next call to ParseParam, you can then get the value.
|
|
|
|
|
Hello,
I've created a button that displays a CBitmap, and switches to a different bitmap when pressed.
I now want to add transparency, allowing the dialog background to show through in certain places.
To do this, I have set a background image on the dialog by overriding the OnEraseBkgnd() method.
The button draw code is called from the dialog OnDrawItem. The drawing code then updates the buttons pCwnd DC (obtained from GetDlgItem, GetDC).
- The DC creates a compatible DC from realDC.
- The DC select-object's a bitmap (realDC compatiblebitmap)
- TransparentBlt a bitmap to the DC
- BitBlt the DC to the realDC
For non-transparent buttons, the above works fine. When there is transparency in the button image, the background doesnt show. Instead, there are smears, or a portion of the previous bitmap remains (when changing from non-transparent to transparent when it is clicked).
I thought I needed an 'Invalidate(TRUE)', not really sure. I tried calling it but it just refreshes the transparent portion to whatever it was before (generally a black/white smear).
Can anyone see any issues with the steps I mentioned above?
TIA.
[EDIT] Using MFC on WinCE.
|
|
|
|
|
Step1. Blit the background bitmap on the realDC.
Step2. Create a bitmap that is compatible with realDC
Step3. Draw on the compatible bitmap (transparent blit)
Step4. Blit this bitmap onto the realDC.
Why would you expect to have th ebackground bitmap magically appear on the compatible bitmap? This should be something like:
Step1. Blit the background bitmap on the realDC.
Step2. Create a bitmap that is compatible with realDC
Step3. Blit the correct portion of the background bitmap onto the compatible bitmap.
Step4. Draw on the compatible bitmap (transparent blit)
Step5. Blit this bitmap onto the realDC.
> 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.<
modified 2-Apr-12 11:55am.
|
|
|
|
|
Not sure to be honest. I just assumed TransparentBlt contained magic!
What is the 'correct' way to retrieve the background? Using what I know, I guess I could use a variation of the OnEraseBkgnd() code (ie load resource, StretchBlt to temporary DC, then BitBlt to the compatible bitmap) - but I suspect that is not very efficient. Is it possible to retrieve it from the 'realDC'?
Thanks for your help!
|
|
|
|
|
Transparent blt basically works something like this:
take the pixel of the source surface (e.g. a bitmap in memory), check if its color equals the 'transparent color', if no, draw it onto the target and move on to the next pixel, if yes, skip it and move on to the next pixel.
I don't think there is a "correct way by the book" to do it, what you said about invoking OnEraseBkgnd is one way, you could also try to store the part of the background bitmap in memory which lies under your button and use that when drawing.
> 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.<
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
