C / C++ / MFC

#if (_WIN32_IE >= 0x0500)

18-Aug-04 5:30

I downloaded some code off of this site that has the constant NIIF_NONE in it. This has happened to me before, and now again where my app won't build because it can't find these constants. It says in the documentation for the source that this and the other NIIF_ constants are defined in shellapi.h, but I can't find them there. Any help?

[insert witty comment here]

bdiamond Sleepy | :zzz:

BlackDice18-Aug-04 5:45

Re: #if (_WIN32_IE >= 0x0500)

18-Aug-04 5:45

I also see now in shellapi.h that the above preprocessor is called. I'm guessing this means if my internet explorer version is higher than 5?? I have IE 6, so I don't know what the problem is. I found the #defines for NIIF_NONE and others, but they're not included (or dwInfoFlags). Anybody know why? Any help is appreciated. Thanks!!!

[insert witty comment here]

bdiamond Sleepy | :zzz:

Steve Thresher18-Aug-04 5:52

Steve Thresher

18-Aug-04 5:52

You need to define _WIN32_IE to 0x0500 or greater somewhere in your program or as part of the command line eg.

#define _WIN32_IE 0x0500

Systems AXIS Ltd - Software for Business ...

Steve Thresher18-Aug-04 5:48

Steve Thresher

18-Aug-04 5:48

The flags are defined in my copy of shellapi.h as follows:

#if (_WIN32_IE >= 0x0500)
#define NIS_HIDDEN 0x00000001
#define NIS_SHAREDICON 0x00000002

// says this is the source of a shared icon

// Notify Icon Infotip flags
#define NIIF_NONE 0x00000000
// icon flags are mutually exclusive
// and take only the lowest 2 bits
#define NIIF_INFO 0x00000001
#define NIIF_WARNING 0x00000002
#define NIIF_ERROR 0x00000003
#define NIIF_ICON_MASK 0x0000000F
#if (_WIN32_IE >= 0x0501)
#define NIIF_NOSOUND 0x00000010
#endif
#endif

Systems AXIS Ltd - Software for Business ...

BlackDice18-Aug-04 5:56

18-Aug-04 5:56

duh, I was looking in the wrong place at first, (vc98 include folder) I found them, but now I'm finding that the trouble must be with the IE version defined. I looked it up in the MSDN and found out what it meant, but since I have version 6 of IE, I still don't see what the problem is..Wait, I just got an email where you stated I should define my explorer version. I was just going to ask if I should do that, and will it break something? Oh well, I'm going to try that now. Thanks!!

[insert witty comment here]

bdiamond Sleepy | :zzz:

BlackDice18-Aug-04 6:07

18-Aug-04 6:07

yup, that worked!!! thanks

[insert witty comment here]

bdiamond Sleepy | :zzz:

What wrong with this code?

Michael Dunn18-Aug-04 7:17

Michael Dunn

18-Aug-04 7:17

See the FAQ:
2.2 I'm trying to call a Windows API, but the compiler gives an undeclared identifier error (C2065). Why?[^]

--Mike--
Personal stuff:: Ericahist | Homepage
Shareware stuff:: 1ClickPicGrabber | RightClick-Encrypt
CP stuff:: CP SearchBar v2.0.2 | C++ Forum FAQ
----
"That probably would've sounded more commanding if I wasn't wearing my yummy sushi pajamas."
-- Buffy

gilazilla18-Aug-04 4:51

gilazilla

18-Aug-04 4:51

Hi,
i tried to modify the codes to display only gray scale image and aslo the original image.So far my program just display a blank bitmap.Anyone can please help me.

void CMy2ndtryView::OnDraw(CDC* pDC)
{
CMy2ndtryDoc* pDoc = GetDocument();
ASSERT_VALID(pDoc);
// TODO: add draw code for native data here

CDC MemDC;
MemDC.CreateCompatibleDC (NULL);
MemDC.SelectObject (&m_Bitmap);

pDC->BitBlt
(20,
20,
m_BitmapWidth,
m_BitmapHeight,
&MemDC,
0,
0,
SRCCOPY);

CDC resultDC;
CBitmap m_result;

m_result.CreateCompatibleBitmap(pDC,m_BitmapWidth,m_BitmapHeight);
resultDC.CreateCompatibleDC (NULL);
resultDC.SelectObject (&m_Bitmap);

for( int y = 0; y < m_BitmapHeight ; y++ )
{
for( int x = 0; x < m_BitmapWidth ; x++ )
{
//set pixel to color returned by convolve
resultDC.SetPixel(x,y,Convolve(&MemDC,x,y,kernel));
}
}

//Display Result
pDC->BitBlt
(300,
20,
m_BitmapWidth,
m_BitmapHeight,
&resultDC,
0,
0,
SRCCOPY);

}

COLORREF CMy2ndtryView::Convolve(CDC *pDC, int sourcex, int sourcey, float kernel[][3])
{
float rSum = 0, gSum = 0, bSum = 0, kSum = 0;
float grayscale =0;
COLORREF clrReturn = RGB(0,0,0);
for (int i=0; i <= 2; i++)//loop through rows
{
for (int j=0; j <= 2; j++)//loop through columns
{

COLORREF tmpPixel = pDC->GetPixel(sourcex+(i-(2>>1)),sourcey+(j-(2>>1)));

float fKernel = kernel[i][j];

rSum += (GetRValue(tmpPixel)*fKernel);
gSum += (GetGValue(tmpPixel)*fKernel);
bSum += (GetBValue(tmpPixel)*fKernel);

kSum += fKernel;
}
}

if (kSum <= 0)
kSum = 1;

rSum/=kSum;
gSum/=kSum;
bSum/=kSum;
if (rSum > 255)
rSum = 255;
else if (rSum < 0)
rSum = 0;
if (gSum > 255)
gSum = 255;
else if (gSum < 0)
gSum = 0;
if (bSum > 255)
bSum = 255;
else if (bSum < 0)
bSum = 0;

grayscale=0.299*rSum + 0.587*gSum + 0.114*bSum;
rSum=grayscale;
gSum=grayscale;
bSum=grayscale;

clrReturn = RGB(rSum,gSum,bSum);
return clrReturn;

}

Is there something with my formula for grayscale?
grayscale=0.299*rSum + 0.587*gSum + 0.114*bSum;

Drag and Drop Using the CFSTR_FILEDESCRIPTOR / CFSTR_FILECONTENTS Formats

Steve Thresher18-Aug-04 4:48

Steve Thresher

18-Aug-04 4:48

Is there a standard way to attach a description to the data being dragged. I require this as the name of the data being dragged can include characters that are invalid in filename field of the FILEGROUPDESCRIPTOR structure (such as slashes or question marks) and I would like to be able to extract the description when the data is dropped. It would appear Outlook just replaces the invalid characters with blanks when creating the filename and then specifies the full name (subject text) as an additional Object Descriptor format.

Systems AXIS Ltd - Software for Business ...

new in dll, delete in exe, bang :(

Rüpel18-Aug-04 3:42

Rüpel

18-Aug-04 3:42

hi,

i'm writing a (legacy, non-MFC) dll and there might get an exception thrown in there. it is caught in the exe-file that uses that dll.

dll:

//some error<br />
throw new CSomeException();

exe:

catch (CSomeException *e)<br />
{<br />
  e->SomeFunction(); // works fine<br />
  delete e; // crash<br />
}

the delete-call crashes because the object is not a valid *local* heap-pointer.

stepping in dbgheap.c reveales the following passage

/*<br />
 * If this ASSERT fails, a bad pointer has been passed in. It may be<br />
 * totally bogus, or it may have been allocated from another heap.<br />
 * The pointer MUST come from the 'local' heap.<br />
 */<br />
_ASSERTE(_CrtIsValidHeapPointer(pUserData)); // fails

so, finally. how am i supposed to handle this? i mean throwing an exception in a library isn't that uncommon, is it? Confused | :confused:

:wq

Re: new in dll, delete in exe, bang :(

Nemanja Trifunovic18-Aug-04 3:58

Nemanja Trifunovic

18-Aug-04 3:58

I bet at least one of your modules (exe or dll) has CRT statically linked. That means that one instance of CRT is allocating the memory and another one tries to release it ... BANG!

A solution is to link all your modules dinamically (option /MD) against CRT. This way they will share the same CRT instance, and you should be able to allocate memory in one module and release it in another.

Either that, or make sure that each module cleans its own memory.

My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.

Re: new in dll, delete in exe, bang :(

Rüpel18-Aug-04 4:22

Rüpel

18-Aug-04 4:22

bingo! the DLL was set to /MT[d] - I changed that to /MD[d] and it seems to work (just gave it a quick shot)

thx, man! Rose | [Rose]

:wq

Re: new in dll, delete in exe, bang :(

Ravi Bhavnani18-Aug-04 4:13

Ravi Bhavnani

18-Aug-04 4:13

If my memory serves me right, an object new'd by a regular MFC DLL must be destructed by that DLL. An object new'd by an extension MFC DLL can be destructed by the client. See this[^] article.

/ravi

My new year's resolution: 2048 x 1536
Home | Articles | Freeware | Music
ravib@ravib.com

bitmap file format

peterworth18-Aug-04 3:21

peterworth

18-Aug-04 3:21

i am reading the first 14 bytes of a bitmap into a struct like this:

struct bmfh
{
unsigned short int bfType;
unsigned long int bfSize;
unsigned short int bfReserved1, bfReserved2;
unsigned long int bfOffBits;
};

and the results come out like this:

type: BM
size: 5
reserved1: 0
reserved2: 1078
bit offset: 3452764160

surely the size and offset cant be correct, does anyone know what i'm doing wrong? other bitmaps give similar values.

C^hris L^osinger18-Aug-04 4:27

18-Aug-04 4:27

what are the first 14 bytes of the file? (you look at it in VC, if you open it as a "binary" file)

Software | Cleek

Anonymous18-Aug-04 4:46

Anonymous

18-Aug-04 4:46

aha, i didnt know you could do that in vc++..

42 4D 9A 31 08 00 00 00 00 00 36 04 00 00

C^hris L^osinger18-Aug-04 4:54

18-Aug-04 4:54

any reason you're not using MS's BITMAPFILEHEADER struct?

when i do this:

<br />
BYTE buf[14] = {0x42 ,0x4D ,0x9A ,0x31 ,0x08 ,0x00 ,0x00 ,0x00  ,0x00 ,0x00 ,0x36 ,0x04 ,0x00 ,0x00 };<br />
BITMAPFILEHEADER *b = (BITMAPFILEHEADER *)buf;<br />

the values look fine:

bfType: 19778 ('BM')
bfSize: 536986
bfReserved1: 0
bfReserved2: 0
bfOffBits: 1078

-c

Software | Cleek

Anonymous18-Aug-04 4:57

Anonymous

18-Aug-04 4:57

hmm, thats what should happen with mine. i'm just using my own struct to better understand the file format and stuff. as far as i can see, mine is identical to the microsoft one..

C^hris L^osinger18-Aug-04 5:03

18-Aug-04 5:03

are you using the 'pack' pragmas to ensure the members of your struct are aligned correctly?

ie.:

<br />
#pragma pack(2)<br />
typedef struct tagBITMAPFILEHEADER {<br />
        WORD    bfType;<br />
        DWORD   bfSize;<br />
        WORD    bfReserved1;<br />
        WORD    bfReserved2;<br />
        DWORD   bfOffBits;<br />
} BITMAPFILEHEADER, FAR *LPBITMAPFILEHEADER, *PBITMAPFILEHEADER;<br />
#pragma pack()<br />

-c

Software | Cleek

Anonymous18-Aug-04 5:08

Anonymous

18-Aug-04 5:08

that works perfectly now, could you explain what this pragma pack nonsense is all about and what it does?

thanks very much for your help.

C^hris L^osinger18-Aug-04 5:14

18-Aug-04 5:14

#pragma pack(n) tells the compiler to arrange your structs so that the struct members each start on addresses that are multiples of 'n'. your problem was that the members of the struct weren't in the right places to be filled by your file read function, because they weren't aligned the way you assumed they were.

the default packing size is 8; so, in effect, each member of a struct takes a minimum of 8 bytes. you can change this on a project-wide level in Project / Settings / C/C++ / Code Generation, or on specific structs using the #pragma pack constructs.

this is one of those things we all have to learn the hard way, since it's not exactly well-advertized Smile | :)

Software | Cleek