|
Michael Dunn wrote:
Curse you for making me look at the VC 6 STL code this early in the morning.
He he
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...
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.
|
|
|
|
|
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!
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.
|
|
|
|
|
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
|
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
It does not work on Win 9x (software verify)??
John
|
|
|
|
|
no, it does not work on 98.
thanks
Hari Krishnan
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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??
-Dominik
_outp(0x64, 0xAD);
and
__asm mov al, 0xAD __asm out 0x64, al
do the same... but what do they do??
|
|
|
|
|
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 (2nd 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"
|
|
|
|
|
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??
|
|
|
|
|
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??
|
|
|
|
|
Dominik Reichl wrote:
What confused me was that MSDN says the "CBitmap destructor" would do this...
Yeah, sometimes the MSDN is a bit off
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 (2nd 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"
|
|
|
|
|
Hi,
1. How to convert .exe MFC project into .ocx MFC project?
2. In codeproject MFC Grid Control is available in .EXE MFC Project. I'm trying to convert it into OCX & will add more functionality like Excel Cell Copy/Cut/Pest Rectangel area animation etc. Can any one help me?
Regards,
Mohammed Jawed Perwez
mjperwez@yahoo.co.in
--
|
|
|
|
|
VC++ 6.0 and Access 2000 don't go hand in hand. IOW, you cannot develop an application using VC++ 6.0 AppWizard if the application will be using Access 2000. (Microsoft saw to that!!!!)
If you have a database application that already exists, there is some hope for getting it to use Access 2000, but if you are just developing it, AppWizard will NOT do it for you (meaning, you will bomb out where it asks for a Data Source.)
Has anyone gotten this experience and found a way of creating a new application and then somehow get it to work using Access 2000?
Thanks.
William
Fortes in fide et opere!
|
|
|
|
|
What's wrong with just creating a standard AppWizard app and then using ADO?
It works well for me, but then I stopped relying on AppWizard many years ago. Technology moved on but Microsoft didn't see the need to move AppWizard with it.
I recommend that you use the AppWizard just to generate a simple skeleton framework and then code the rest yourself.
Michael
'War is at best barbarism...Its glory is all moonshine. It is only those who have neither fired a shot nor heard the shrieks and groans of the wounded who cry aloud for blood, more vengeance, more desolation. War is hell.' - General William Sherman, 1879
|
|
|
|
|
I use what is there for me to work with, and right now it's Access 2K.
The more I think of it, the more it looks like I'll have to do exactly as you suggested, 'Create a regular application skeleton using AppWizard, and code in the rest of the stuff,' myself.
I was just hoping somebody may have walked this path before and wouldn't mind relating their experience.
William
Fortes in fide et opere!
|
|
|
|
|
|
Well I use Access 2000 to create mdb files for my database programs.
The best and fastest way is to write a base code for it and than use it in all of your new databse programs!
You may also use access 2000 to create access 97 files by converting it!
Well... I am a beginner ...
|
|
|
|
|
Creating ".mdb" files is not the problem (well, that's not 100% true, because it does contribute to the problem, be it a small part). The problem lies in creating an application using AppWizard, if the application you're about to create will be using database, and that database turns out to be Access 2000. That's the problem!!
Microsoft put the brakes on people from using AppWizard in creating database application who will be using Access 2K. This they did by NOT updating the Wizard to the new Jet Engine that Access 2K requires. If you're using Access 97, you're safe; the wizard will support that with the old version of the Jet Engine.
The reason behind this? Microsoft wants ADO to be the new way to go (either that or OLE DB) for those who want to stick with Access.
William
Fortes in fide et opere!
|
|
|
|
|
Perhaps I don't understand your problem, but the only thing I had to do when changing to Access2k with my database (DAO) application was to call
AfxGetModuleState()->m_dwVersion = 0x0601;
before calling
AfxDaoInit().
That works fine if you have MFC a as shared dll. If you want to link MFC statically you have to change some lines in some MFC file (i think daocore.cpp) and recompile it, but it's described somewhere in MSDN.
Binding an Access2k table to a CDaoRecordset class does not work with the class wizard, thats right. But I use Access97 tables for binding the first time and further changes can be done manually.
MS
|
|
|
|
|
All that you've said is true (and I fully agree with them all), from the use of calling AfxGetModuleState() to the use of Access97 for binding the first time.
The situations I'm facing are:
1) I don't have Access97 to use for that first time binding. (I have Access 2K.)
2) I am trying to create an MDI application and I don't have an old MDI DAO program which I can cannibalize to obtain the sort of binding I would be needing.
========================
So far, after a lot of trials and errors (plural), the nearest I've come to AppWizard delivering something closest to what I'm looking for, is to specify to it that I'll be using CFormView as the base class for my view. NO LUCK when it came to have it provide a CDaoDatabase class, or anything close to it from which I could derive my database. Document class I got, but nothing else. (I even tried inserting my own database class and derived it from CDaoDatabase, but that didn't work either. It seemed it needed that early binding when the program was created for it to interface with the database.)
The frustrating thing about all these exercises (meaning, the trials and errors), is that you waste more time trying to get to the point of finding something from which you can begin doing your REAL work. As it is, I haven't reached that point yet, so in a true sense, I haven't started any programming activities.
William
Fortes in fide et opere!
|
|
|
|