DocumentEvents OnChange -> Procedure declaration does not match description of event

[Bert_Bimmel]

Hello Everybody,

may anyone help me here? I can't find the butter in the fridge: The left code which tries to catch a UIEvent works perfectly fine. The right one refuses to and tells me, my declaration does not match the description etc. blah blah..., although i cannot find any discrepancy to the documentation:

Cheers, Bert

[bradeneuropeArthur]

Hey "Bert_Bimmel" how are you doing?
Let me have a look for you!
Regards,
Arthur

[WCrihfield · Accepted solution]

Hi @Bert_Bimmel.  Just a quick note that may help here.  In pretty much every one of these things, the HandlingCodeEnum type variable should be declared with 'ByRef' instead of 'ByVal'.  The other are usually just fine with 'ByVal'.  That is one snag I ran into several times early on...and the documentation may not indicate this properly, but sometimes you can catch it within the text of the error message...which I think is where I picked it up.

[Bert_Bimmel]

@WCrihfield : That did the trick. Thank you very much. 

Maybe this was the key hint I didn't see:

But on the other hand, to me that would make sense for all parameters, because i do not hand over any information to the event, do I? I dont't think so: In my understanding all of these parameters are information that the event hands over to me, so I can deal on them.

E.g. the EventTimingEnum: This is some Information that I receive and do not send (i.e. an output). In other words: I do not tell the event "fire before" or "fire after", it fires twice anyway, and i can choose in which of the two cases i want to react when i look at it's acual value.

But if I set that one to ByRef, the whole thing doesn't work again.

I'm happy that it works now, but either I have a basic misunderstandig about event handling, or the whole thing isn't very coherent.

Cheers Bert

[WCrihfield]

That last one 'HandlingCode' allows you to change the way the event is handled after you are done with it.  The others are as you said, just information for our convenience.  I didn't realize this my first couple of times either...and sometimes it just doesn't matter, because you may just choose not to deal with it, one way or the other.  It is a good way to prevent certain 'no no's' that you don't want to happen, by checking something about the event, then specifying to abort the action, before it happens.  Other times you are only using the event to gather data, and don't want it to go further than that, so you can set it as handled.  And so on.  Glad I was able to help.  Good luck in your automation plans.

[Bert_Bimmel]

Ok, I think I just have difficulty in changing my role from caller to callee:

Normally, when I call a System function, i provide some arguments, and prepare some neat place where that function can put its result, which I pass as a memory address (i.e. ByRef, or in C-Slang: a Pointer).

Didn't really see, that I am the callee here, and I can pass some result back to the event which calls me.

With that point of view, the whole thing starts making sense to me.

Thanks again for this explanation!