A new (and better?) way to Subclass in VB 6!

*** CODE ATTACHED TO THIS POST ***

Hi, I just figured out what may be a really great way to
Subclass in VB 6. Here are the some of the features of this 'alpha'
product.

* Every handle you subclass gets a UNIQUE WindowProc ().
By 'unique' I mean the actual binary code for every
WindowProc is within it's own dynamically allocated chunk
of memory.

* Pressing the 'Stop' button does not crash the IDE. In fact
you can use breakpoints, step through code, and basically
perform all normal debugging operations.

* The implementation is an event-driven class. You can
respond before and after a window handle is subclassed
and before and after a WindowProc () is processed. If you
happen to respond before then you may also optinally
change the data before it reaches the original WindowProc ()
OR you may simply cancel the original WindowProc () (of
course meaning that you are handling the message 100%
on your own).

The attached ZIP file contains the class' code and a demo
application (code of course). I apologize for the lack of comments,
and the occasional un-used function... but this is hot off the grill.
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). Note, when you first
open up the project you will get (an expected) error
message 'Unable to set version compatible component...'.
You can safely igore this because I had the project set to
binary compatibility in my environment.

* Compile \<Zip Location>\MITestApp\MultiTestAppProject.vbp
(this is the demo program). Note, you will need to change
the reference to the location of the newly compiled DLL or
you will get a missing-reference compilation error.

* Execute MultiTestAppProject.exe

My intention (aside from sharing this 'hopefully' new discovery)
is to get feedback from all you VB Subclassing maniacs out there...
whether you like it, hate it, think it needs to work differently,
think it's dangerous... (you get the point).

Thanks,

-CC

One last thing I thought I would mention. I DON'T make any
use of the undocumented VarPtr (), ObjPtr (), etc... functions.
Everything is made with documented and supported
functions.

I can see by the downloads that some of you have tried this
allready. Give me some feedback on it :).

-CC

Nice Work!

i like this alot, how you manage to figure this out?

Well, it all started by an attempt I made to create a flickerless-
keyword highlighting-extension of the the Rich Text Box control:

http://www.vbforums.com/showthread.php?threadid=196839

Sadly the end result was that it appeared it could not be done
(you could get close... but the high quality result was just not
within reach). The last suggestion I noted was simply to use a 3rd
party control. I really hate using 3rd party components because
you never know when the company in question will go out of
business or stop making the component (not to mention you have
very little control over defects). Long story short, it was not an
option. I actually had a hypothesis (documented in the post)
which may work. Basically I could subclass the RTB control,
intercept and send all WM_PAINT output to a memory DC, and
then bitblt () the DC to the controls real DC afterwards (basically
simulating double buffering). In order to do this I needed to
subclass the control. I have done VB 6 subclassing before and
extensively researched other peoples work on the topic. I was
simply not happy with the limitations imposed by these existing
methods of subclassing so I decided to go for the gold and create
my own 'perfect' subclass control (after which I could test out my
double buffered RTB hypothesis... which has not been done yet
but will happen soon).

So, how did I come up with this implementation? My analysis
of existing subclassing implementations told be that the bulk of
the known instabilites/limitations came from the use of a module
function as the replacement WindowProc (). It seemed that
stopping, breaking, debugging etc... caused the module function
to disappear or be relocated in memory. Of course when
messages were dispatched to an invalid memory location...
*poof* you crashed. In addition, it was next to impossible to get
a reference to more than one subclassed object into the window
proc. This meant the first thing I had to do was find a way to
get 1 or more (depending on how many controls I wanted to
subclass) stable memory locations and fill them with WindowProc
() code. Creating the memory was the easy part. HeapAlloc ()
did this quite nicely and it returns a pointer to the memory that
can be sent directly to SetWindowLong () to replace the existing
WindowProc (). Now I had to populate the allocated memory with
actual code (that acted as a WindowProc ()). To do this I
maintained the WindowProc () code in a module function. This
only acted as a template. I would then copy the code from the
function (at run time) directly into my memory location created
with HeapAlloc (). The copying part was done with the
CopyMemory () function of course. I was able to determine the
size of the base template function by looking for the 'ret 16'
assembly instruction (which all module functions end with when
returning). Now I could create a unique WindowProc () on the fly.
There was a problem with this however. If I attempted to call any
Win32 API function or even module function directly from a
dynamically created WindowProc () (dynamic code like this is
called a 'Thunk' FYI) then a crash would occur. This is because
the memory references to these calls are releative and
created at compile time in the template function. Of course the
relative addresses were invalid for code freshly copied into a
different memory location... so I turned to a different way of doing
things. Within my WindowProc () template I added code to
instantiate a class on the fly (so all addressing would be correct
because the call is made at run-time). This class could then call
any API function (or otherwise) that I wanted to... and do it
safely. So, now I needed a way to reference a unique 'subClass'
object every time a WindowProc () was executed. I did this by
passing the classes memory address via the actual window
handle referenced by the WindowProc () (SetProp () and GetProp
() worked perfectly for this). So how did I get a pointer to the
original 'SubClass' object and SetProp () it in the first place
without using ObjPtr ()? Simple:

pSelf = HeapAlloc(hProcessHeap, 0, WIN32_POINTER_SIZE)
CopyMemory ByVal pSelf, Me, WIN32_POINTER_SIZE
rc = SetProp(hSubClassedWnd, "<some unique tag>", pSelf)

So, once again the heap came to the rescue. Now the
infrastructure was in place and the rest was just regular coding.
I am probably making it sound easy, but this bastard was a *****
to conceptualize... but alas it's done and it works! After I get
some more feedback from others I am going to continue with
my double-buffered RTB project and update the thread I created
on the topic should I have any success (cross your fingers).

Thanks,

-CC

dude, that was just an awsome description!
you can tell you know your stuff!

and considering you said it was 'alpha' it hasnt crashed once yet and ive been stepping through code, terminating it via stop button etc.

i only one question which i got stuck with ( and btw im not a subclass freak, only played around with it past few weeks with very ugly results )

I was following a tutorial to draw a picture for the background of a textbox and this is a snip of the code..

VB Code:

'-- This was in the WindowProc
        Case WM_CTLCOLOREDIT And Brush <> 0
            SetBkMode wParam, 1
            WindowProc = Brush
            Exit Function

as you can see, the WindowPeoc returns the Brush ( which holds a bitmap )

how could i do this with your class? i notice there a returncode in the _beforeWindowProc but not sure if thats what im looking for


Thanks

[edit]
P.S Youve given me some insight in the windows memory, thanks!

You're right on target. Just set 'returnCode' to the desired
value and ALSO set 'cancelWindowProc=True'... as this will
prevent the original WindowProc () from executing (otherwise
it would override your return code).

-CC

Any other feedback folks? I see alot of downloads and have
only gotten feedback from one person.

-CC

Well, I have received no negative feedback on this 'alpha'
component, so I will now develop a complete beta package, QA
it, and then finalize a release version. The final version won't
be posted on this forum (unless you sign an NDA with me...
perfeclty acceptable), but feel free to use and abuse the 'alpha'
build as you see fit.

-CC

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 :)

Diamond:

But this is just a normal vb problem, what has this got to do with the subclass control?

Its just common design to make sure you dont devision by zero

division by zero was just a sample to demonstrate the bug, whereas in my case the run time error is not as simple as division by zero, the application will crash if any run time error occur, specially when it comes to complicated database application like ours, there is no chance to prevent these run time error :)

btw, my application still using subclassing on same method, and sometimes we suffer if the problem doesn't happen with us and it happens only on the customer side...

Hey Diamonds, thanks for bringing that bug to my attention.
It's very interesting that a run-time error seems to process fine
when running from the IDE but has causes a 'crash' when raised
from a pure binary (only if it's not caught by an On Error
statement). I made some observations on the problem (which
may only be relevant to my subclasser and not yours), and
what seems to be happening is that as soon as a run-time error
occurs, the VB engine enumerates all heaps and deallocates
them. Of course, in my subclasser the WindowProc () Thunk
was created in Heap space so it gets deallocated in the middle
of processing and a Floating Point Inexact Result mismatch occurs,
leading to a crash or disappearance of the program. A simple
workaround of catching run-time errors is available (as you know),
but I don't know if a permanent solution is possible. I
experimented with locking the heap from another thread, but
when the crash occurs the VB engine is aware of all threads and
will unlock the heap and destroy it accordingly. Of course I will
still make other attempts at solving this problem, and if I run
into any successes I'll post them here. If anybody else has any
ideas please by all means post them.

On a sidenote, I have found quite a few bugs in the 'alpha'
build (as to be expected). They are currently all corrected in my
beta build... with the exception of this latest problem of course.

-CC

P.S. Sorry for not responding sooner. I was out of town on
business all week.

Quote:

---

the application will crash if any run time error occur

---

I did not get this error if I use the EventVB.dll to do the subclassing - the VB runtime error is displayed as expected....

Thanks Crunchy Cat for your reply

MerrionComputin, i am little bit hesitate to use EventVB.dll in my application coz i did not tested it properly, but i had a look at it, it was really nice...

shall i use EventVB.dll ??

We'll this has been a trippy ride. I finally found the definitive
cause of the problem. I thought it was heap deallocation, but
it turns out to be a stack corruption. When VB 6 (for binaries
only) partakes in a run-time error, it will nuke part of the stack.
Of course it nukes the most important part... where to return
to after the WndProc () is complete... so... *poof* there ya' go.

A solution? Well I hate to use the word impossible so, I'll
use 'improbable'. Every single VB subclasser is going to be
affected by this. The good news is that my subclasser wont
have any problems from the IDE and if you handle the error
in your binary then everything works fine (as you already
know).

MERRION & DIAMONDS, I am sorry to report that even
EventVB can't escape this negative 'behavior'. Take your version
'H' dll and do this:

A) Create a new project.
B) Add 1 form and 1 command button.
C) Link in the EventVB dll.
D) Add this code to the form:

Option Explicit

'\\ EventVB event sink classes, declared WithEvents
Private WithEvents apiLink As EventVB.APIFunctions
Private WithEvents apiWnd As EventVB.ApiWindow

Private Sub apiLink_ApiError(ByVal Number As Long, ByVal Source As String, ByVal Description As String)

'\\ Inform the user that an error has occured
MsgBox Description, vbCritical, "Error in " & Source

End Sub

Private Sub Command1_Click()
Dim a As Long

a = 1 / 0
End Sub

Private Sub Form_Load()
'\\ Initiate the EventVB link
Set apiLink = New EventVB.APIFunctions

'\\ Start subclassing this window
Set apiWnd = New EventVB.ApiWindow
apiWnd.hWnd = Me.hWnd
apiLink.SubclassedWindows.Add apiWnd
End Sub

Private Sub Form_Unload(Cancel As Integer)
'\\ Stop subclassing this window
apiLink.SubclassedWindows.Remove apiWnd
Set apiWnd = Nothing

'\\ Unlink the eventVB dll
Set apiLink = Nothing
End Sub


Private Sub apiWnd_Move(ByVal x As Long, ByVal y As Long, Cancel As Boolean)

Me.Caption = "Form at ( " & x & "," & y & ")"

End Sub

E) Compile the Project.
F) Close VB.
G) Run the compiled project.
H) Press the button.

You'll notice that the program crashes/disappears instead of
giving a run-time error dialog (I did this on NT 4.0 at the time
FYI).

MERRION, I know you are a long-time API/Subclassing wiz,
so if you have any ideas about this please let me know. Although
this problem can be dealt with quite easily by simply catching
and handling an error, I would prefer a purer solution if its
possible at all.

Thanks,

-CC

I coped your code, compiled up the exe and it gave me the error message as expected...I am running NT4 and VB5 (SP2)

Crunchy Cat, EventVB cashed with me also

i think the problem is not really diffecult to solve, just dont raise any event after the run time error occur, if there is a way to now that a run time error has occured, then the problem is easy to solve.

btw, r u using VB6 with or without SP ? if yes which SP ?

MerrionComputin, your Project1.exe shows ActiveX cant create object run time error, can you please send it again with the source code. probably there is something to do with the OS, i faced this problem with 98,2000 advanced servier and XP.

code is attached...

MerrionComputin, no use, just the same, but when i open the project VB didn't allocate the EventVB_H.DLL, it shows as missing, then i have selected the one installed with me, i think the version is not the same,

i found the the DLL is Beta R1.2.005 H, is it the same with you ?

Release Release 1.2.006 H, 24/09/2002.

It's code compatible with the previous version though except v6 has ApiWindow.CreateChildControl.

MERRION/DIAMONDS... I am using VB6 sp5... perhaps that
accounts for the EventVB crash that Diamonds and I have
but MerrionComputin does not. I hate to think this is all related
to MS bugs...

DIAMONDS, you mentioned "i think the problem is not really diffecult to solve, just dont raise any event after the run time error occur, if there is a way to now that a run time error has occured, then the problem is easy to solve". I actually tried
eliminating all event raising in my subclasser, yet I still got
the same problem. Did I mis-understand something you were
trying to communicate with me?

Crunchy Cat, maybe :) i will explain in detailed what happen with me,

on my DLL project i have one module and one class only, i raise evnet by calling a function in the Class using CallByName. the function will raise an evnet.

Now if i raise WindowProc event for any windows message, the program will crash on run time error, just like the following code: -

Public Function WindowProc(ByVal hwnd As Long, ByVal uMsg As Long, ByVal wParam As Long, ByVal lParam As Long) As Long
Dim p As Long
p = GetIndex(hwnd)
CallByName PrevProc(p).OBJ, "WindowProc", VbMethod, uMsg, wParam, lParam
WindowProc = CallWindowProc(PrevProc(p).Proc, hwnd, uMsg, wParam, lParam)
End Function

But, if i raise WindowProc for only resize messages the program doesn't crash, the code is :-


Public Function WindowProc(ByVal hwnd As Long, ByVal uMsg As Long, ByVal wParam As Long, ByVal lParam As Long) As Long
Dim p As Long
p = GetIndex(hwnd)
If uMsg = &H5 Then CallByName PrevProc(p).OBJ, "WindowResize", VbMethod
WindowProc = CallWindowProc(PrevProc(p).Proc, hwnd, uMsg, wParam, lParam)
End Function

i have made a test project that will write a 'debug' file for each message, i found that after the run-time error occur, there are 6 to 9 messages is beeing sent, riasing events after the run time error will crash the EXE,

Now we just have to stop the raising events immediately after the run time error occur, i think there is message sent by windows that tell run time error occur, am not sure about it, and i couldn't find it as well.

by the way, before EXE crash, you will hear the sound that comes with the run time error message box, the message box suppose to be displayed by windows, that means the crash happens after the message box (that suppose to be displayed)

sorry if my english is poor :)

Ahh I get it... and I think the fact that you got things to work
in the manner that you did unfortunately may be luck. I made
the same observations about the run-time error sound occuring
before the crash. In fact you can even MessageBox () (from the
Win32 API) Err.Description and kind of see whats going on.
It seems like any class/object instatiations, references, method
calls from within a WndProc () do something to the stack that
invalidates pushed information from the original WndProc () (only
when a VB Run-time error occurs). It's a crazy problem (thankfully
with a workaround), but MerrionComputin's DLL works in sp2
where as it does not seem to work in sp5... indicating this whole
stack thing may be an MS "feature".

yeah, its a crazy problem, i think the reason why MerrionComputin doens't have the problem is because of he is using NT4.

anyway, i really need to solve this problem, i have one project with 130+ forms and one OCX with 45+ forms and object, both are complex, and subclassing in everywhere! i will just be in a maze when any run time error occur.

Yep. I am still working on this problem. I trying to figure out
the rules behind this stack corruption and work around it. I
have had some very positive results but I still need to do some
more R&D work.

hello!

i just want to say that i have tried the code in your zip file... and i will try to post questions/troubles, to help in making the code run better.

thanks!

over and out!:eek:

Thanks bud... appreciate it.

Good news folks! I am close to figuring out a soution to this
stack problem. Stay tuned...

I was able to use a subclasser and pointer access to the Refresh buffer array to make form-drag-updating translucency in win95 but i need a way to keep the window from being drawn at its new position until the Refresh buffer is done rendering. It seems that our goals for using a subclasser are not dissimilar; indeed I will stay tuned.

Stuff all your WM_PAINT msgs on a stack and then process them
once the buffer is complete perhaps?


TO ALL:
I figured out the solution to the stack problem! Unhandled
VB run-time errors for binaries now appear as expected! I am
cleaning up the code now and I'll post it within 3 days.

... or maybe I'll just post the code tonight! :) Ok, this new build
boasts the same great features as the first AND:

* Will not prevent a natural unhandled run-time error from
processing properly in a compiled binary.

DIAMONDS & MERRION - Please compile and try the new build.
I want to ensure that it explicitly works in both of your
environments (the 3rd button in the sample app will generate
a Divide by '0' run-time error).

EVERYONE ELSE - Give me some feedback on this puppy. Alot of
of blood, sweat, and... well blood went into fixing this freakish
problem (which I am convinced is a MS flaw more than anything).

Thanks,

-CC

Hi Crunchy Cat,

I try to build your project (subby2) but it request one of your component the Logical Dreams String Helper Methods 1.0

Where could I get it?

Thanx

Note I saw your Deploment note but I don't found your
Logical Dreams String Helper Methods 1.0.0 - ldsHelper.dll

My bad, just uncheck the reference to it and I think you will be
ok. I commented out the functions that would actually use it.

Thanks,

-CC

I run your app and I saw yours messages and heard your sound than I press on the Button3, it raise an runtime error I saw the error code screen. Than I press the OK button the screen go and VB also.

I have VB6 pro (SP5) my OS is NT 4.00.1381 w IE 5 6.0.2600.0000

Is it normal that way or VB6 should have stay open I also haven't got any Dr Watson!

Hope this could help.

When I press debug Dr Watson pop up

look that screen if it could help


I also don'T know why it ask for drive A ?!?!?

Hi Aldragor, regarding your first post:

"Is it normal that way or VB6 should have stay open I also haven't got any Dr Watson!"

The question is not clear. If you mean "Is the compiled binary
supposed to disappear after you press Button3 and and then
press 'OK' on the runtime error dialog, the answer is 'Yes'".
That behavior is very specific to VB. If you meant something else
then please rephrase the question.

Regarding your second post, once again I am not entirely clear
what you did. You are referencing a 'Debug' button thus implying
that you are pressing Button3 from the IDE? I just can't tell.
Please restate exactly what happened (in terms of physical
actions and results if necessary).

Thanks,

-CC

Both time I press the play button with in VB6

When I get the error the first time I press the ok button and the second time I press the debug button.

I am not use to speek/write in english so if I am not clear don't worry about asking me to be precise.

The only thing I could say it's went running with VB went I pressed the 3rd button VB crash with the apps.

If you need more informations just ask!

I need subclassing in my project, it's a component who need trapping move event in design time, so I am happy to help, if I don't complicate it !! :)

Thanx

Hi Aldragor, if I am understanding you correctly you:

A) Launched 'MultiTestAppProject.vbp' using VB6 sp5 on
Windows NT 4.0 (what service pack for NT?).

B) Pressed the 'Start' button.

C) Pressed 'Button3'.

D) Pressed the 'OK' or 'Debug' button on the run-time error
dialog and experienced two types od IDE crashes.

Is this correct? Perhaps the NT Service pack is what makes the
difference. I tried this on Win2k sp3, WinNT 4.0 sp6, and WinME
without problems.

-CC

Aldragor, I just had a random idea on why you are experiencing
the problem at hand (BTW any questions from my previous posts
still stand). To test the hypothesis I have prepared two binary
DLLs for you to try. Please register them and let me know if
the problem you experienced reproduces. No miracles here... just
a test...

-CC

I have SP6 on Windows NT

I try the 3rd button only 3 times (all within VB6 environment) 2 time I press the ok button on the run time error dialog -> result VB crach with any call to DrWatson and one time I pressed the debug button in that case DrWatson show up but I doesn't been about to look at the log message.

I look for these dll's and give you the result

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