Results for "Author: nick campbeln"

Determine the operating system your code is currently running under via the GetVersionEx() API. This module contains a number of useful functions to streamline the OS determination: isWin95(), isWin98(), isWinME(), isWinNT4(), isWin2k(), isWinXP(), isNT(), is9x() which all return true/false and Win32Ver() which returns an eNum integer that refers to the Win32 version currently running. The code is well commented and has been thoroughly tested (though your mileage may vary). Thanks and enjoy!

This code module gives you the ability to convert between short (DOS style 8.3) and long paths under ANY Win32 system. If you've ever had to do path conversions with the API you know that Win95/NT4 does not support the GetLongPathName() API which allows for short to long path name conversions. Those of you who have looked for a solution may have found David Goben’s wonderful (though poorly commented) GetLongPath() function on SearchVB.com, but it relies on the FileSystemObject (which did me no good). So I built this module which utilizes both conversion APIs (GetShortPathName() and GetLongPathName()) on the systems that support them (Win98+). For systems that do not support GetLongPathName() (Win95/NT4) the GetShortPathName() API is used along with Dir() to determine the long path name from the passed short path name. The code is very well commented but is not thoroughly tested; so if you find a bug, please let me know!. Thanks and enjoy!

This is a simple class that allows you to read from standard in (StdIn) and write to standard out (StdOut) and/or standard error (StdErr) via API calls. This allows you to do things like inputting a data file from the command line (i.e. - “C:\vb\YourProgram.exe outputfile.txt”) or output an error to the calling application (i.e. – “YourProgram.exe 2> errors.txt”). The class has been tested pretty well, but your mileage may vary =) UPDATE: Fixed a sloppy coding bug (forgot to rename the copy-n-pasted StdErr function, d'oh!). If you find a bug or want to suggest an improvement, please lemme know! Thanks and enjoy!

This class module provides a process manipulation abstraction layer that will work across all Win32 operating systems in addition to a completely unique process information conversion function. NT4's process information interface differs greatly from Win95+, but with this lightweight class these differences are abstracted thru the class’s interface. The process conversion function of this class allows you to activity convert between a window’s ProcessID, hWnd, Window Title, Class Name and EXE name. Given any one of these, the Convert() function will convert it into another! Ever needed to figure out the hWnd of a window and only had the EXE name? Or needed the ProcessID for a window title beginning with “Adobe”? The Convert() function in this class will do these conversions and more! I’ve provided a simple example program to demonstrate the basic interface to this class. Be sure to take a look at the class itself in order to learn about all of its features and capabilities! This class has been very well tested, but your mileage may vary. If you find a bug or would like to suggest an improvement, please let me know! Thanks and enjoy!

I was sitting at my computer today in a programming quandary when my fiancé asked me to let her know when it was 1:15pm. Since she does this quite often and I needed a distraction from my current task, I decided to build this little application – EggTimer. EggTimer allows you to set a duration (i.e. - 30min), a specific time (i.e. - 1:15pm) or it can be used as an upward counting timer (like a stopwatch). Once you start EggTimer, it minimizes itself into the system tray where it can be accessed to check the time remaining, reset/change the time, or pause/resume/stop the timer. You can also see the time remaining/running time by floating over the tray icon. When the timer expires, a ‘vbSystemModal’ message box is popped above your working app to let you know the time is up. This little application is really handy if you sometimes need a reminder of the time when you’re working on the computer =) This code utilizes a simple class I created from a number of examples from around the web that encapsulates the API functions used in placing an icon in the system tray. This class is definitely something to look it if you’re interested in placing an icon in the system tray. *LATEST UPDATE* It seems that I had a little issue with the time math in certain situations (it was adding an extra minute). When I get a chance I’m going to overhaul that little but complicated portion of the code. Enjoy, if you like it please remember to vote! If you find a bug, please let me know!

This module is a collection of various time functions, including the generation of GMT offset UNIX Epoch timestamps, Leap Year calculation, Days In Month calculation, and the completely unique GetTimeZoneOffset(), GetCurrentTimeZoneOffset() and isDaylightSavings() functions! I was unable to find any VB code for timestamp generation, so I had to make my own! Have you ever needed to compare dates that were created in two different countries? If so then you've probably run into the differences in dates in various regions of the world. The US formats dates as "mm/dd/yy" where as most of the rest of the world uses "dd/mm/yy". This is all fine and good, until you need to compare one to the other. According to VB's documentation, the date format is defined by the local systems settings. This has the effect of improper comparison when equating dates generated in two different regions. IE - is CDate("3/4/03") March 4th or April 3rd? VB makes the assumption that the date was generated on the local system, so if the local system's format is different then the system that generated the date it will be incorrect. It becomes even more fun when dealing with other languages! CDate("Mar 4, 2003") will generate an error on a non English machine as "Mar" is not a recognized month or abbreviation. Utilizing a GMT offset UNIX Epoch timestamp can avert this issue. The timestamp is the number of seconds that have elapsed since the epoch (January 1 1970 00:00:00 GMT). So instead of storing "3/4/03" you store "1046700000" which is the number of seconds between March 4th, 2003 and the epoch. Best of all, this module allows you to convert back from a timestamp into a date variable, allowing you to format it for the local user. ** In a nutshell, utilizing a timestamp in place of a locally formatted date will allow you to correctly compare dates no matter what language or format was used during the creation of either date you're attempting to compare. ** The other unique functionality of this module is the GetTimeZoneOffset(), GetCurrentTimeZoneOffset() and isDaylightSavings() functions. These allow you to determine the Time Zone Offset and Current Time Zone Offset of the local system. IE - Canberra, Australia is GMT + 10:00, so 10 is Canberra's Time Zone Offset. During summer daylight savings, Canberra's Current Time Zone Offset is 9. If you didn't follow that, then you'll probably never need this functionality (but it's in here if you do)! The rest of the functions are pretty standard, though well-commented and optimized functions concerning leap year and days in a month calculation. The module is pretty well tested, but your mileage may vary. Please leave a comment or send an email if you find a bug or have a new feature to add or request! Thank and enjoy! UPDATED - (Finially) fixed the leap year bug. Please let me know if you find any issues!

Have you ever wanted to CLEANLY shutdown an external application that you only had a ProcessID to? I've always wished that there was the equivalent to the TerminateProcess() API that would send the WM_CLOSE message to the application, allowing it to shutdown cleanly, not abruptly as TerminateProcess() does. Because of this, I began a quest to either find such an API or to build one myself... Basically, the only way to successfully shutdown an application who's window title you do not know beforehand on Win95/98 is to use the TerminateProcess() API. WinME seems to correctly process the WM_CLOSE message to its top-level windows, so it can be excluded from this even though according to MSDN it functions the same as Win95/98. Now, use of the TerminateProcess() API is frowned upon because according to the MSDN article http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/terminateprocess.asp : "The TerminateProcess function is used to unconditionally cause a process to exit. Use it only in extreme circumstances. The state of global data maintained by dynamic-link libraries (DLLs) may be compromised if TerminateProcess is used rather than ExitProcess." But... with the use of the WM_ENDSESSION message this downside seems to be obverted, because to this MSDN article http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/wm_endsession.asp (which is actually for the WM_QUERYENDSESSION message): "Windows 95/98/Me: After all applications return TRUE for this message (WM_QUERYENDSESSION), they receive the WM_ENDSESSION and they are terminated." So if I'm reading that correctly, at shutdown Win95/98 sends the WM_QUERYENDSESSION to all top-level windows, followed by the WM_ENDSESSION then (assuming all applications are happy with the shutdown) they are then terminated assumedly via the TerminateProcess() API! Now this process also occurs at a logoff, so it *should* be reasonable to assume that all of the downsides of the use of the TerminateProcess() API are solved by first sending the window the WM_ENDSESSION and a True in the wParam argument because the application is *supposed* to clean up after itself when it receives the WM_ENDSESSION message. In my research, I found a number of sites concerning the incorrect handling of the WM_ENDSESSION by Delphi applications. They advised their developers to hook the message and fully close their apps (destroy objects, etc) at that time in order to avoid any errors. So as long as I've not missed any important nuances, I believe that with the help of Ark's comment I've stumbled across the answer to my question! So in order to put this into a nice little package, I've implemented the fabled CloseProcess() API I used to wish for... As always… if you find a bug please let me know. Thanks and enjoy!

Determine the operating system your code is currently running under via the GetVersionEx() API. This module contains a number of useful functions to streamline the OS determination: isWin95(), isWin98(), isWinME(), isWinNT4(), isWin2k(), isWinXP(), isNT(), is9x() which all return true/false and Win32Ver() which returns an eNum integer that refers to the Win32 version currently running. The code is well commented and has been thoroughly tested (though your mileage may vary). Thanks and enjoy!

This code module gives you the ability to convert between short (DOS style 8.3) and long paths under ANY Win32 system. If you've ever had to do path conversions with the API you know that Win95/NT4 does not support the GetLongPathName() API which allows for short to long path name conversions. Those of you who have looked for a solution may have found David Goben’s wonderful (though poorly commented) GetLongPath() function on SearchVB.com, but it relies on the FileSystemObject (which did me no good). So I built this module which utilizes both conversion APIs (GetShortPathName() and GetLongPathName()) on the systems that support them (Win98+). For systems that do not support GetLongPathName() (Win95/NT4) the GetShortPathName() API is used along with Dir() to determine the long path name from the passed short path name. The code is very well commented but is not thoroughly tested; so if you find a bug, please let me know!. Thanks and enjoy!

This is a simple class that allows you to read from standard in (StdIn) and write to standard out (StdOut) and/or standard error (StdErr) via API calls. This allows you to do things like inputting a data file from the command line (i.e. - “C:\vb\YourProgram.exe outputfile.txt”) or output an error to the calling application (i.e. – “YourProgram.exe 2> errors.txt”). The class has been tested pretty well, but your mileage may vary =) UPDATE: Fixed a sloppy coding bug (forgot to rename the copy-n-pasted StdErr function, d'oh!). If you find a bug or want to suggest an improvement, please lemme know! Thanks and enjoy!

This class module provides a process manipulation abstraction layer that will work across all Win32 operating systems in addition to a completely unique process information conversion function. NT4's process information interface differs greatly from Win95+, but with this lightweight class these differences are abstracted thru the class’s interface. The process conversion function of this class allows you to activity convert between a window’s ProcessID, hWnd, Window Title, Class Name and EXE name. Given any one of these, the Convert() function will convert it into another! Ever needed to figure out the hWnd of a window and only had the EXE name? Or needed the ProcessID for a window title beginning with “Adobe”? The Convert() function in this class will do these conversions and more! I’ve provided a simple example program to demonstrate the basic interface to this class. Be sure to take a look at the class itself in order to learn about all of its features and capabilities! This class has been very well tested, but your mileage may vary. If you find a bug or would like to suggest an improvement, please let me know! Thanks and enjoy!

I was sitting at my computer today in a programming quandary when my fiancé asked me to let her know when it was 1:15pm. Since she does this quite often and I needed a distraction from my current task, I decided to build this little application – EggTimer. EggTimer allows you to set a duration (i.e. - 30min), a specific time (i.e. - 1:15pm) or it can be used as an upward counting timer (like a stopwatch). Once you start EggTimer, it minimizes itself into the system tray where it can be accessed to check the time remaining, reset/change the time, or pause/resume/stop the timer. You can also see the time remaining/running time by floating over the tray icon. When the timer expires, a ‘vbSystemModal’ message box is popped above your working app to let you know the time is up. This little application is really handy if you sometimes need a reminder of the time when you’re working on the computer =) This code utilizes a simple class I created from a number of examples from around the web that encapsulates the API functions used in placing an icon in the system tray. This class is definitely something to look it if you’re interested in placing an icon in the system tray. *LATEST UPDATE* It seems that I had a little issue with the time math in certain situations (it was adding an extra minute). When I get a chance I’m going to overhaul that little but complicated portion of the code. Enjoy, if you like it please remember to vote! If you find a bug, please let me know!

This module is a collection of various time functions, including the generation of GMT offset UNIX Epoch timestamps, Leap Year calculation, Days In Month calculation, and the completely unique GetTimeZoneOffset(), GetCurrentTimeZoneOffset() and isDaylightSavings() functions! I was unable to find any VB code for timestamp generation, so I had to make my own! Have you ever needed to compare dates that were created in two different countries? If so then you've probably run into the differences in dates in various regions of the world. The US formats dates as "mm/dd/yy" where as most of the rest of the world uses "dd/mm/yy". This is all fine and good, until you need to compare one to the other. According to VB's documentation, the date format is defined by the local systems settings. This has the effect of improper comparison when equating dates generated in two different regions. IE - is CDate("3/4/03") March 4th or April 3rd? VB makes the assumption that the date was generated on the local system, so if the local system's format is different then the system that generated the date it will be incorrect. It becomes even more fun when dealing with other languages! CDate("Mar 4, 2003") will generate an error on a non English machine as "Mar" is not a recognized month or abbreviation. Utilizing a GMT offset UNIX Epoch timestamp can avert this issue. The timestamp is the number of seconds that have elapsed since the epoch (January 1 1970 00:00:00 GMT). So instead of storing "3/4/03" you store "1046700000" which is the number of seconds between March 4th, 2003 and the epoch. Best of all, this module allows you to convert back from a timestamp into a date variable, allowing you to format it for the local user. ** In a nutshell, utilizing a timestamp in place of a locally formatted date will allow you to correctly compare dates no matter what language or format was used during the creation of either date you're attempting to compare. ** The other unique functionality of this module is the GetTimeZoneOffset(), GetCurrentTimeZoneOffset() and isDaylightSavings() functions. These allow you to determine the Time Zone Offset and Current Time Zone Offset of the local system. IE - Canberra, Australia is GMT + 10:00, so 10 is Canberra's Time Zone Offset. During summer daylight savings, Canberra's Current Time Zone Offset is 9. If you didn't follow that, then you'll probably never need this functionality (but it's in here if you do)! The rest of the functions are pretty standard, though well-commented and optimized functions concerning leap year and days in a month calculation. The module is pretty well tested, but your mileage may vary. Please leave a comment or send an email if you find a bug or have a new feature to add or request! Thank and enjoy! UPDATED - (Finially) fixed the leap year bug. Please let me know if you find any issues!

Have you ever wanted to CLEANLY shutdown an external application that you only had a ProcessID to? I've always wished that there was the equivalent to the TerminateProcess() API that would send the WM_CLOSE message to the application, allowing it to shutdown cleanly, not abruptly as TerminateProcess() does. Because of this, I began a quest to either find such an API or to build one myself... Basically, the only way to successfully shutdown an application who's window title you do not know beforehand on Win95/98 is to use the TerminateProcess() API. WinME seems to correctly process the WM_CLOSE message to its top-level windows, so it can be excluded from this even though according to MSDN it functions the same as Win95/98. Now, use of the TerminateProcess() API is frowned upon because according to the MSDN article http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/terminateprocess.asp : "The TerminateProcess function is used to unconditionally cause a process to exit. Use it only in extreme circumstances. The state of global data maintained by dynamic-link libraries (DLLs) may be compromised if TerminateProcess is used rather than ExitProcess." But... with the use of the WM_ENDSESSION message this downside seems to be obverted, because to this MSDN article http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/wm_endsession.asp (which is actually for the WM_QUERYENDSESSION message): "Windows 95/98/Me: After all applications return TRUE for this message (WM_QUERYENDSESSION), they receive the WM_ENDSESSION and they are terminated." So if I'm reading that correctly, at shutdown Win95/98 sends the WM_QUERYENDSESSION to all top-level windows, followed by the WM_ENDSESSION then (assuming all applications are happy with the shutdown) they are then terminated assumedly via the TerminateProcess() API! Now this process also occurs at a logoff, so it *should* be reasonable to assume that all of the downsides of the use of the TerminateProcess() API are solved by first sending the window the WM_ENDSESSION and a True in the wParam argument because the application is *supposed* to clean up after itself when it receives the WM_ENDSESSION message. In my research, I found a number of sites concerning the incorrect handling of the WM_ENDSESSION by Delphi applications. They advised their developers to hook the message and fully close their apps (destroy objects, etc) at that time in order to avoid any errors. So as long as I've not missed any important nuances, I believe that with the help of Ark's comment I've stumbled across the answer to my question! So in order to put this into a nice little package, I've implemented the fabled CloseProcess() API I used to wish for... As always… if you find a bug please let me know. Thanks and enjoy!