Sending Emails with attachments

[John Montenigro]

OK, I'm making progress. Once I have something solid, I'll clean it up and post it.

But in the meantime, I have an observation. The posted code shows:

Code Select Expand

Flds.Item(schema & "sendpassword").Value =  "mypassword"

Instead, I'm suggesting that as a minimum, the password be coded like this:

Code Select Expand

      pw = Chr$(112,97,115,115,119,111,114,100)   ' password
      ? pw   'comment this out after development tests...
      Flds.Item(schema & "sendpassword").Value     = pw

...because the PB compiler will embed "mypassword" as a literal, and you can see it "plain as day" in the .EXE when you view it in a hex editor/file viewer.

Instead, the PB compiler interprets the CHR$() command sometime "on the fly", so it's never embedded in the .EXE. Yet you can still verify it easily, as the msgbox command shows.

I know there are better ways to do this, but this method works fine during development & initial checking...

-John

[David Kenny]

John,

You could also read an encrypted password from a file and decrypt it.  But your way would be just fine.  I now see that you are just talking about using the password embedded in the program for development only.  I didn't realize that when you asked about it before.  I am comfortable just using the literal for testing as others don't have access to it my test programs and my password is changed often enough.

[John Montenigro]

Thanks for the feedback, David, I just wanted developers to recognize a possible weakness in the published code that they could address easily...

UPDATE:
From home, I was able to determine settings that allowed me to successfully send an email with attachment from my comcast and my gmail accounts.

Unfortunately, I was not able to determine the proper settings to send through my MS Exchange work account. What's strange is that I can do it through Thunderbird, but not through my own program. And I tried every combination of settings I could.

Well, I can see I have a lot more reading to do over the weekend...
-John

[José Roca]

For sending emails using Exchange, see:

http://msdn.microsoft.com/en-us/library/aa494235%28v=exchg.80%29.aspx

[John Montenigro]

For sending emails using Exchange, see:

http://msdn.microsoft.com/en-us/library/aa494235%28v=exchg.80%29.aspx

Where do you FIND these things?!?

You are truly amazing!!

I'm reading and testing it now!

Thanks!!!!!
-John

[John Montenigro]

OK, now here's where my ignorance really shines brightly!

I'm converting the example VBS code, and there's a statement up front that I cannot resolve:

Code Select Expand

   Dim Conn        As ADODB.Connection


Here's how I try to figure it out:
- search all the JR header files for "ADODB.Connection"
- read and examine all matches and the surrounding lines/sections of text and code.
- try to find "ADODB.Connection" at MSDN.

Before JR headers, I could usually dope it out. But the JR headers are in a different kind of notation, and I don't know how to read it.

I guess that sums up my biggest problem in recent years - that since the move to COM, PB files are written in a new language, and I don't know where to learn all the details.

I can read the files and figure out some of the things, but the deeper significance of a lot of the notation, I just cannot follow, let alone comprehend!

Attributes, properties, methods are pretty self-explanatory. It's the way that various groups of them relate to others that isn't easy to grasp.

If I wanted to get proficient in understanding a whole file (not just fragments here and there), where could I go to get simple explanations? I need to understand how the whole INC is structured, what it contains, all the sections, and how they relate to each other...

Did I just hijack my own thread? Maybe I should start another just for this topic...
[ADDED: OK, I just did:  http://www.planetsquires.com/protect/forum/index.php?topic=3542.new#new]

Let's keep this thread focused on CDO email code...

-John

[John Montenigro]

OK, following the example Jose gave me in the other thread, I tried the same pattern of conversion for two other objects:

Code Select Expand


' Dim Msg    As CDO.Message
Local Msg    As CDOMessage
' Dim Config As CDO.Configuration
Local Config As CDOConfiguration

' Create message and configuration objects.
'   Set Msg = CreateObject("CDO.Message")
   Msg = NewCom "CDO.Message"

'   Set Config = CreateObject("CDO.Configuration")
   Config = NewCom "CDO.Configuration"


Of course, I first searched the headers for "CDO.Message" to see where it was defined, and found it in CDOSys.inc.

So I examined it and related files, and concluded that the file I needed to #INCLUDE is "CDOSYS.inc"

But now PBWIN is complaining that it can't find a TYPE definition for "CDOMessage".

Here's where I get confused as to how to resolve this: I cannot find a TYPE definition for "CDOMessage" in any of the header files.

I do see in "cdoexstr.inc" that there's a section of values in a section entitled "CdoContentTypeValues", but I've never seen strings that start with two dollar-signs ($$), and I don't know what that signifies.

In that list are entries such as

Code Select Expand

$$cdoMessageExternalBody       = "message/external-body"$$

...but there are similar items sprinkled throughout the file. It's not clear to me why they're all spread out like that.

I have no doubt that there is documentation for such things, so I search MSDN for it and find:

http://msdn.microsoft.com/en-us/library/ms527255(v=EXCHG.10).aspx

I can't understand this page, so I go up a level and start examining what's there. I notice that there's an entry for "CDOConfiguration", so I am tempted to go there. But I also notice that there's NO entry for CDOMessage...

So I go up another level, and now I can see the broad scope, and I'm lost...

That's when I come to the forum and ask for help, and my question comes out like this:
"Why is PBWIN complaining about this, when I've included the only file that looks like it deals with this object?"

Code Select Expand

Local Msg    As CDOMessage

OK, enough of my sob story... Can anyone see an avenue that I haven't explored? or a method for tracking down these kinds of things?

I appreciate being directed to something I can read and learn from!
Thanks,
-John

[José Roca]

VB is using Automation and my example low-level COM. Verfy different animals. In my headers, the interface is called CDO_IMessage.

You can't translate examples from other languages literally. You can read them to get an idea of what you have to do and then adapt it to the syntax of your tool.

[John Montenigro]

Yes, I do know that translation is complicated and takes effort; I actually enjoy doing the work.

I just need to know how to distinguish one thing from another!

Thanks for the guidance, I'll keep at it.

-John

[David Kenny]

Jose took care of most of this in your other thread, but in regards to this:

Code Select Expand

$$cdoMessageExternalBody       = "message/external-body"$$

It's a PB string constant statement.  First "$$" means its a unicode constant, named cdoMessageExternalBody.  The string being assigning to the Equate is "message/external-body" and the second "$$" says this is a unicode string. For more info, type "string equates" into the index tab of the PB help file.

But now PBWIN is complaining that it can't find a TYPE definition for "CDOMessage".

It used to be that the only variable type besides built-in types (integer, string, dword, etc.) were UDT's.  PB's message should probably say "undefinded type or interface" now. If you search the CDO includes for interface definitions you will find CDO_IMessage and CDO_IConfiguration. (added: looks like he beat me to it)

Sounds like... rather, reads like you are getting frustrated.  Been there. You are just in an unfamiliar area. COM, PB classes (the differences between them), unicode, etc.  It gets better, and you will start to pick it up soon.  I'm only a little ahead of you in these area's myself.

David

[José Roca]

It happens that the name of an interface is irrelevant. You could rename it as John_Montenigro_Message and it will work just changing DIM pIMessage AS CDO_IMessage to DIM pIMessage AS John_Montenigro_Message. What counts is the unique GUID that identifies it, i.e. GUID$("{CD000020-8B95-11D1-82DB-00C04FB1625D}") in the case of that CDO interface. By convention, low-level COM interfaces are prefixed with an "I" of interface, but isn't mandatory, just convenient. So, in CDO, there is an Automation object called Message and a low-level interface called IMessage. But it happens that in other components there are also objects and interfaces with that common name, so to avoid conflicts, I have added "CDO_" as a prefix.

To complicate matters, nobody looks at the C++ examples, as they should, because they use a weird syntax, but at the VB examples, that use the Automation Message object instead of the IMessage interface.

[David Kenny]

Jose,

First off, I am sure you know what regular expressions are and how to use them.  The information below is meant to help other people find information quickly if they don't already have a system of their own.

It happens that the name of an interface is irrelevant.

But you have kept it close enough to relevant.  I use baregrep to search your include files regularly (no pun intended). It's a free utility that searches files using regular expressions. I can usually find what I'm looking for with a couple educated guesses in a minute or two.  Even if I don't know the Interface name, I can still search for all Interfaces and inspect them manually.

From the ReadMe.txt that came with my current version of your headers:

This version has been updated using the SDK for Windows 7.1.

In less than ten seconds baregrep, using this expression "^\s*interface" (^ = Newline, \s* = zero or more whitespace), finds 7,831 interfaces in 517 of 1,184 include files searched.  That is using a "*.inc" wildcard on the file names.  Your file naming convention is really handy.  If I change from wildcards to regular expression for file filtering in baregrep, and use the expression "cdo" (find "cdo" anywhere in a filename similar to "*cdo*" using wildcards), then the list is reduced to 39 interfaces in 2 files of 4 searched.

7,831 interfaces!!!  That is why all of us will always need to search the include files.  Could you imagine how long it would take one person (Jose) to document all those?  It's not really possible.

David

[Jim Dunn]

... low-level COM interfaces are prefixed with an "I" of interface, but isn't mandatory, just convenient. So, in CDO, there is an Automation object called Message and a low-level interface called IMessage. But it happens that in other components there are also objects and interfaces with that common name, so to avoid conflicts, I have added "CDO_" as a prefix.

To complicate matters, nobody looks at the C++ examples, as they should, because they use a weird syntax, but at the VB examples, that use the Automation Message object instead of the IMessage interface.

I know that PowerBASIC isn't used by a large enough population on the planet to demand this, but I would've loved a "PowerBASIC COM Programming" book.  Just sayin'.

[John Montenigro]

David, thanks for your encouragement - much appreciated! Also, your explanation of the $$... I didn't realize that one was a compiler directive and the other a type indicator!  I thought I was looking at a set of begin/end delimiters! Doh!

Jose, Thanks for that explanation!!!! THAT is the kind of information that really helps!!! And yes, I apologize, I have not learned to read the C++ examples, and I do reflexively go to the VB examples that look more familiar. I am more than happy to work with any such explanations and guidance you are able to provide! Thanks!

David (again), you have echoed my process, too, of using a search tool to narrow down the locations that *might* be relevant. The problem is to figure out which are and which aren't! I also examine the "tree" or "chain" of "#INCLUDE"s...

Jim, I agree - it would be great to have a comprehensive explanation of "COM with a PB flavor"... Maybe I should start keeping notes on what I'm learning, although I'm not doing it fast enough to benefit anyone else, I'm sure.

OK, so here's another question that would "open more doors" of understanding:
Jose, you say the example is VB Automation, and I will search over the weekend to read and understand that more.
But for now, my next question would relate to this code line (from that MS example you provided a link to):

Code Select Expand


' Set the sendusing field to 'cdoSendUsingExchange'.
    Config("http://schemas.microsoft.com/cdo/configuration/sendusing") = 3

I'm not asking you to translate it for me, but to tell me where I might learn how to read and understand this, so that I can be able to translate it for myself.

Thanks for all the help! This is indeed a most supportive community!
-John

[John Montenigro]

I just went back to the MS examples that Jose pointed me to at this link:
http://msdn.microsoft.com/en-us/library/aa494235(v=exchg.80).aspx

and I took time to look at the C++ code...

What I mainly noticed is this: that I have NO IDEA how to understand what's going on in the C++ code...

But interestingly, when I went back to the VB code, I realized that I THOUGHT I had some idea of what was going on, because the syntax looks familiar.

But in reality, I also have NO IDEA just from looking at it, what is REALLY going on in that code!

So I have been deluding myself in thinking that I could translate the VB code fairly directly... It would appear that I have to read a LOT more about VB Automation in order to be able to do such a translation.

BUT!!! I would not have known that I need to learn "VB Automation", if Jose had not identified it.

Little by little...I'll get there...eventually!

-John