|
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.<
|
|
|
|
|
That did the trick - thanks!
I'll probably store the entire bitmap in memory, as there are multiple buttons and dialogs that will use it.
|
|
|
|
|
Yourwelcome, glad it worked out. Good luck with the rest. 
> 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.<
|
|
|
|
|
vector<int> vect;
vector<int>::iterator pBegin;
I want to check the iterator for NULL.
In VC6 we can compare if (pBegin == NULL) and it works. But in VC10 we cannot compare iterator to NULL.
How to achieve that in VC10?
|
|
|
|
|
You should check against begin or end (usually past the end).
if you have
KASR1 wrote: vector<int>::iterator pBegin;
Than it should be treated as an uninitialized variable, so it it give out bad results if used as-is.
As far as I know, the STL implementation in VC6 is crap and not standard.
Watched code never compiles.
|
|
|
|
|
Ok. Lets assume its not initialized.
Can we consider checking
if (pBegin != vect.end()) in place of if( pBegin != NULL)
|
|
|
|
|
You need to assign the iterator to something valid before using it.
std::vector<int> v;
std::vector<int>::iterator pBegin = v.begin();
while ( pBegin != v.end() )
{
++it;
}
or
if ( pBegin != v.end() )
{
}
Watched code never compiles.
|
|
|
|
|
|
std::vector<int>::iterator pIter = v.end();
//do Some operation on pIter
if ( pIter != v.end() )
{
// do something
}
Is the above logic make sense?
|
|
|
|
|
Checking it against NULL is wrong. It's an implementation detail that it works in vc6 (because raw pointers are used, amongst other implementation specific details). Iterators are not required be pointers, in fact vectors are one of the few containers where they can do the job and as you've discovered even then they are not the only option.
Steve
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
