Printable View
I have just try it referencing to the two dll you send me and the result is ... Wow! I don't realy understand want was wrong but using these dll it work fine. If I use the End or Debug button I return to VB in stop or in break mode with the cursor at the place where the error occur.
:) Good work CC :)
I would like to ask your permission to use your dll in my project.
Thank you!
you did it :)
i was out of the country for five days, i didn't forgot this subject, but i didn't get time to browse the net as well:)
it works with me perfectly (windows XP), i will test it later on Windows 2000 advance server, and win 98
thanks man :)
All, I am glad to hear these positive results. The specific result
that Aldragor had is VERY significant though and unfortunately
demonstrates a new 'stack' problem. Apparently, a thunked
WindowProc () does not function correctly in different compiled
modes (fastest vs. no optimization for example). What does not
function correctly is how the stack is set up in various scenarios
and once again we're back to a stack corruption of some sort.
Now for the good news, my new model on dealing with the
ORIGINAL stack corruption issue (for the VB run-time error in
compiled binaries) yielded a very significant behavior... the LACK
of a need for a thunked WindowProc ()! The new model proved
(in both my environment and Aldragors) that a pure module-
defined WindowProc () could be used and the location/existance
of the WindowProc () in memory would no longer matter. This
behavior was completely accidental on my part... but it works
in all compiled formats in labs.
Where do we go from here? I am going to get rid of all the Thunk
coding and strictly use the module-define WindowProc () directly
(as I did in Aldragor's case) and then release the code to this
forum.
Aldragor/Diamonds/Merrion/Geespot, you are all welcome to use
the final code that I will put out here for your RL projects.
Aldragor, wait for my next release so you can have the code.
As a general rule of thumb, it's a bad idea to be reliant on a
3rd parties binaries if there is no clear contract for maintenance.
Once you have the source code you will then have control over its
maintenance yourself.
Thanks All.
-CC
And the changes have been made. Consider this an official beta
(minus a few functionalities I am reserving for myself :)).
The attached ZIP file contains the source code for both the
sub classer (ldsClasser) and a demo application (MultiTestApp).
TO INSTALL AND RUN EVERYTHING:
* Unzip the attached .zip file to a location of your choosing.
* Compile \<Zip Location>\ldsClasser\ldsClasser.vbp (this is
the actual subclasser). A DLL will now exist (and the
compilation should have registered it).
* Compile \<Zip Location>\MITestApp\MultiTestAppProject.vbp
(this is the demo program). Note, you may need to change
the reference to the location of the newly compiled DLL.
* Execute MultiTestAppProject.exe
TO USE THE SUBCLASSER IN YOUR OWN PROJECTS:
* Make sure that 'ldsClasser' is compiled.
* Make a reference to the compiled DLL in your project.
* Create an instance of the 'subClasser' object.
* Subclass away!
IMPORTANT NOTE: Always use 'ldsClasser' as an external DLL.
FEATURES OF THIS BETA:
* Same great features as before except Thunked 'WindowProc ()'s
are no longer used as they are no longer needed.
* The DLL can now be compiled with any optimization option.
Have fun folks!
-CC
Thank you Crunchy Cat, your safe subClasser handler will be very usefull in my R&D project.
Again thanx,
Aldragor
Quote:
Originally posted by diamonds
Crunchy Cat, there is a bug...
in fact, your component has more features than the one i have made, but both have the same bug !
on your sample project, put a code on Button 1 as follows: -
Private Sub Button1_Click()
MsgBox 1 / 0
End Sub
when you run the project from VB, it will give you run time error 'Division by zero'
but when you compile it, and run it from the EXE file, the program crash when you click on the button WITHOUT showing any message, in fact the program will crash whenever there is any run time error occur.
on my project, i found the problem, but i dont know how to prevent it. on the DLL, you should NOT raise any even after the run time error occur on the EXE project, and if you did your EXE will immediately crash, btw i have tried this on all windows operating systems.
also, using On Error Goto ErrHandle: will solve the problem, but i have a big project really and i can not put error handle on each and every procedure, the most difficult part of this problem is when a client calls and says ‘the program crashes whenever i do xyz’!!! no message at all :)
anyway. i hope you will solve it :)
why dont you put your error handler into a module which you can call? I have written a module which traps all (i believe) trappable errors - and just use
on error goto trap
trap:
Call errtrap
i havent yet implemented it into any of my code as it isnt quite finished - I used a 2 dimensional array to store the error numbers and their descriptions - and from the module I send a msgbox with the # and the desc to the user
Well, the post that you responded to has already been solved.
VB Runtime errors occur normally. I don't see any reason for
adding complexities and potentially stack corruptions. Thanks
for the suggestion though.
-CC