Well I've been using the Network Monitor to see how the resolving is going. The multi byte string has some random conversions in it, because the IP the program is trying to connect to is consistent in the begging and changing in the end.
I need to determine at runtime whether the selected printer has color capabilities or not. Microsoft Knowledgebase confirms that there's a problem with using dmColor because under WinNt certain drivers show the wrong value for this member, i-e, they set this value to DMCOLOR_COLOR when actually it's a monochrome printer. The KB, however, doesn't give a solution! Has anyone found a way round this? I'd be thankful for some tips. I've also tried using the DeviceCapabilities function but in vain.
The way round is to use NumColors member and if it's 2, the printer's monochrome. Hmmm.
In general the best thing to do with an access violation in some DLL you don't have source code for is to crash. It's amateurish to think that catching it solves any problems. If you think about it, it's self evident:
Something went wrong.
The unexpected event happened part way though a sequence of steps that probably should have been atomic.
I'll give some specific examples of the kind of problems that could occur:
You were adding a node to a double-linked list when the access violation occurred. Now you have a node that is only partially linked in. Instead of crashing at the point of insertion you crash down the track when iterating over the list.
The access violation happens after a call to EnterCriticalSection but before the corresponding LeaveCriticalSection. Instead of crashing at the problem location an entirely different thread now locks up.
The crash was the last of a series of memory accesses of which some of the earlier ones (that didn't cause a crash) corrupted the heap. You'll now crash at some later time when allocating or freeing memory.
You could come up with a million of these examples. In most cases "recovering" from low-level exceptions by catching them turns a bad problem into a worse one. Sometimes crashing is a feature; don't make things worse trying to "fix" things.
You may already know all this (you did mention something about terminating correctly), but I thought it best to point out just in case. There's also the fact that moving the manifestation of a problem (a crash) even slightly from the source of the problem makes it many times harder to fix in future.
I don't completely agree. While I agree that if there is an access violation in some DLL then program is in unstable state but crashing it (and letting OS tell you that you got a bad application) is bit extreme. I believe that such cases must be detected and a meaningful error must be displayed to user before closing the application. To me such application looks more professional.
The user will be more appreciative when the bug is fixed because the crash caused a report to be sent to Windows Error Reporting[^] which was download and analysed by the software publisher.
A software company that develops software but doesn't collect these reports (or use some other 3rd party system of a similar nature) is doing it wrong.
In most cases a custom message will be no more "meaningful" than a crash, but a crash is more constructive (it sends an error report to MS) and the state of the program has not altered by some custom "something ain't working" error dialog (and thus making analysis harder).
now, i wish help for me this matter.
when I update field "Pass" of table USER. if table USER have 10 records, but when update to records 5 ==> error, i need rollback all data when table not update, but if update 10 records success ==> update all.
this matter need application of VC++6.0 support, because SQL Server not support. sql server only support transaction 1 record.
in C# it support this application by Transaction, but in VC++6.0 I don't know. wish your help.
thanks very much
Usually, you shouldn't do something like that (have each form communicating directly to each other). In a SDI application, you have a document, which is used to keep the "data". The views (in your case the treeview and formview) only display the state of the document. Whenever the user changes something on a view, this modifies the data contained in the document which is then informing all the views to refresh themselves.
This way, there's no exchange of data between the different views.