C / C++ / MFC

Re: Problem including commctrl.h.

4-Jul-03 4:41

make sure you have included "winnt.h" or "wtypes.h" first. Does this help?

Ryan

Being little and getting pushed around by big guys all my life I guess I compensate by pushing electrons and holes around. What a bully I am, but I do enjoy making subatomic particles hop at my bidding - Roger Wright (2^nd April 2003, The Lounge)

Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late - John Nichol "Point Of Impact"

blackmesa4-Jul-03 4:45

blackmesa

4-Jul-03 4:45

After including wtypes.h, I have no more errors. Thanks a lot guys.

Cheers, nickelplate.

Re: Problem including commctrl.h.

Ryan Binns4-Jul-03 4:55

4-Jul-03 4:55

You're welcome Smile | :)

Ryan

Being little and getting pushed around by big guys all my life I guess I compensate by pushing electrons and holes around. What a bully I am, but I do enjoy making subatomic particles hop at my bidding - Roger Wright (2^nd April 2003, The Lounge)

Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late - John Nichol "Point Of Impact"

Wide iostreams

Taka Muraoka4-Jul-03 4:06

4-Jul-03 4:06

You would think that the following bit of code would produce a 6-byte file:

wofstream f( "test.txt" ) ;
f << wstring( L"123" ) ;

But it doesn't. It produces a 3-byte file. A bit of experimentation indicates that the stream seems to be converting the wide characters to single-byte before writing it to the file. This also happens using Stlport (with their iostream library).

This seems just plain wrong. Anyone care to explain why it's like this?

Always code as if the person who ends up maintaining your code will be a violent psychopath who knows where you live.

Awasu 1.1[^]: A free RSS reader with support for Code Project.

Michael Dunn4-Jul-03 5:17

Michael Dunn

4-Jul-03 5:17

Curse you for making me look at the VC 6 STL code this early in the morning. Wink | ;)

The fstream inserter eventually calls basic_filebuf::overflow(), which has this line:

fwrite(_Str->begin(), 1, _N, _File)

The problem is that it writes 1 byte, when it should write sizeof(_E) [where _E is the template character type, wchar_t in this case].

--Mike--
"So where does that leave us? Well, it leaves us right back where we started, only more confused than before." -- Matt Gullett
Ericahist | Homepage | RightClick-Encrypt | 1ClickPicGrabber

Ryan Binns4-Jul-03 5:21

4-Jul-03 5:21

Michael Dunn wrote:
Curse you for making me look at the VC 6 STL code this early in the morning.

Laugh | :laugh:

Taka sent that message after midnight on a Friday night, so I don't want to know what he was thinking Wink | ;)

Taka Muraoka4-Jul-03 12:41

4-Jul-03 12:41

Ryan Binns wrote:
Taka sent that message after midnight on a Friday night, so I don't want to know what he was thinking

I'm converting Awasu to Unicode. My life is over until further notice Cry | :((

Actually, it's not quite that bad. Most of it is ready for Unicode but there are some core modules that I wrote years ago that need to be converted. Of course, *everything* uses them...

Always code as if the person who ends up maintaining your code will be a violent psychopath who knows where you live.

Awasu 1.1[^]: A free RSS reader with support for Code Project.

Taka Muraoka4-Jul-03 13:00

4-Jul-03 13:00

Michael Dunn wrote:
Curse you for making me look at the VC 6 STL code this early in the morning.

He he Smile | :)

Michael Dunn wrote:
fwrite(_Str->begin(), 1, _N, _File)

Yep. The odd thing is, Stlport does the same thing i.e. even when I use their iostreams instead of Microsoft's. They correctly process each character as 16-bit but then explicitly call codecvt to convert it 8-bit!

Which makes me wonder if this is what is supposed to happen. If this is a bug, it's a pretty obvious one and someone would've picked it up. Seems definitely wrong to me... Frown | :-(

Always code as if the person who ends up maintaining your code will be a violent psychopath who knows where you live.

Awasu 1.1[^]: A free RSS reader with support for Code Project.

Taka Muraoka4-Jul-03 15:08

4-Jul-03 15:08

This is just fscked!!!

According to this guy[^]:

The standard *does not* provide a way to output (i.e.: to write on a disk file) a stream of wide characters. You can put wide characters into a wide stream but you will always obtain a file of "narrow" characters, obtained through a "degenerate conversion" as explictly specified in the standard.

Also here[^]:

On Win32, VC++ 6sp5, STLport the following test program produces the output 52 (0x34) instead of 4660 (0x1234). According to the standard, this behaviour is perfectly conformant.

int main() { wchar_t a = L'\x1234'; std::wofstream out("test.txt", std::ios::binary); out << a; out.close(); std::wifstream in("test.txt", std::ios::binary); in >> a; in.close(); std::cout << unsigned(a) << std::endl; return 0; }

(The second poster also makes the interesting point:
the ios::binary is required, because the I/O library could apply CRLF translation to a part of a two-byte character.
)

This makes no sense. What possible justification could there be to have wide streams output narrow?! The only thing I can think of is possible problems with sending wide data to the console, for example, but surely it would be preferable to hack wcout et.al. rather than crippling wide streams! WTF | :WTF:

Always code as if the person who ends up maintaining your code will be a violent psychopath who knows where you live.

Awasu 1.1[^]: A free RSS reader with support for Code Project.

memory leak

pranavamhari4-Jul-03 3:31

pranavamhari

4-Jul-03 3:31

hi,

i need help from you guys again.

My program uses classes like CButtonST, AnyFormDialog, etc.
I am not blaming these classes, but i think my program is leaking memory. (found out using system monitor). when app closes, the memory is not released to the point where it was when launched.

now the question is how can i detect where in my application memory leaks? any free third party utilities ?

BTW, it leaks in ME, not in XP.

thanks for your reply.

Hari Krishnan

John M. Drescher4-Jul-03 3:53

John M. Drescher

4-Jul-03 3:53

Try http://www.softwareverify.com/download_eval.php[^]

You can get a free 30 eval which should be enough to solve your problem.

John

pranavamhari4-Jul-03 19:05

pranavamhari

4-Jul-03 19:05

thanks,

but as i said, it does'nt leak in XP. So i can't use this in my XP machine. It is leaking in ME only.

Also, i found out by trial and error that if i load the image from a file (~500KB) rather than a resource, it does'nt leak. Ofcourse i use DeleteObject() call at destruction when i load from resource.

regards

Hari Krishnan

John M. Drescher5-Jul-03 3:29

John M. Drescher

5-Jul-03 3:29

The thing I was going to tell you that is handled differently between windows NT ( NT 4, 2K, XP) and Win 9x is resources.

John

John

John M. Drescher5-Jul-03 3:30

John M. Drescher

5-Jul-03 3:30

It does not work on Win 9x (software verify)??

John

Whats true? MSDN or source code?

pranavamhari5-Jul-03 20:58

pranavamhari

5-Jul-03 20:58

no, it does not work on 98.

thanks

Hari Krishnan

COM passing

Anthony98874-Jul-03 3:27

Anthony9887

4-Jul-03 3:27

I want to be able to pass an ado object interface pointer from VB to my COM dll. Is this possible. How would I go about doing such a thing.

Thanks

Re: COM passing

valikac4-Jul-03 5:05

valikac

4-Jul-03 5:05

In theory, yes it is possible to pass pointers from and to COM DLL given that the DLL is in the program's address space.

As for practice, post some code. I am not familiar with VB. In general, one solution is to call a function in the DLL that takes a pointer to an interface as one parameter.

Kuphryn

Re: COM passing

Anthony98874-Jul-03 7:42

Anthony9887

4-Jul-03 7:42

Hi,

I'm trying to pass a _RecordsetPtr to my ATL COM method as a parameter. Except I'm not too sure how to do it. How would I pass the interface as you described.

Thanks

Dominik Reichl4-Jul-03 2:12

Dominik Reichl

4-Jul-03 2:12

Hello,

I am using CBitmaps for my bitmap objects. MSDN says that a bitmap loaded with the LoadBitmap member function will be freed automatically when the class is destructed:

You can use the CGdiObject::DeleteObject function to delete bitmap loaded by the
LoadBitmap function, or the CBitmap destructor will delete the object for you.

Now I had a look into the MFC source files and found the following lines in the file Afxwin1.inl

_AFXWIN_INLINE CBitmap::~CBitmap()
	{ }

So it seems the destructor does simply nothing???

Will my bitmap be freed on destruction of the CBitmap class or not??

Confused | :confused:

-Dominik

_outp(0x64, 0xAD);
and
__asm mov al, 0xAD __asm out 0x64, al
do the same... but what do they do??

Ryan Binns4-Jul-03 2:16

4-Jul-03 2:16

Dominik Reichl wrote:
Will my bitmap be freed on destruction of the CBitmap class or not??

It will. The bitmap gets destroyed in the destructor for CGdiObject, same as in other CGdiObject-derived classes.

Ryan

Being little and getting pushed around by big guys all my life I guess I compensate by pushing electrons and holes around. What a bully I am, but I do enjoy making subatomic particles hop at my bidding - Roger Wright (2^nd April 2003, The Lounge)

Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late - John Nichol "Point Of Impact"

Dominik Reichl4-Jul-03 2:23

Dominik Reichl

4-Jul-03 2:23

Ah, this destructor reads

_AFXWIN_INLINE CGdiObject::~CGdiObject()
	{ DeleteObject(); }

-Dominik

_outp(0x64, 0xAD);
and
__asm mov al, 0xAD __asm out 0x64, al
do the same... but what do they do??

Dominik Reichl4-Jul-03 2:25

Dominik Reichl

4-Jul-03 2:25

What confused me was that MSDN says the "CBitmap destructor" would do this...

-Dominik

_outp(0x64, 0xAD);
and
__asm mov al, 0xAD __asm out 0x64, al
do the same... but what do they do??

Ryan Binns4-Jul-03 2:29