C / C++ / MFC

Re: IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS returns error code 87 INVALID_PARAMETER

3-Apr-12 0:52

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);

Jochen Arndt3-Apr-12 0:59

Re: IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS returns error code 87 INVALID_PARAMETER

3-Apr-12 0:59

Then you should check the lpBytesReturned value and compare it with the structure size to see why.

VCProgrammer3-Apr-12 1:02

Re: IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS returns error code 87 INVALID_PARAMETER

3-Apr-12 1:02

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.

Jochen Arndt3-Apr-12 1:12

Re: IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS returns error code 87 INVALID_PARAMETER

3-Apr-12 1:12

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.

VCProgrammer3-Apr-12 1:17

Re: IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS returns error code 87 INVALID_PARAMETER

3-Apr-12 1:17

Can you please tell me how to use 8 byte allignment my

DWORD d = sizeof(VOLUME_DISK_EXTENTS);<pre> is returining 24 value

Jochen Arndt3-Apr-12 1:31

Re: IOCTL_VOLUME_GET_VOLUME_DISK_EXTENTS returns error code 87 INVALID_PARAMETER

3-Apr-12 1:31

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+):

C++

#if !defined(WIN32) && !defined(_WIN64)
#include <pshpack4.h>
#endif

Winsock2.h without the bug looks like this (from Server 2003 R2 SDK):

C++

#if !defined(WIN32) && !defined(_WIN64)
#include <pshpack4.h>
/* WIN32 can be defined between here and the required poppack
   so define this special macro to ensure poppack */
#define _NEED_POPPACK
#endif

VCProgrammer3-Apr-12 2:47

Duplicate Function - Linker Error LNK2005

3-Apr-12 2:47

Thanks a lot it solved my problem....

Mike Certini2-Apr-12 9:30

Mike Certini

2-Apr-12 9:30

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.

C++

// MetaDLL_5.cpp : Defines the initialization routines for the DLL.
//
#pragma once

#define WIN32_LEAN_AND_MEAN
//#define _AFXDLL

//#include <windows.h>
#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 = ansi_to_managed(date_time);	
	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;
	}

Re: Duplicate Function - Linker Error LNK2005

Richard MacCutchan2-Apr-12 21:25

Richard MacCutchan

2-Apr-12 21:25

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

CCommandLineInfo and parsing command line arguments.

Maximilien2-Apr-12 3:47

Re: CCommandLineInfo and parsing command line arguments.

2-Apr-12 3:47

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:

C++

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;
        }
    }

    //call standard commandline processing (for /Regserver, Unregserver...)
    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.

Richard MacCutchan2-Apr-12 4:06

Richard MacCutchan

2-Apr-12 4:06

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

Re: CCommandLineInfo and parsing command line arguments.

Maximilien2-Apr-12 4:34

Re: CCommandLineInfo and parsing command line arguments.

2-Apr-12 4:34

hmmm, ok, not what I understood.

I thought non flag parameters were parameter with no flag before them.

??

Watched code never compiles.

Richard MacCutchan2-Apr-12 4:42

Richard MacCutchan

2-Apr-12 4:42

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

Re: CCommandLineInfo and parsing command line arguments.

Jochen Arndt2-Apr-12 4:18

TransparentBlt not showing background correctly

2-Apr-12 4:18

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.

Codling20202-Apr-12 3:39

Codling2020

2-Apr-12 3:39

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.

Re: TransparentBlt not showing background correctly

Code-o-mat2-Apr-12 5:04

Code-o-mat

2-Apr-12 5:04

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.

Re: TransparentBlt not showing background correctly

Codling20202-Apr-12 5:37

Codling2020

2-Apr-12 5:37

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!

Re: TransparentBlt not showing background correctly

Code-o-mat2-Apr-12 6:12

Code-o-mat

2-Apr-12 6:12

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.<

Re: TransparentBlt not showing background correctly

Codling20202-Apr-12 6:35

Codling2020

2-Apr-12 6:35

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.

Re: TransparentBlt not showing background correctly

Code-o-mat2-Apr-12 6:43

Code-o-mat

2-Apr-12 6:43

Yourwelcome, glad it worked out. Good luck with the rest. Smile | :)

> 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.<

How to check iterator for NULL

KASR12-Apr-12 2:24

KASR1

2-Apr-12 2:24

XML

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?

Maximilien2-Apr-12 2:46

2-Apr-12 2:46

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.

KASR12-Apr-12 2:53

KASR1

2-Apr-12 2:53

Ok. Lets assume its not initialized.
Can we consider checking
if (pBegin != vect.end()) in place of if( pBegin != NULL)

Maximilien2-Apr-12 3:00

2-Apr-12 3:00

You need to assign the iterator to something valid before using it.

C++

std::vector<int> v;
// fill the vector.

std::vector<int>::iterator pBegin = v.begin();

while ( pBegin != v.end() )
{
  // do something.
  ++it;
}

C++

if ( pBegin != v.end() )
{
  // ite
}

Watched code never compiles.