Results for "Author: paul caton"
VB makes it easy to compile controls into an application if you have the source. It's much more convenient for users if the only file that needs to be added to the project is just the control’s ctl file. If the Control uses subclassing, then you're out of luck, or rather... you were. This submission includes the FIRST ever Control/Form that can subclass itself without ANY dependencies – modules, classes, type-libraries, references or components. The techniques used are based on my WinSubHook2 submission and thus incorporate IDE breakpoint and stop safety; it won’t crash the IDE. My main target audience here would be control authors, however, anyone who needs form subclassing may well find this to be an ideal solution. 06/02: Can now subclass multiple hWnd’s. 06/07: Byte array substituted in place of a string for the machine code buffer. 06/18: Hidden bug fixed, see comments. 06/19: Optimised to within an inch of its life. 06/20: Road to Damascus. 06/21 New sample added, see screenshot. 06/28 Final (I hope). 06/29 Oops fixed. 09/10 fixed bug in UserControl_Terminate, marked zSubclass_Proc hidden.
Pentium class cpu's include a 64 bit register that increments from power-on at the CPU clock frequency. With a 2GHz processor, you have in effect, a 2GHz clock. The cCpuClk class allows the user to retrieve the 64 bit CPU clock cycle count into a passed currency parameter. The class can be used as a basis for sub-microsecond benchmarking and delay timing. Note that with the extreme resolution provided, multitasking and the state of the cpu caches will show in the results. Thanks to David Fritts and Robert Rayment for the vtable trick. Update 7/1/2003 - I said... at this resolution cache FX come into play. In determining the call overhead, I should have born that in mind. Just goes to show you have to be extra, extra careful with benchmarks. Update 7/5/2003 - I got asked to do an article for a benchmark site based on this submission so I thought I'd put a little more effort into the data displayed. See new screenshot.
The included cDebug.cls class allows the user to break their application (or the VB IDE if run from there, not recommended) into the Visual Studio debugger. Make the sample project, run the executable, click the 'Break into debugger' button, a dialog will be displayed, click the Cancel button to enter the Visual Studio debugger, dismiss the message box and then press F10 twice to step thru the software interupt and the return statements and you'll be back in the VB calling routine. Provided you haven't run the program from the IDE, you should now see the Visual Basic statements interspersed with their implementing assembler codes. To ensure that you can view the VB source with your own programs.... make sure that the following options are set on the Project/Project Properties/Compile dialog... Compile to Native Code, Create Symbolic Debug Info. Also, before running the application to be debugged, be certain that the source code files on disk are up to date by selecting File/Save Project. I should stress that this submission is a shameless VB+ASM promotion, as the same trick can be achieved with an API call, as is demonstrated in the sample.
I was wondering whether MMX/SSE instructions could be employed to improve on the performance of CopyMemory for large blocks of data. Well, as you can from the screenshot, in some scenarios huge benefits can be wrought. Though I have to state, overall, the best strategy is to play nice with the cache and ensure that both source and destination are aligned on 16 byte boundaries. Nota Bene: The ASM routines DO NOT work with overlapped source and destination, though why a VB programmer would be doing that, I can't imagine. Don't concern yourself that that a user's CPU might be ancient and not support either MMX or SSE instructions, if those capabilities aren't found, then the cMemory class seamlessly falls back to using the regular api functions. For actual usage, use the cMemory.cls which chooses SSE over MMX, if available, automatically, rather than the cMemTest.cls, as used in the sample project, which was written just so that I could demonstrate both MMX and SSE codes against each other. Just for fun, I also test the equivalent C run-time functions memcpy, memmove & memset. The screenshot was produced on a P4 @ 1.8GHz See comments below for update details...
Version 2 of my funky thunks. Teaser: check out the global keyboard hook sample as the basis of a spy app... with active app tracking. Update 2/13 minor enhancement to cTimer.cls
*** Update: See my new submission here... http://www.exhedra.com/vb/scripts/ShowCode.asp?txtCodeId=42918&lngWId=1 If you do want the original zip then email me at Paul_Caton@hotmail.com *** cSuperClass.cls is i believe the fastest, safest compiled in window subclasser around. Speed: The WndProc is executed entirely in run-time dynamically generated machine code. The class only calls back on messages that you choose. Safety: So far I've not been able to crash the IDE by pressing the end button or with the End statement. Flexible: The programmer can choose between filtered mode (fastest) and all messages mode. In filtered mode the user decides which windows messages they're interested in and can individually specify whether the message is to callback after default processing or before. Before mode additionally allows the programmer to specify whether or not default processing is to be performed subsequently. No module: AFAIK this is the only subclasser ever to eschew the use of a module. So how do I get the address of the WndProc routine? Simple, the dynamically generated machine code lives in a byte array; you can get its address with the undocumented VarPtr function. The real magic in cSuperClass.cls is getting from the WndProc to the callback interface routine using ObjPtr against the owning Form/UserControl, see the assembler .asm model file included in the zip. Speaking of which... it may well be the case that my assembler is sub-optimal. Any experts out there willing to take a look? I thought I had a nifty/dirty stack trick working for a while but it didn't pan out. Should work with VB5 if VarPtr & ObjPtr were in that release? Sample project included. Regards.
Superceded by this submission http://www.planet-source-code.com/vb/scripts/showcode.asp?txtCodeId=51403&lngWId=1 Updated 3/07 - Just minor stuff --- My cSuperClass submission's download link appears broken so I thought it was about time I made a new entry. Just as Vlad Vissoultchev's excellent subclasser built on mine and added a hooking thunk, I've done likewise and added timer and api-windows thunks. Each of the thunks has an individual sample to demonstrate its use. If you're blessed with Windows 2000 or Windows XP check out the form shadow/fade user control. Credits: Thanks to Clint LaFever for the idea of a form shadow. http://www.exhedra.com/vb/scripts/ShowCode.asp?txtCodeId=42148&lngWId=1 Thanks to Vlad for his superb subclass/hook thunks http://www.exhedra.com/vb/scripts/ShowCode.asp?txtCodeId=40518&lngWId=1
x86 cpu's have the ability to self-report their make, model, family, features, cache details etc. The included cCPUID class allows the programmer to execute this instruction and retrieve the results. To abstract the complexities of decoding the CPUID data, the included cCpuInfo class presents the programmer with a series of read-only properties. As an example of this, the included VBCPUID application displays the information presented by the cCpuInfo class. If you are wondering why the 'Real Time Speed' display - try running the VBCPUID app on a SpeedStep cpu. If you own an unusual cpu, such as an Athlon 64/Opteron, Cyrix etc... I'd be gratefull if you'd go to the 'Actions' tab, 'Save Data...' and email the file to me.
CDECL DLL functions cannot be called from Visual Basic... or so they'll tell you... such dll's use a incompatible technique for parameter stack cleanup. The included class uses VB+ASM to slay the "impossible" cdecl call dragon, even allowing 'C' style variable length/type parameter lists and the use of VB bas module functions as cdecl callback routines. The convention used with a cdecl function is that the caller cleans the stack on return; the stdcall convention is that the called function cleans the stack at function end. The advantage of stdcall is reduced program size, 6 calls to a function, one bit of cleanup code. The advantage of cdecl is that variable length/type parameter lists are "safe" because the caller, he who pushed the parameters onto the stack, cleans the stack... he knows exactly how many parameters he pushed and thus knows the required adjustment on function return. Years ago I worked on a team that lost a project because of our inability to speedily resolve this issue for a third-party dll - So, perhaps not the sexiest submission of the week, however, it might just save your a*s someday. The included sample demonstrates variable length/type parameter lists and callbacks routines, focusing on the std 'C' library qsort (quicksort) function.
Version 2 of my funky thunks. Teaser: check out the global keyboard hook sample as the basis of a spy app... with active app tracking. Update 2/13 minor enhancement to cTimer.cls
VB makes it easy to compile controls into an application if you have the source. It's much more convenient for users if the only file that needs to be added to the project is just the control’s ctl file. If the Control uses subclassing, then you're out of luck, or rather... you were. This submission includes the FIRST ever Control/Form that can subclass itself without ANY dependencies – modules, classes, type-libraries, references or components. The techniques used are based on my WinSubHook2 submission and thus incorporate IDE breakpoint and stop safety; it won’t crash the IDE. My main target audience here would be control authors, however, anyone who needs form subclassing may well find this to be an ideal solution. 06/02: Can now subclass multiple hWnd’s. 06/07: Byte array substituted in place of a string for the machine code buffer. 06/18: Hidden bug fixed, see comments. 06/19: Optimised to within an inch of its life. 06/20: Road to Damascus. 06/21 New sample added, see screenshot. 06/28 Final (I hope). 06/29 Oops fixed. 09/10 fixed bug in UserControl_Terminate, marked zSubclass_Proc hidden.
Superceded by this submission http://www.planet-source-code.com/vb/scripts/showcode.asp?txtCodeId=51403&lngWId=1 Updated 3/07 - Just minor stuff --- My cSuperClass submission's download link appears broken so I thought it was about time I made a new entry. Just as Vlad Vissoultchev's excellent subclasser built on mine and added a hooking thunk, I've done likewise and added timer and api-windows thunks. Each of the thunks has an individual sample to demonstrate its use. If you're blessed with Windows 2000 or Windows XP check out the form shadow/fade user control. Credits: Thanks to Clint LaFever for the idea of a form shadow. http://www.exhedra.com/vb/scripts/ShowCode.asp?txtCodeId=42148&lngWId=1 Thanks to Vlad for his superb subclass/hook thunks http://www.exhedra.com/vb/scripts/ShowCode.asp?txtCodeId=40518&lngWId=1
Pentium class cpu's include a 64 bit register that increments from power-on at the CPU clock frequency. With a 2GHz processor, you have in effect, a 2GHz clock. The cCpuClk class allows the user to retrieve the 64 bit CPU clock cycle count into a passed currency parameter. The class can be used as a basis for sub-microsecond benchmarking and delay timing. Note that with the extreme resolution provided, multitasking and the state of the cpu caches will show in the results. Thanks to David Fritts and Robert Rayment for the vtable trick. Update 7/1/2003 - I said... at this resolution cache FX come into play. In determining the call overhead, I should have born that in mind. Just goes to show you have to be extra, extra careful with benchmarks. Update 7/5/2003 - I got asked to do an article for a benchmark site based on this submission so I thought I'd put a little more effort into the data displayed. See new screenshot.
Updated November 2007, fix a DEP problem. CDECL DLL functions cannot be called from Visual Basic... or so they'll tell you... such dll's use a incompatible technique for parameter stack cleanup. The included class uses VB+ASM to slay the "impossible" cdecl call dragon, even allowing 'C' style variable length/type parameter lists and the use of VB bas module functions as cdecl callback routines. The convention used with a cdecl function is that the caller cleans the stack on return; the stdcall convention is that the called function cleans the stack at function end. The advantage of stdcall is reduced program size, 6 calls to a function, one bit of cleanup code. The advantage of cdecl is that variable length/type parameter lists are "safe" because the caller, he who pushed the parameters onto the stack, cleans the stack... he knows exactly how many parameters he pushed and thus knows the required adjustment on function return. Years ago I worked on a team that lost a project because of our inability to speedily resolve this issue for a third-party dll - So, perhaps not the sexiest submission of the week, however, it might just save your a*s someday. The included sample demonstrates variable length/type parameter lists and callbacks routines, focusing on the std 'C' library qsort (quicksort) function.
I was wondering whether MMX/SSE instructions could be employed to improve on the performance of CopyMemory for large blocks of data. Well, as you can from the screenshot, in some scenarios huge benefits can be wrought. Though I have to state, overall, the best strategy is to play nice with the cache and ensure that both source and destination are aligned on 16 byte boundaries. Nota Bene: The ASM routines DO NOT work with overlapped source and destination, though why a VB programmer would be doing that, I can't imagine. Don't concern yourself that that a user's CPU might be ancient and not support either MMX or SSE instructions, if those capabilities aren't found, then the cMemory class seamlessly falls back to using the regular api functions. For actual usage, use the cMemory.cls which chooses SSE over MMX, if available, automatically, rather than the cMemTest.cls, as used in the sample project, which was written just so that I could demonstrate both MMX and SSE codes against each other. Just for fun, I also test the equivalent C run-time functions memcpy, memmove & memset. The screenshot was produced on a P4 @ 1.8GHz See comments below for update details...
The included cDebug.cls class allows the user to break their application (or the VB IDE if run from there, not recommended) into the Visual Studio debugger. Make the sample project, run the executable, click the 'Break into debugger' button, a dialog will be displayed, click the Cancel button to enter the Visual Studio debugger, dismiss the message box and then press F10 twice to step thru the software interupt and the return statements and you'll be back in the VB calling routine. Provided you haven't run the program from the IDE, you should now see the Visual Basic statements interspersed with their implementing assembler codes. To ensure that you can view the VB source with your own programs.... make sure that the following options are set on the Project/Project Properties/Compile dialog... Compile to Native Code, Create Symbolic Debug Info. Also, before running the application to be debugged, be certain that the source code files on disk are up to date by selecting File/Save Project. I should stress that this submission is a shameless VB+ASM promotion, as the same trick can be achieved with an API call, as is demonstrated in the sample.
x86 cpu's have the ability to self-report their make, model, family, features, cache details etc. The included cCPUID class allows the programmer to execute this instruction and retrieve the results. To abstract the complexities of decoding the CPUID data, the included cCpuInfo class presents the programmer with a series of read-only properties. As an example of this, the included VBCPUID application displays the information presented by the cCpuInfo class. If you are wondering why the 'Real Time Speed' display - try running the VBCPUID app on a SpeedStep cpu. If you own an unusual cpu, such as an Athlon 64/Opteron, Cyrix etc... I'd be gratefull if you'd go to the 'Actions' tab, 'Save Data...' and email the file to me.
I was searching around for a self-deleting exe technique. There is one here on PSC (70747) but it has a few problems... it doesn't work on a 64-bit OS (easily fixed), creates a remote thread that can look suspicious to real-time AV. So, this is my version of that code. Basically, we create a child notepad process in a suspended state, overwrite its entry point and resume the process, whereupon the overwritten code waits until our process terminates and then deletes the exe file. Note well, the process that's to have its exe file deleted must have sufficient permission to do so. e.g. if the exe file is being run from "/Program Files/" (for example) on Vista or Windows 7, then it will have to be running with Administrator permissions in order to self-delete.
Simple self-sunlassed form and usercontrol -- fixed for XP... hopefully.
Just an update responding to previous user requests. Added fastcall support, call by pointer and every return type I could think of: Byte, Integer, Long, 64bit, Single, Double and none. March 10: two asm optimizations and some comments fixed. March 17: LaVolpe's requests added.