|
One solution is to derive a class from CDialog and do custom creation. Otherwise, one solution is to overrite OnClose(), etc. and keep the window from losing focus.
Kuphryn
|
|
|
|
|
|
Hi All,
Is there is any get the detail about the network devices like,
Name : HPINKJET
Type : Printer
Sub type : Laser
Make :
Model :
Serial No :
MAC Address:
If anyone of you know, can you please help me.
Thanks.
Regards,
A.Ilamparithi.
|
|
|
|
|
what network device do u mean?
a shared printer, a print server?
Don't try it, just do it! 
|
|
|
|
|
Hi Alex...
Thanks for your interest.
By network device, i mean things like router, firewall, printer, etc..
Regards,
A.Ilamparithi
|
|
|
|
|
I execute a console process with the ShellExecuteEx, this process creates a file but it spends 4 o 5 seconds, my next code needs to access this file so I need to wait the end of the execution of my console process or wait 5 seconds until continue the program execution, how can i do that?
thanks
|
|
|
|
|
Add SEE_MASK_NOCLOSEPROCESS to the fMask member of your SHELLEXECUTEINFO structure. The process's handle will be returned in the hProcess member. You can then pass this to WaitForSingleObject, which will return when the process exits. You could also use one of the other XxxWaitForZzz functions.
Don't forget to call CloseHandle on the process handle once the WaitFor function returns.
An alternative is to use CreateProcess rather than ShellExecuteEx.
|
|
|
|
|
Hi ,
I wrote code in MFC , based on ActiveX component Microsoft Internet Explorer.
Purpose of that is to load images by IExplorer.
With JPEG it goes fine , but when I'm trying to load BMP , it runs by default MSPaint (defined by registry) . I'v removed entry from regestry and now any time I want to open a file , IExplorer shows dummy window "Do you want to open / save bla bla bla .. "
How can I avoid this window message ??
Thanx.
Kogi.
|
|
|
|
|
i have created a table in access database. then i tried to retrieve the table using class wizard in the application which was successful. when i am trying to get the methods and properties for this table using pDoc (document class) i am unable to get the methods and properties.
am i missing out something in the whole process????
|
|
|
|
|
Hi,
How do i disable the verticall scroll bar of the CListCtrl,
I want the user only scroll horizontally and not verticaly how do i do that?
Thanx in advance.
Regards,
Prakash
The World is getting smaller and so are the people.
|
|
|
|
|
Mr.Prakash wrote:
How do i disable the verticall scroll bar of the CListCtrl,
Don't add as many items to the control. In other words, if the control can display 9 items and you add 10, a vertical scroll bar will be displayed.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
Lol! that is not what i was looking for... Actually i had little idea bout listctrl,I wanted the user to scroll the listctrl horizontally rather than vertically,
I some how figured out that it is done by setting left adjust in the dialog editor.
regards,
Prakash.
|
|
|
|
|
I'm not familar with the "left adjust" style. Could you be more specific?
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
I need to save some settings to the registry when the user closes my application. For this purpose i use the WM_DESTROY message and it works fine. Now i noticed that the application doesn't receive this message when a user terminates Windows without closing my application before.
How can I detect that the application closes in such a case.
MS
|
|
|
|
|
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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
