Oh, puh-leeze. Everyone knows that's he asking for information on a booking program to help with international trade.

Visual Studio Favorites - www.nopcode.com/visualfav - improve your development!

Gee, dunno, wonder why Blockbuster is even bothering to stay open then. PS: freebie rental 2:1 here. You're welcome.

Visual Studio Favorites - www.nopcode.com/visualfav - improve your development!

[cheapshot] Microsoft and security [/cheapshot]

Visual Studio Favorites - www.nopcode.com/visualfav - improve your development!

Aww, damn, beat me to it! :mad:

Visual Studio Favorites - www.nopcode.com/visualfav - improve your development!

Wired has a piece on Bob Bemer, who claims he invented the concept of hyperlinks (aka escape sequence). Hmm. Maybe I'll patent/trademark that one. Surely nobody has thought of it before!) I agree with the general concept that the patent office needs to be taken out and flogged.

Visual Studio Favorites - www.nopcode.com/visualfav - improve your development!

Actually SP6.89999 - close but not quite it. :-D

Visual Studio Favorites - www.nopcode.com/visualfav - improve your development!

It may be his intent and belief, but not Microsoft's. More than likely Stanley is not let in everything that is really going on over there. And in any case, get back to MFC you heathen! MFC rulez d00d! STL sukz! :-D

Visual Studio Favorites - www.nopcode.com/visualfav - improve your development!

Here is a technical overview of .NET at Ars Technica. Pretty good read, answers some questions I'm sure all of you might have.
In a remarkable feat of journalistic sleight-of-hand, thousands of column inches in many "reputable" on-line publications have talked at length about .NET whilst remaining largely ignorant of its nature, purpose, and implementation. Ask what .NET is, and you'll receive a wide range of answers, few of them accurate, all of them conflicting. Confusion amongst the press is rampant.
The more common claims made of .NET are that it's a Java rip-off, or that it's subscription software. The truth is somewhat different.

Visual Studio Favorites - www.nopcode.com/visualfav - improve your development!

No shock there - Microsoft is simply trying to keep everyone within their technology camp (VB & C#). C++ is cross platform, so why support it?

Visual Studio Favorites - www.nopcode.com/visualfav - improve your development!

Brings a new meaning to the phrase "bought their silence". Nobody else but Microsoft would dare do this on this kind of scale.

Give the user the option to turn this on and off (Help menu->Autocheck for updates). Make your dialog very clear that no personal information is sent back. Give the user the option via the help menu to manually check for updates (ala Windows Update). Other than that, sounds ok. --------------------------------------------- Todd Wilson (tw@nopcode.com) www.nopcode.com ICQ: 5638028 "I picked up a Magic 8-Ball the other day and it said 'Outlook not so good.' I said, 'Sure, but Microsoft still ships it.'"

This is probably true, and if I was doing something that uses DB stuff, I probably would, but there doesn't seem to be any other fixes to MSVCRT, MFC, or ATL. It doesn't seem like a super-important service pack like SP3 was (and SP4 to some degree). Plus you can always link static or else ship the dlls you need in your exe folder. --------------------------------------------- Todd Wilson (tw@nopcode.com) www.nopcode.com ICQ: 5638028 "I picked up a Magic 8-Ball the other day and it said 'Outlook not so good.' I said, 'Sure, but Microsoft still ships it.'"

Be sure to include the header with the 'extern' wherever you are going to use it. Or stick the header include in your stdafx.h

Like this (applies to C++ not just MFC): yourcode.h: extern globalVariableType YourGlobalVariable; yourcode.cpp: globalVariableType YourGlobalVariable; This is freqently use for making the MFC CWinApp class global like this: extern CMyApp theApp; (this is because theApp is already defined in your MyApp.cpp file by MFC). This nicely replaces: ((CMyApp*)AfxGetApp())->Bogus(); with: theApp.Bogus(); Hope this helps -------------------------------- Todd C. Wilson (tcw@nopcode.com) www.nopcode.com ICQ: 5638028 "I picked up a Magic 8-Ball the other day and it said 'Outlook not so good.' I said, 'Sure, but Microsoft still ships it.'"

ZoneAlarm (blocks outgoing unless you allow it, some incoming) and BlackIce (blocks incoming). Get a hardware firewall - DLink has one that does both DSL/Cable and modem (dialup) - which is better than BlackIce IHMO. If you do find spyware running, email the vendor and get in their face about it.

Color me confused, but did anyone see in the readme for the thing as to why one would bother with this? I read the readme and the knowledge base files on what was changed, but all the stuff revolves around database stuff, even the ATL fixes. I've been running SP3 and SP4 and haven't had any problems.

Heck it doesn't remember it under IE55 either. I think I spotted your problem; it's in the loop: for (int i=0;i<500;i++) { CPen pen; pen.CreatePen(PS_SOLID, 1, RGB(0,0,0)); dc.SafeSelect(&pen); /* Okay, here is the problem as I see it: the first time this is called, there is no pen to release, so the pen handle is selected into the device context, which basically takes ownership of it. Then your loop exits, and the CPen object is destroyed, taking the handle with it - but more than likly just a COPY of the handle, leaving the other one still selected into the device context, since it was never selected out. Then the 2nd time into the loop you create a new CPen, and then select it in, but you never got rid of the other one. */ } I've never written code like this; I've always done it like, the scope of the function: CPen *pOldPen = dc.SelectObject(&pen); ...dowhatever.... dc.SelectObject(pOldPen); If I was going to attempt to re-write the SafeSelect, I would probably NOT do it like this (IMHO), but instead, make a helper class (or nested class) that does the need balanced SelectObject's on construct and destruct.

Ah, but it is portable - see Inside the C++ Object Model (S. Lippman), pages 121-124. Static functions are managled internally into non-class functions. "Taking the address of a static memmber function always yields the value of its location in memory, that is, its address. Because the static function is without a this pointer, the type of its address is not a pointer to a class member function but the type of a nonmember pointer to function." Sadly, the ARM doesn't give more than a trivial explanation of static data and functions, other than they have "external linkage". What reference were you using for the undefiend functionality? In any case, you can work around the private/protected problem like this: void bogus(void *ptr) { ((Fred*)ptr)->publicBogus(); } class Fred { public: void publicBogus() { ; /* do the real work here */ } };

Modify your SafeSelect functions like this: if (m_pOldPen!=NULL) SelectObject(m_pOldPen); if (pPen!=NULL) m_pOldPen = SelectObject(pPen); else m_pOldPen=NULL; return m_pOldPen; Same for the brush version. Now, if you are detaching the DC handle from the CDC base class, then your destructor is worthless, since the DC handle is gone. The other problem is that I did not see a constructor for your CGDC class. Assuming that you're using the base CDC, then the DC handle is null, and SelectObject will either (a) do nothing (b) bomb (c) leak. Just my $0.02

I'm surprised that what you've done works. _beginthread takes three parms: address of the thread functions stack size arg list pointer What you're doing is completly non portable: you're using the 'this' pointer as the arg list and praying that Borland compiler will put it into the correct register and fake it for you. If you look at what your lpParm value is and compare it to what was passed as 'this' in your beginthread, it will be probably the same, but what happens when you compile in release mode? Plus you're also taking into account the memory layout of the union on your compiler to be the same on all compilers; it may not, since you have two different data types - one the address to a non-class function, and one an address to a scoped class function. Bet this will puke in IA64 and maybe other compilers. Bet the Intel c++ compiler will go completly nuts on you with this code. Simplest, portable solution: class Fred public: static void _Thread(void*pThis) { Fred*pFred=(Fred*)pThis; pFred->ThreadFunc(); } void ThreadFunc() { ;/*whatever*/ } void StartThread() { _beginthread(&_Thread,0,this); } }; Note that this is the same as a lot of the callback stuff you'll get from the SDK. Lot cleaner, simpler to understand & teach newbies, and a hell of a lot easier to maintain! Just my two cents as always...