|
There are several other ways that Windows destroys it windows. The alternate shutdown is in the WM_COMMAND message when the user clicks on the small *X* or closes from the toolbar. The paramater sent to WM_COMMAND is the IDCANCEL and IDOK default macros. Simply intercept these messages in addition to WM_DESTROY and call the same exit procedures that you have setup for WM_DESTROY. Both IDOK and IDCANCEL are always Windows specific so if you do not program these in then they will call for the Window to destroy without saving any work including freeing memory. IDCANCEL and IDOK, though, is pretty generic so you might want to consider calling the DestroyWindow( HWND ) yourself in addition.
|
|
|
|
|
Check out the WM_QUERYENDSESSION and WM_ENDSESSION messages.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
Thank you David, WM_ENDSESSION did the trick.
MS
|
|
|
|
|
hi,
my code is working well when i am working in debugging mode but if i set configurations to release mode it gives some unhandled memory location exceptions during run time. what could be the possible reasons for this error??
can anyone please help me.
thanks!
ramya.
|
|
|
|
|
Hi Ramya...
Hope explains u the problem....
Q: My program works fine in debug mode, but fails in release mode. Why? And what can I do about it?
A: First of all, there is no such thing as 'debug mode' or 'release mode'. The VC++ IDE offers the possibility to define configurations which include a set of project settings (like compiler / linker options, output directories etc.) When a project is created using AppWizard, you get two default configurations: "Win32 Debug" and "Win32 Release". These are just convenient starter configurations whith several preset options which are suitable for debug build or release builds respectively, but you are by no means restricted to those settings. Actually, you can modify those configurations, delete them, or create new ones. Now let's see what the two default configurations typically include and what distinguishes them:
Win32 Debug:
Subdirectory 'Debug' used for temporary and output files
Preprocessor symbol _DEBUG defined
Debug version of the runtime libraries is used
All compiler optimizations turned off
Generate debug info
Win32 Release:
Subdirectory 'Release' used for temporary and output files
Preprocessor symbol NDEBUG defined
Release version of the runtime libraries is used
Various compiler optimizations turned on
Generate no debug info
There are a few other differences, but these are the most important ones. Now, what's the first implication of all this? That, as opposed to a common misunderstanding, you can debug a release build. Just go to Project -> Settings, choose the Win32 Release configuration, tab 'C/C++', 'General' and set 'Debug Info' to 'Program Database'. Then go to the tab 'Linker', and turn on 'Generate Debug Info'. If you rebuild your project now, you will be able to run it in the debugger. Regardless of whether you program crashes or just doesn't behave as expected, running it in the debugger will show you why. Note however, that due to optimizations turned on in the release build, the instruction pointer will sometimes be off by a few code lines, or even skip lines altogether (as the optimizer didn't generate code for them). This shouldn't be a concern, if it is, turn off optimizations.
When debugging your release build this way, you will probably discover that at a certain point during execution, a variable has a different value in the release and in the debug build, causing the differing behaviour. And if you go back and see where the value of that variable is set, you will most probably find out that it isn't: You simply forgot to initialize that variable. The reason why the debug build seemed to work is that the debug version of the runtime library initializes dynamic memory and stack variables to known values (in order to track down memory allocation and overwrite errors), while the release version of the runtime library doesn't. This is by far the most frequent single cause for different behaviour between debug and release builds, so chances are good that this fixes your problem (and for the future, remember to always initialize your variables).
If uninitialized variables were not the cause of your problem, let's look at the next possible difference between debug and release builds: The preprocessor symbols _DEBUG and NDEBUG. If you have any code inside an #ifdef _DEBUG / #endif block, it will not be contained in a release build. What's worse, the dependency of those symbols can be hidden inside other macros. A typical candidate for this is ASSERT: It expands to the assertion testing code if _DEBUG is defined, and to nothing if it is not. Therefore, be careful to have no code with side effects inside an ASSERT macro. For example, the following code will work in a debug build, but fail in a release build:
code:--------------------------------------------------------------------------------CSomeDialog dlg;
ASSERT(dlg.Create(IDD_SOME_DLG));
dlg.ShowWindow(SW_SHOW);--------------------------------------------------------------------------------
As a rule, never put code which needs to be executed inside an ASSERT. (A side note: Conditions which can be expected to fail at runtime, like the Create() call in the example, should never be tested with ASSERTs anyway. Assertions are a tool to assert pre- and postconditions regarding your code, not runtime error conditions.)
At this point, you have most probably found out why your code failed in the release build. If not, this might be one of the very rare cases where the compiler optimizations caused your code to behave differently (the VC++ compiler had several optimizer bugs in the past, and I doubt they have all been fixed). To exclude this, first turn all the optimizations off (Project -> Settings, tab 'C/C++', category 'Optimizations', option 'Disable (Debug)'). If your code works now, selectively turn optimization options on until you found the culprit. Simply leave it turned off, or upgrade to a newer version of the compiler (or install the most recent service packs) which might hopefully fix that bug.
This should help you get your release build running in most of the situations. For a more in-depth discussion about the differences between debug and release builds, see the excellent article Surviving the Release Version on codeproject.com.
With Best Regards,
A.Ilamparithi
|
|
|
|
|
See if this article helps.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
In Oct. 2002 Microsoft wrote in part:
NetBIOS LANA Numbers
Windows XP Certain legacy networking protocols, including NetBEUI, will no longer be supported. For more information, see Network Protocol Support in Windows.
The NetBIOS LANA number identifies the transport driver, network interface card (NIC) driver, and adapter that will be used to send and receive NetBIOS packets. This is known as the network route. The following example shows the network route that will be used when you specify a LANA value of 1:
001 NetBT -> IEEPRO -> IEEPRO1
Specify the LANA number in the ncb_lana_num member of the NCB structure when you issue a NetBIOS command.
The IBM NetBIOS 3.0 specification supports only two LANA numbers, because NetBEUI was originally the only protocol that supported NetBIOS, and a computer could contain only two network adapters at that time. Specifying LANA 0 directed a command to the first adapter, and specifying LANA 1 directed a command to the second adapter. Because many computers had only one network adapter, many MS-DOS based applications sent all their requests to LANA 0. If a second network adapter was installed, some applications allowed the user to specify the use of LANA 1 instead. As a result, LANA 0 became the default setting, though it was never intended as such.
Windows NT/Windows 2000/Windows XP enables NetBIOS to use transport protocols other than NetBEUI. Therefore, Microsoft has extended the meaning of a LANA number to indicate a specific transport protocol on a specific adapter. For example, if you have two network adapters, and have three transport protocols installed, you have six LANA numbers. The LANA numbers are not necessarily sequential.
In addition to extending the meaning of a LANA number, Microsoft also added the NCBENUM command to enumerate the available LANA numbers. As an example, the LANA_ENUM structure filled by NCBENUM might hold an array with values 0, 3, 5, and 6. Zero might map to IPX/SPX on the first adapter, three might map to a different protocol on a second adapter, and so on.
Windows 2000/XP: You cannot configure LANA numbers on these platforms.
Windows NT: You can associate specific LANA numbers with specific network routes using the following steps.
To associate a LANA number with a network route
Start the Network Control Panel application.
Click the Services tab.
Double-click NetBIOS Interface.
Click the LANA number you want to change.
Enter the new LANA number to be associated with the network route.
Windows 95/98/Me: You cannot configure LANA numbers because of the way plug and play was designed. LANA numbers can change as users install plug and play devices. You may set only LANA 0, which is the default protocol. The next protocol is LANA 7, then LANA 6, and so on. If no protocol is set as the default, there may not be a LANA 0.
You can set the default protocol in the control panel using the following steps:
To set LANA 0 on Windows 95/98/Me
Start the Network Control Panel application.
Choose the protocol you want as the default.
Click Properties.
Click the Advanced tab.
Click Set this protocol to be the default protocol.
The best way to write a NetBIOS application is to support all LANA numbers, and establish connections over any LANA number. This allows your application to transparently support any transport protocol that supports NetBIOS, as well as dynamic LANA numbers associated with dial-up adapters or plug-and-play hardware. A good approach is outlined in the following steps.
To support connections over any LANA
Enumerate the LANA numbers by issuing an NCBENUM command.
Reset each LANA by issuing one NCBRESET command per LANA number.
Add your local NetBIOS name to each LANA. The name may be the same on each LANA.
Connect using any LANA number:
For servers, issue an NCBLISTEN command on each LANA. If necessary, cancel any outstanding listen operation after the first listen operation has been completed.
For clients, issue an NCBFINDNAME (Windows NT/Windows 2000/Windows XP only) or an NCBCALL (Windows NT/Windows 2000/Windows XP or Windows 95/98/Me) command on each LANA. The first successful NCBFINDNAME or NCBCALL operation will indicate which LANA to use. When using NCBCALL instead of NCBFINDNAME, you must cancel any pending NCBCALL commands and hang up any extra completed calls.
Though this is the best technique for writing a NetBIOS application, it generates several datagrams, making the NetBIOS interface less desirable than other networking interfaces.
End of Microsoft White paper.
OK if I want to grab a MAC number and I get the os type of say XP how do I enumerate the the LANA numbers.
Should I use 0?
Best Wishes,
ez_way
|
|
|
|
|
Hi..
I think i can help you in this regard,because iam working in this area for past 2 months...
But i dont understand your question properly...
Can u pls explain it little more clearly... What exact you want to do?
Is it, to find the MAC address of a XP machine??
Waiting for your reply...
With Best Regards,
A.Ilamparithi
|
|
|
|
|
Yes please do help, no just not XP but any machine, just wanted to understand how to use LANA numbers or just set them to zero and hope for just on nic.
|
|
|
|
|
Hi
first we must find the LANANUM.
LANA_ENUM lna;
NCB nb;
memset((void*)&nb,0,sizeof(NCB));
memset((void*)&lna,0,sizeof(LANA_ENUM));
nb.ncb_buffer = (UCHAR*)&lna;
nb.ncb_length = sizeof(LANA_ENUM);
nb.ncb_command = NCBENUM;
int hh = Netbios(&nb);
int iLanaNum=lna.lana[0]; // here we got the LANANUM
Then you must reset the NCB.
NCB ncb;
UCHAR uRetCode;
memset( &ncb, 0, sizeof(ncb) );
ncb.ncb_command = NCBRESET; // note NCBRESET to reset.
ncb.ncb_lana_num = iLanaNum;
uRetCode = Netbios( &ncb );
Then to find the status, here it is MAC Address, set the command as NCBSTAT.
TCHAR MacAddress[20];
_TCHAR host[16];
ncb.ncb_callname,"MODBUS " ); // here MODBUS is the host name.It must be exactly 15 characters long(Since Netbios names are always 15 characters long). Remaining pad it to spaces.
ncb.ncb_lana_num = iLanaNum;
ncb.ncb_buffer = (unsigned char *) &Adapter;
ncb.ncb_length = sizeof(Adapter);
ncb.ncb_command = NCBASTAT;
uRetCode = Netbios( &ncb ); // make netbios call
printf( "The NCBASTAT return code is: 0x%x \n", uRetCode );
if ( uRetCode == 0 )
{
printf( MacAddress,"%02x-%02x-%02x-%02x-%02x-%02x",
Adapter.adapt.adapter_address[0],
Adapter.adapt.adapter_address[1],
Adapter.adapt.adapter_address[2],
Adapter.adapt.adapter_address[3],
Adapter.adapt.adapter_address[4],
Adapter.adapt.adapter_address[5] );
It works well in all versions of Windows.
Regards,
A.Ilamparithi
|
|
|
|
|
My question,
I execute a ping to a device with the ShellExecuteEx, How can I know if the ping has been successfully??
thanks in advance
|
|
|
|
|
No don't do it that way, it is not a good practice. Look for article by Chris Maunder for MFC ping or just write a console app.
Best Wishes,
ez_way
Wait big error! It was not Chris it was P.J. Naughter in 1999. I made the mistake because they both look alike
|
|
|
|
|
I don't found the article by Chris Maunder, can you tell me the exact title??
thanks
|
|
|
|
|
hi
It is P.J. Naughter article...
Look at it!!!
With Best Regards,
A.Ilamparithi
|
|
|
|
|
No it was P.J. Naughter, and his url is http://www.naughter.com
he and chris worked together, well sort of at codeguru years ago.
|
|
|
|
|
How about a link?
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
the application sends this error when compiling, I am not using MFC, I use the Win Api 32 with #include <windows.h>, but the ping classe is designed for MFC, somebody has another solution for monitor a ping to a device?
c:\archivos de programa\microsoft visual studio\vc98\mfc\include\afxv_w32.h(14) : fatal error C1189: #error : WINDOWS.H already included. MFC apps must not #include <windows.h>
thanks
|
|
|
|
|
So you want a solution that does not use MFC. Is that correct? You could take what you already have and redirect it to a temporary file and then parse the contents of that file. Something like:
ShellExecute("ping a.b.c.d > ping.out", ...);
I don't know if this would actually work as I've not tried it, nor would I opt for this type of solution.
A more preferred solution would be to use the ICM protocol directly. Examples are plentiful.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
A numpty question I think
I declare a CList in my header (VC6)
public:
CList (less than)CString, CString&(greater than) wordList;
Compiles fine but when I go to use it in a helper function I get an error.
if (!AfxIsValidAddress(pOb, sizeof(CObject)))
{
TRACE0("ASSERT_VALID fails with illegal pointer.\n");
if (AfxAssertFailedLine(lpszFileName, nLine))
AfxDebugBreak();
return; // quick escape
}
If I then go and add the CList declaration into the helper function and comment
out the header declaration it all works fine.
Any Ideas?????
Confused!!!!
Dave
|
|
|
|
|
Why not just use the CStringList class?
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
Last time I just built my own linked lists using CStrings, I just thought this time I'd try one of the in built templates. The question is more why cant I use this when it is declared in my header but can if declared in the function it's being used in.
I'll have a look at CStringList though!!
Thanks, Dave.
Dave
|
|
|
|
|
Hi.
I need help for create in vc++.net/vc++6 .
When I create template class in vc++ it gives error.
My code is like this :
template <class t="">
class p : public q
....
(I already write it in c++5 , it worked right)
Thank you
|
|
|
|
|
What is the error?
- Mike
|
|
|
|
|
Is there any way of setting toolbar buttons text NOT TO ALL buttons? I mean, buttons which do have text, should have proper size, and buttons which DO NOT have text should be of standard size (something like 24x23 etc.) All my attempts to set button info via CToolbarCtrl::SetButtonInfo() were doomed to failure  .
|
|
|
|
|
Sure, if you can group your large an small buttons. Just add another toolbar with the larger buttons. Also if you wish to do it programatically you must leave MFC and build a win32 app.
Best Wishes,
ez_way
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
