MSOUTL.OLB Version 9.4 missing (2 Viewers)

[MrHans]

Also, take a look at this article from Daniel Pineault, he explains how to add conditional compilation to the code so you can actually switch between late binding and early binding.

https://www.devhut.net/2017/02/16/vba-early-binding-and-late-binding-part-2/

 

[Uncle Gizmo]

Daniel Pineault site is the best!

Sent from Newbury UK

 

[The_Doc_Man]

Another issue with Outlook is that you might have two versions installed but can only use one of them at a time. If you attempt to launch Outlook and one is already running, the second launch WILL fail. I know because I dealt with this one myself when trying to set up some automated e-mails. If Outlook is running, you can't create a new Outlook application. You have to try to find the already-open one so that you can "ride" on that copy. I couldn't figure out what was wrong with my CreateObject until I found the article (on this forum) that explained that fact.

 

[Eljefegeneo]

The first code in Post #20 runs with no error but it does not seem to transfer the appointment to my Outlook. I check my old code on the non-Test Db and it works fine. The second two codes throw the following error message:
Run Time Error 1-2147417851 (80010105) Method of To of object' _ Mail Item Failed.
My code is as follows for the send mail item: (throws the error)

  Dim olApp As Object
  Dim mItem As Object
  Set olApp = CreateObject("Outlook.Application")
  Set mItem = olApp.CreateItem(0)
  With mItem
      .To = Me.To
      .CC = CC2
      .BCC = BCC2
      .Subject = Me.SubjectLine
      .Body = Me.MessageBody

Code for Appointment item: (No errors but does not add an appointment

  Dim outobj As Object
  Dim outappt As Object
  Set outobj = CreateObject("Outlook.Application")
  Set outappt = outobj.CreateItem(1)
  With outappt
  .Start = Me!ApptDate & " " & Me!ApptTime
  .Duration = Me!ApptLength
  .Subject = Me!Appt

Code for Task item: (throws the error)

  Dim outobj As Object
  Dim outtask As Object
  Set outobj = CreateObject("Outlook.Application")
  Set outtask = outobj.CreateItem(3)
  With outtask  'New Code Not working
  .Subject = Task
  .StartDate = Me!TaskDate
  .ReminderTime = Me!TaskTime & Me.RemdDate
  .Status = Me.TaskStatus
  .Importance = Me.TaskImportance
  .ReminderSet = True

I rechecked my non-test DB and the code with early binding works fine.

 

[Eljefegeneo]

OK, after much research – my favorite thing to do on a Saturday afternoon – I found the following "fix". It was to add CStr([item]) to the code as follows and now it seems to work OK on my home machine (not yet tested on the machine causing the problem in the first place).

  Dim olApp As Object
  Dim mItem As Object
  Set olApp = CreateObject("Outlook.Application")
  Set mItem = olApp.CreateItem(0)
  With mItem
      .To = CStr(Me.To)
      .CC = CStr(CC2)
      .BCC = CStr(BCC2)
      .Subject = CStr(Me.SubjectLine)
      .Body = CStr(Me.MessageBody)

So it would seem to me that the code requires the CStr function to work properly. I am curious to know why this is necessary. Am I missing a reference? And so which one.?

 

[Eljefegeneo]

And I amended the other code to include the CStr function and now all is OK. The big test will be on Monday to see if it functions correctly on the miscreant new machine. Hopefully it will and I can go back to my golf game. I don't want to jinx this by thanking everyone just yet, but the message will be coming on Monday.

 

[theDBguy]

And I amended the other code to include the CStr function and now all is OK. The big test will be on Monday to see if it functions correctly on the miscreant new machine. Hopefully it will and I can go back to my golf game. I don't want to jinx this by thanking everyone just yet, but the message will be coming on Monday.

Hi. Glad to hear you got it sorted out and good luck on Monday. Unfortunately, I cannot tell you why you need to use CStr() because I didn't have to. Cheers!

 

[Micron]

What looks suspect to me is:
- To is a reserved word
- CC2, BCC2 and MessageBody look like variables. Are they declared as Strings? If not, they may be variants. While I'd expect their values to be recognized as strings if they so resemble, not declaring them is not wise. Could that be why you must use the string conversion function? Or perchance the values are numeric before the conversion, which ought to fail. If they're form fields, why no Me. reference?
- you mix Me! and Me. Why is that? Me! won't compile until run time and if the child object is misspelled, you'll generate a run time error.

 

[The_Doc_Man]

At least in theory any value assignment using an equals-sign gets a "free" conversion from one compatible type to another. Therefore, if you really needed the CStr() then VBA must think that something is wrong with the thing that needed it. Which in this case would have to be the (actual) argument of the function. To need CStr in that context, the thing inside must be neither a string nor a variant.

Me.To SHOULD be a reference to a text box, but what format was selected for that box? Concur with Micron that the use of CC2 & BCC2 are suspicious. If the CStr() fixed these assignments then the next question is, do you have variables of those names that are declared as strings? If not, then you must not be running with Option Explicit because if you were, you should get an error.

 

[Eljefegeneo]

Thank you for the last two replies. The question remains that this problem of needing the CStr function did not occur until I chose to use Late Binding. Does that have anything to do with it? No other part of the code was changed.



As I said before, I have to wait until Monday to test it on the errant new machine.

 

[Micron]

needing the CStr function did not occur until I chose to use Late Binding. Does that have anything to do with it?

It would surprise me if it had anything to do with the particular lines of code. The issue of early/late binding affects when objects and their methods/properties/references are compiled and checked. CStr is a built in Access function and I strongly suspect does not enter into the picture when it comes to binding. I still maintain that what you're using to use the function against is suspect. I have read that when upgrading to later versions of Access, things that would squeak by (in terms of less than perfect coding) no longer will and that syntax, referencing etc. have to be more 'perfect' than what they were before the upgrade.

 

[theDBguy]

Thank you for the last two replies. The question remains that this problem of needing the CStr function did not occur until I chose to use Late Binding. Does that have anything to do with it? No other part of the code was changed.

As I said before, I have to wait until Monday to test it on the errant new machine.

Hi. I'm just curious and can't wait until tomorrow. I created a small demo of what I would normally use. Could you please give it a try and let us know if you get the same errors? Thanks.

 

[The_Doc_Man]

Concur with Micron. I've seen many articles in this forum where a version upgrade led to the syntax becoming extremely strict.

In order to need to use CStr(), and to get run-time errors if you don't, the question has to be "what type does Access think the right-hand expression is?" Obviously, it knows that the left-hand side of the assignment is a string because it "shuts up" if you use CStr() in that context. I might set a breakpoint on that line of code and open the immediate window to Debug.Print the right-hand side argument, Me.To, in order to see what it is. I would also do a Debug.Print VarType(Me.To). You would have to interpret the code that comes back, so here is a link to the reference article that lists the codes.

https://support.office.com/en-us/article/vartype-function-1e08636c-1892-40c2-aff3-2b894389e82d

Probably wouldn't hurt to do the same for the next two lines of code to verify data types.

 

[Eljefegeneo]

DBGuy:
Thanks. I tried it but it threw the same error as mine. So I changed it to:

With olMail
    .To = CStr(Me.txtTo)
    .Subject = CStr(Me.txtSubj)
    .HTMLBody = CStr(Me.txtBody)
    .Display
 End With

And it works.
Perhaps there is just something wrong with my Access Program.

 

[theDBguy]

DBGuy:
Thanks. I tried it but it threw the same error as mine. So I changed it to:

With olMail
    .To = CStr(Me.txtTo)
    .Subject = CStr(Me.txtSubj)
    .HTMLBody = CStr(Me.txtBody)
    .Display
 End With

And it works.
Perhaps there is just something wrong with my Access Program.

Hi. Thanks for confirming that. Just to clarify as well, the demo, as is, doesn't give me any errors on my machine. Can you post a link to where you saw the CStr() trick mentioned?

 

[Micron]

Perhaps there is just something wrong with my Access Program.

with respect to CStr(Me.txtTo) or Me.To - I said way back in post 28 that To was a reserved word. If you use reserved words, expect trouble.


EDIT - suggest you adopt one of these:
http://access.mvps.org/access/general/gen0012.htm

https://www.access-programmers.co.uk/forums/showthread.php?t=225837
txt prefix not only virtually guarantees you won't use reserved words, it tells you what the data type is 6 months later when you won't remember.

 

[Eljefegeneo]

The following post gave me the hint to use the CStr() function.

https://access-programmers.co.uk/forums/showthread.php?t=290214. It was on this forum!

 

[theDBguy]

The following post gave me the hint to use the CStr() function.

https://access-programmers.co.uk/forums/showthread.php?t=290214. It was on this forum!

Hi. Thanks for the link. In Post #15 in that thread, CJ asked a question that I don't think was ever answered. Would you mind testing it for us, so we can also confirm it? His question was what would happen in you tried it this way:

    .To = Me.To.Value

or using my demo:

    .To = Me.txtTo.Value

 

[Eljefegeneo]

I'm all Accessed out right now but will try it tomorrow.

 

[theDBguy]

I'm all Accessed out right now but will try it tomorrow.

Appreciate that. It would be nice to find out the answer and maybe we can get to the bottom of the issue.