Re: VB Script not executing

From: Sue Mosher [MVP-Outlook] (suemvp_at_outlookcode.com)
Date: 12/13/04 

Date: Mon, 13 Dec 2004 13:35:05 -0500

Very interesting. There's a hotfix to suppress signatures on custom forms in
Outlook 2002 SP3. Maybe it would help? See
http://www.outlookcode.com/d/ol2002problems.htm#sp3 under "Design Changes." 

-- 
Sue Mosher, Outlook MVP
Author of
     Microsoft Outlook Programming - Jumpstart for
     Administrators, Power Users, and Developers
     http://www.outlookcode.com/jumpstart.aspx
"Mike Morgan" <MikeMorgan@discussions.microsoft.com> wrote in message 
news:19741EFD-6F50-4246-B095-81D7543A6C5E@microsoft.com...
> Hi Sue,
>
> I found out what was happening but it was a long and *arduous* task. It
> still seems a bit odd... Your suggestion about creating some dummy code in
> other forms helped. For the record here is what happened (on offending
> workstation):
>
> Created dummy form with code that instatiated the DLL,
> -- worked fine
> Revisited original codes Item_Open code, specifically function call to
> verify that the DLL installation was Ok which returned True or False.
> Republished form so that function always returned True.
> -- still did not work
> Brought code into a vbs script file and executed form command line.
> -- worked fine
> Scratched head in disbelief
> -- helped but didn't solve problem
> Just for the heck of it I turned off users Signature (since I had an If
> statement that checked Len(Item.Body))
> -- worked fine. Now the troubling part here is that I turned Signatures ON
> on my workstation and didn't have a problem. The signature is apparently
> applied before the Open event fires on XP sp3 and beyond. Also why wasn't
> this happening on the dummy form I created...
>
> Anyway, Thanks for the help. Mike
>
>
>> > Unfortunetly this is the only form with custom code.
>> >
>> > Don't know if it is relevent or not but another reason why I suspect
>> > Office
>> > XP and service pack issues may be involved is that OXP SP2 runs fine, 
>> > OXP
>> > SP3
>> > doesn't execute. Removing the users profile and rolling them back to 
>> > OXP
>> > SP2
>> > solves the problem but is alot of work and not my responsibilty so I 
>> > have
>> > no
>> > control over it. And is really tantamount to a clean install anyway.
>> >
>> > I will give detect & repair a try. Anyway. thanks for your help but I
>> > suspect this is one where reformat and new install is the fix.
>> >
>> > Thanks again. Mike
>> >
>> > "Sue Mosher [MVP-Outlook]" wrote:
>> >
>> >> Detect & Repair replaces files and repairs correct registry entries. 
>> >> It's
>> >> a
>> >> standard troubleshooting step, espeically for issues with no known 
>> >> cause.
>> >>
>> >> Normally, Session is not used but instead you instantiate a Namespace
>> >> object
>> >> with Application.GetNamespace.
>> >>
>> >> If might be useful to know if other Outlook custom form code works for
>> >> this
>> >> particular user.
>>
>> >>
>> >>
>> >> "Mike Morgan" <MikeMorgan@discussions.microsoft.com> wrote in message
>> >> news:1B026E1D-CB22-434A-B074-D6DD97918696@microsoft.com...
>> >> > My understanding is Session is a root object, there is no need for
>> >> > instantiation other than the user opening Outlook in the normal 
>> >> > course
>> >> > of
>> >> > events (ie the user opening Outlook from there shortcut). In the VBA
>> >> > immediate window you can type in:
>> >> > ?Session.CurrentUser and it will return whoever it is. Also as I
>> >> > mentioned
>> >> > this is not part of the problem. This routine is a Private routine 
>> >> > that
>> >> > never
>> >> > gets called. I made it public as a quick test. I don't recall what 
>> >> > the
>> >> > error
>> >> > message was.
>> >> >
>> >> > What does Detect & Repair do and why would it enable or disable code
>> >> > from
>> >> > executing in a form?
>> >> >
>> >> > "Sue Mosher [MVP-Outlook]" wrote:
>> >> >
>> >> >> > Everything was deleted below:
>> >> >> > C:\...\Local Settings\Application Data\Microsoft\FORMS
>> >> >> >
>> >> >> > Is that what you mean by 'delete the entire contents of the Forms
>> >> >> > folder.'?
>> >> >>
>> >> >> Yes.
>> >> >>
>> >> >> > I can say that in debugging this I went into the VbaProject.OTM
>> >> >> > module
>> >> >> > on
>> >> >> > the offending station and the following would throw an error:
>> >> >> >
>> >> >> > Set fldrRoot = Session.Folders.Item("Mailbox - " &
>> >> >> > Session.CurrentUser)
>> >> >>
>> >> >> How is Session instantiated? What error?
>> >> >>
>> >> >> If you haven't run Help | Detect & Repair, you might want to try 
>> >> >> that.
>> >> >>
>> >> >> > Session.CurrentUser was the offending call. Note that the 
>> >> >> > procedure
>> >> >> > this
>> >> >> > occurs in is never called so it is not part of the problem. 
>> >> >> > Though
>> >> >> > it
>> >> >> > is
>> >> >> > noteworthy that on my workstation this same code runs without 
>> >> >> > error.
>> >> >> > It
>> >> >> > is
>> >> >> > this error (along with some other things) that makes me think 
>> >> >> > this
>> >> >> > is a
>> >> >> > problem related to some security patch issue. I've been wrong 
>> >> >> > before
>> >> >> > though...
>> >> >> >
>> >> >> > Regards, Mike
>> >> >> >
>> >> >> >
>> >> >> > "Sue Mosher [MVP-Outlook]" wrote:
>> >> >> >
>> >> >> >> There is no setting that affects this, as long as the form is
>> >> >> >> published
>> >> >> >> and
>> >> >> >> not one-offing. In addition to clearing the forms cache, you 
>> >> >> >> might
>> >> >> >> want
>> >> >> >> to
>> >> >> >> delete the entire contents of the Forms folder.
>> >> >> >>
>> >> >> >> "Mike Morgan" <MikeMorgan@discussions.microsoft.com> wrote in
>> >> >> >> message
>> >> >> >> news:485AD042-8579-4520-BD86-4AD040993B37@microsoft.com...
>> >> >> >> > No it is the creator (not the recipient) of the email where 
>> >> >> >> > the
>> >> >> >> > script
>> >> >> >> > does
>> >> >> >> > not run. The DLL is definitely registered on the creator
>> >> >> >> > workstation...
>> >> >> >> > It
>> >> >> >> > is
>> >> >> >> > very odd. Like I say this runs fine on about 99.9 percent of 
>> >> >> >> > the
>> >> >> >> > workstations
>> >> >> >> > (about 350 or so). The only thing I can think of is some 
>> >> >> >> > Sevice
>> >> >> >> > Pack
>> >> >> >> > setting
>> >> >> >> > restricting the execution of the code. I can post code if you
>> >> >> >> > think
>> >> >> >> > it
>> >> >> >> > would
>> >> >> >> > help.
>> >>
>> >> >> >> > "Sue Mosher [MVP-Outlook]" wrote:
>> >> >> >> >
>> >> >> >> >> And it's the recipient who is opening it from **their own**
>> >> >> >> >> Inbox
>> >> >> >> >> and
>> >> >> >> >> not
>> >> >> >> >> seeing the script run?  Is it possible the problem machines
>> >> >> >> >> don't
>> >> >> >> >> have
>> >> >> >> >> the
>> >> >> >> >> ..dll registered?
>> >> >> >>
>> >> >> >> >> "Mike Morgan" <MikeMorgan@discussions.microsoft.com> wrote in
>> >> >> >> >> message
>> >> >> >> >> news:F99DE014-63CD-4C43-AC4E-8C26D4376AEC@microsoft.com...
>> >> >> >> >> > The item is sent out as an email. When it arrives at the
>> >> >> >> >> > destination
>> >> >> >> >> > it
>> >> >> >> >> > goes
>> >> >> >> >> > into the Inbox for the recipient.
>> >> >> >> >> >>
>> >> >> >> >> >> > If you are thinking it is a forms cache issue I have
>> >> >> >> >> >> > cleared
>> >> >> >> >> >> > out
>> >> >> >> >> >> > the
>> >> >> >> >> >> > forms
>> >> >> >> >> >> > cache which reinstalls the form the next time the above
>> >> >> >> >> >> > stuff
>> >> >> >> >> >> > happens.
>> >>
>> >> >> >> >> >> >> "Mike Morgan" <Mike Morgan@discussions.microsoft.com>
>> >> >> >> >> >> >> wrote
>> >> >> >> >> >> >> in
>> >> >> >> >> >> >> message
>> >> >> >> >> >> >> news:EB74C7B6-8824-45FA-9F06-EE3FB85D770B@microsoft.com...
>> >> >> >> >> >> >> >I have a form in the Organizational Forms Library with
>> >> >> >> >> >> >> >some
>> >> >> >> >> >> >> >script
>> >> >> >> >> >> >> >in
>> >> >> >> >> >> >> >it.
>> >> >> >> >> >> >> > This forms script instantiates a DLL that gets user
>> >> >> >> >> >> >> > input,
>> >> >> >> >> >> >> > then
>> >> >> >> >> >> >> > the
>> >> >> >> >> >> >> > forms
>> >> >> >> >> >> >> > script reads that and populates the message body of 
>> >> >> >> >> >> >> > the
>> >> >> >> >> >> >> > email
>> >> >> >> >> >> >> > and
>> >> >> >> >> >> >> > sets
>> >> >> >> >> >> >> > a
>> >> >> >> >> >> >> > UserProperty.
>> >> >> >> >> >> >> >
>> >> >> >> >> >> >> > In 99.9 percent of the cases this is all running fine
>> >> >> >> >> >> >> > and
>> >> >> >> >> >> >> > dandy
>> >> >> >> >> >> >> > except
>> >> >> >> >> >> >> > for
>> >> >> >> >> >> >> > a
>> >> >> >> >> >> >> > few cases where Office is XP is installed (generally 
>> >> >> >> >> >> >> > we
>> >> >> >> >> >> >> > run
>> >> >> >> >> >> >> > Office
>> >> >> >> >> >> >> > 2000).
>> >> >> >> >> >> >> > I
>> >> >> >> >> >> >> > have Office 2003 on a secondary workstation that the
>> >> >> >> >> >> >> > above
>> >> >> >> >> >> >> > scenario
>> >> >> >> >> >> >> > works
>> >> >> >> >> >> >> > fine on. Based on that I thought that upgraded the XP
>> >> >> >> >> >> >> > installations
>> >> >> >> >> >> >> > to
>> >> >> >> >> >> >> > 2003
>> >> >> >> >> >> >> > would solve the problem but it doesn't on those 
>> >> >> >> >> >> >> > machines
>> >> >> >> >> >> >> > that
>> >> >> >> >> >> >> > had
>> >> >> >> >> >> >> > XP
>> >> >> >> >> >> >> > installed. When I login to those machines with the 
>> >> >> >> >> >> >> > newly
>> >> >> >> >> >> >> > installed
>> >> >> >> >> >> >> > Office
>> >> >> >> >> >> >> > 2003 and setup Outlook the above form executes the 
>> >> >> >> >> >> >> > form
>> >> >> >> >> >> >> > script
>> >> >> >> >> >> >> > just
>> >> >> >> >> >> >> > fine.
>> >> >> >> >> >> >> >
>> >> >> >> >> >> >> > This leads me to believe that there is probably a
>> >> >> >> >> >> >> > registry
>> >> >> >> >> >> >> > setting
>> >> >> >> >> >> >> > in
>> >> >> >> >> >> >> > HKEY_CURRENT_USER that maybe affecting code 
>> >> >> >> >> >> >> > execution.
>> >> >> >> >> >> >> > Does
>> >> >> >> >> >> >> > anyone
>> >> >> >> >> >> >> > know
>> >> >> >> >> >> >> > what
>> >> >> >> >> >> >> > that setting might be?
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >>
>> >>
>>
>>
>>

Relevant Pages
Loading