CustomPropertyChange triggered by Init Value?? Help!

[Abe Hendin]

I'm coming back to this OLXP project after maybe a year away to update a
few things, and I'm seeing behavior I don't remember. I'm hoping
bouncing it around here will get me back on track and out of this
confoundeed brain cramp...

I've got a field, StudentStatus, on a custom Contact form. When a new
contact is created, that field's initial value is set to "Not a Student"
by the control itself: that is, I've specified the initial value
property on the control.

The trouble is that this is triggering the CustomPropertyChange event,
which then throws up an error box that shouldn't be triggered when the
contact is first created, only when the user changes the StudentStatus
manually (and if certain conditions apply). Is it always the case that
specifying an init value on a custom control will trigger a
CustomPropertyChange event during the Item_Open event?

In another set of routines I set a "Processing" flag to prevent
CustomPropertyChange events from firing up subroutines when I don't want
them to, and I suppose I could try the same here, in the hopes that
setting that flag as the first entry in the Item_Open event SUB will be
early enough to catch it. I just don't remember this behavior in this
case previously, and I'm wondering if anyone can shed light on it.

Thanks for any thoughts,

Abe

 

[Sue Mosher [MVP-Outlook]]

Try this -- Don't process CustomPropertyChange until Item_Open has
completed:

Dim blnIsOpen

Function Item_Open()
blnIsOpen = False
' initialization code goes here
blnIsOpen = True
End Function

Sub CustomProperyChange(ByVal Name)
If blnIsOpen Then
' do your property change processing
End If
End Sub

 

[Abe Hendin]

That's what I was trying to accomplish with my flag, but I think this
method is much better insofar as it doesn't require changing a form
property--doh! Thanks, Sue, I'll give this a shot.

One probably foolish question: my Item_Open() is a SUB. Does it matter?
This is all VBScript code behind a form (Form, View Code). [I should
probably have dinner before asking this Q...]

I'm still quite curious as to why this hasn't come up until the 8th
version of this project... weird. I just checked with the user and it
isn't happening on her system, so I'm completely mystified.

Abe

 

[Sue Mosher [MVP-Outlook]]

Item_Open should be declared as a Function, not a Sub. Yes, it matters,
because to cancel an event like that, you set the result to False, e.g.
Item_Open = False.

--
Sue Mosher, Outlook MVP
Author of
Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers

That's what I was trying to accomplish with my flag, but I think this
method is much better insofar as it doesn't require changing a form
property--doh! Thanks, Sue, I'll give this a shot.

One probably foolish question: my Item_Open() is a SUB. Does it matter?
This is all VBScript code behind a form (Form, View Code). [I should
probably have dinner before asking this Q...]

I'm still quite curious as to why this hasn't come up until the 8th
version of this project... weird. I just checked with the user and it
isn't happening on her system, so I'm completely mystified.

Abe

Try this -- Don't process CustomPropertyChange until Item_Open has
completed:

Dim blnIsOpen

Function Item_Open()
blnIsOpen = False
' initialization code goes here
blnIsOpen = True
End Function

Sub CustomProperyChange(ByVal Name)
If blnIsOpen Then
' do your property change processing
End If
End Sub

 

[Abe Hendin]

Item_Open should be declared as a Function, not a Sub. Yes, it matters,
because to cancel an event like that, you set the result to False, e.g.
Item_Open = False.

Can you give me a brief example? When would you want to cancel Item_Open
and how would you do it?

Using the boolean to prevent CustomPropertyChange from executing works
perfectly. Thanks again.

BTW, I finally just ordered your book! (haven't done OL programming
pretty much since it came out)

 

[Sue Mosher [MVP-Outlook]]

The form launcher form at
http://www.outlookcode.com/d/forms/formlauncher.htm is a good example. It's
sole purpose is to launch another form (in part as a workaround to the
limitation that you can't make a message form the default for a folder, but
it has many other users). After it launches the other form, it cancels its
own Open event, so it never opens:

Function Item_Open()
' form launching code goes here
Item_Open = False
End Funcntion

--
Sue Mosher, Outlook MVP
Author of
Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers

 

[Abe Hendin]

Thanks, Sue.