The sample program attached here ... doesn't shows Senders' name, Subject
and Text with 1.82.294 but works abs perfect when I compile the same with
1.80.

Mind it, it receives HTML mails, perfectly allrite, but with Plain/Text
mail, it just shows as EMPTY.

Any PFL/workaround ? I need it urgent as we have moved our productions to
1.82 long ago...

Anand

The program file attached herewith...

Anand Gupta wrote:

> The sample program attached here ...

I'm afraid I can't locate any attachement...

regards
Thomas Braun

web: www.software-braun.de / email: nospam@wegasoft.de
If you need to send email, substitute "nospam" with my initials
since the spam account is not checked on a regular basis.
Xbase++ FAQ : http://faq.xbasecentral.net

I realised after I came back to see the NG. Looks like, you checked the NG
almost then only. Anyway have posted a followup mail with the attachment a
little while ago only...

Thanks

Anand

"Thomas Braun" <nospam@wegasoft.de> wrote in message
news:3fc35077$1@asgcom.alaska-software.com...
> Anand Gupta wrote:
>
> > The sample program attached here ...
>
> I'm afraid I can't locate any attachement...
>
> regards
> Thomas Braun
> --
> web: www.software-braun.de / email: nospam@wegasoft.de
> If you need to send email, substitute "nospam" with my initials
> since the spam account is not checked on a regular basis.
> Xbase++ FAQ : http://faq.xbasecentral.net

Anand Gupta wrote:

> Looks like, you checked the NG
> almost then only.

 I have a local news server (called Hamster) that pulls various usenet
groups every 120 minutes, so I think this was a big coincidence.

regards
Thomas Braun

web: www.software-braun.de / email: nospam@wegasoft.de
If you need to send email, substitute "nospam" with my initials
since the spam account is not checked on a regular basis.
Xbase++ FAQ : http://faq.xbasecentral.net

Anand,

>The sample program attached here ... doesn't shows Senders' name, Subject
>and Text with 1.82.294 but works abs perfect when I compile the same with
>1.80.

>Mind it, it receives HTML mails, perfectly allrite, but with Plain/Text
>mail, it just shows as EMPTY.

Your posted test program should never show any Content, just the "From:" and 
"Subject:" headers. I do not have any problems to retrieve any kind of email 
message, including all headers and all contents, from either of my email
servers using ASINET. I also use Xbase++ 1.82.294.

Maybe it is your email server that does not work right? Or you used different 
code than you actually posted, which might have an error of some sort?

-- Andreas

---                                                                       ---
  Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
  415 Gute Street                     or: Andreas@DDPSoftware.com
  Owosso, MI 48867-4410               or: Andreas@Aerospace-History.net
  Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
---                                                                       ---

I really hate to do this, but I have to follow up on my own response again!

I wrote (somewhat prematurely):
>I do not have any problems to retrieve any kind of email message, including
>all headers and all contents, from either of my email servers using ASINET.

This is actually not quite true. I tested this some more with various emails 
that I received from different sources -- including emails sent with ASINET, 
a bunch of spam emails that I continuously receive, and some NASA listserv 
emails -- some with and some without attachments. In most cases, all content 
is returned as expected. But in some (very specific) cases the text content 
is not included, even though it is retrieved from the server!

In several cases (all were NASA listserv emails), the email had only "text" 
as Content-Type and no Content-Transfer-Encoding specified. I can read those 
emails just fine with any email program (that I tried), but ASINET's
"oMimeContent:GetMessage()" returns an empty string. After manually changing 
the Content-Type to "text/plain", "text/xxx" or even just "text/" on that 
email server, ASINET can "see" the text body, too.

In another case the email was sent via ASINET and had a text as message body 
and a ("printed-quotable" encoded) file attached to it. The email's general 
Content-Type was set to "multipart/mixed" (as expected). The text content 
(first part) had neither any Content-Type nor any Content-Transfer-Encoding 
specified, which is probably caused by an ASINET error (see PDR 109-5315).
ASINET's POP3Client() actually reported the Content-Type as "text/plain", as 
it should, if there is no specific Content-Type set, but the body was empty.

The second part of that email had as Content-Type "application/octet-stream" 
and the correct (or better "the expected") Content-Transfer-Encoding of 
"quoted-printable". This second part is visible to ASINET, even though the 
extracted message content is slightly corrupted -- but this is caused by the 
(previous) incorrect "quoted-printable" encoding of ASINET itself. My email 
reader(s) can handle this email also just fine, and I can see the text part 
as well as the attached file, even though the attached file is even more 
corrupted using a working "quoted-printable" decoding routine. I have not 
yet received a PDR for this "quoted-printable" encoding/decoding problem, 
but I still hope that I will get one soon.

Other emails, that were also created by ASINET and also had some file
attachments (for example two "base64" encoded files), do not show the same
problem, and the text body is later seen by ASINET's POP3Client() just fine! 
So, this is not a consistent problem, and I don't know exactly why it 
sometimes works (or why it sometimes fails!)

It appears that ASINET can't handle "incomplete" Content-Type descriptors
(like simply "text" without a following "/") and sometimes has also problems 
if no Content-Type is specified at all. This problem should definitely 
receive a PDR, and if nobody from ASTAG reads or responds to this thread 
here, I will send Gogo another email. 

There is actually a workaround for PDR 109-5315, which I use:
I attach the text body of the message first, using oMimeMessage:SetContent(), 
and after that, I attach all the files. This usually works ok, but because 
the message body text does not have a separate Content-Type (afterwards), 
ASINET might not see the body anymore, when retrieving such a message (at 
least sometimes).

There is also a strange workaround for this problem:
If you including a "fake" header like:
	"Content-Type: text/plain" + CRLF + CRLF
in front of your actual email text message, using oMimeMessage:SetContent(), 
all "normal" email readers will still be able to see both, the text message 
body (including the "fake" Content-Type line, which is not good, of course) 
as well as the attachments, while ASINET will be able to see the text message 
body (without the "fake" Content-Type line!!!), as well as the attachments.

Of course, if ASINET would work correctly in other aspects, then adding this 
"fake" Content-Type line should not work at all. The very fact that this 
workaround works for ASINET hints at another problem with not yet discovered 
side effects.

If ASTAG would either give out the code for ASINET, or open up the ASINET 
classes for sub-classing, with programmer-access to the internals, like the 
sockets used (to fix FTP), the raw-data of the email message (to fix 
MimeMessage-related problems) -- and of course documented it all -- we could 
use our own methods to retrieve a directory listing from FTP, or send an 
arbitrary FTP command, or we could use our own "ToCP()" and "FromCP()" 
functions to include or extract attachments, or we could scan the raw message 
for any inconsistencies, etc.

Unless ASINET is opened up like this, we will continue to run after ASTAG 
for every little problem or minor enhancement request, because we can't fix 
anything ourselves.

-- Andreas [just a little bit grumpy]

---                                                                       ---
  Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
  415 Gute Street                     or: Andreas@DDPSoftware.com
  Owosso, MI 48867-4410               or: Andreas@Aerospace-History.net
  Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
---                                                                       ---

Hi Andreas

Thanks for the detailed various possiblities. I checked further, even when I
generate Plain/Text mail from my Outlook Express 6, it doesnt' show up. Will
try little further later in the evening or so and get back.

Anand

NB: The mails, which I need to currently 'fetch' are being generated from
our FlagShip driven site. I will see if I can ask the FlagShip guy to tweak
with WebSendMail() function and add the necessary Contet/type strings..


"Andreas Gehrs-Pahl" <Andreas@DDPSoftware.com> wrote in message
news:3fc3f928$1@asgcom.alaska-software.com...
> I really hate to do this, but I have to follow up on my own response
again!
>
> I wrote (somewhat prematurely):
> >I do not have any problems to retrieve any kind of email message,
including
> >all headers and all contents, from either of my email servers using
ASINET.
>
<snip>

Andreas,

> Unless ASINET is opened up like this, we will continue to run after ASTAG 
> for every little problem or minor enhancement request, because we can't fix 
> anything ourselves.

The format of a message is quite simple (RFC822), so it should be very easy
to write a class heirarchy to emulate Alaska's structure.  You can then use
the functions in ASINET to encode/decode etc.

Regards,

Phil Ide

***************************************
* Xbase++ FAQ, Libraries and Sources: *
* goto: http://www.idep.org.uk/xbase  *
***************************************

How do they get teflon to stick to the pans?

Phil,

>>Unless ASINET is opened up like this, we will continue to run after ASTAG 
>>for every little problem or minor enhancement request, because we can't fix 
>>anything ourselves.

>The format of a message is quite simple (RFC822), so it should be very easy
>to write a class heirarchy to emulate Alaska's structure. You can then use
>the functions in ASINET to encode/decode etc.

The problem is that we need to use ASINET's classes/objects and their 
internal iVars and methods -- most of which are undocumented and hidden --
unless we want to rewrite the complete functionality of them from scratch.

For FTP we already switched to Marshall Soft's FCE4XB, because ASINET does
not have the minimum required functionality and does not expose any of its 
internals, so we can't add to it or change it. I don't want to do the same
for email, and buy SEE4XB, too. Even though it is dirt-cheap ($105) compared 
with the amount of time and effort it would take to write this from scratch, 
using ASINET's sockets. And I would hate to do this, because we got the
Professional Subscription mostly because of ASINET, but I have not been able 
to utilize it enough to make it worth that kind of money, especially because 
we have (to use) much more flexible and cheaper add-ons like FCE4XB and 
XB2NET anyway, which would make ASINET completely redundant, if we now also 
need to buy SEE4XB.

I wouldn't even mind fixing Alaska's code or post working or enhanced 
replacement functions, classes, or methods, but I don't have the time to
write everything from scratch. I agree with you, that the RFC(s) for email 
are relatively simply and straight forward, so I don't know or understand 
why Alaska wants to keep all of this so "secret" or "proprietary", and does 
not document the classes beyond the absolute minimum, while keeping a lot
of the internals a "black box".

As a programmer, I do not want my development tool to baby-sit me and keep 
all the nitty-gritty details secret from me. I like the development tool to 
make my job easier, so I can use existing functionality in a simple and
efficient way. But if there are any problems or special requirements, I want 
to have full access to all the internals and want to be able to change the 
behavior and functionality any way I want, especially if it is something 
that the original developer (ASTAG) didn't think anyone would want to do or 
should do, or when the original implementation is wrong or incomplete.

If all the existing iVars, Methods, and Functions of the ASINET library
would be documented and made EXPORTED or at most PROTECTED, than it would
be possible to enhance, modify, fix and actually use all the classes of 
ASINET. The way it is now, ASINET is very, very limited in its usability,
and if I were the programmer of ASINET, I would hate the thought that all
my work and effort that I put into developing it is basically wasted, 
because very few people can use it, due to some relatively minor issues,
most of which could be fixed by the developers themselves. If it is 
virtually impossible to sub-class anything of ASINET, due to a lack of
information or documentation, then what is the purpose of using classes in
the first place?

If ASINET (and this probably applys to most of ASTAG's add-ons) were opened 
up like this, I bet that many more would use it, and that would be good for 
all of us, including ASTAG!

If I misunderstood you, and you know of an easy way to fix, replace, or add 
broken or missing functionality of any of the ASINET classes, then please 
tell me about it, and I will publicly worship you as an Xbase++ semi-god. 

-- Andreas [no, I am not from down under]

---                                                                       ---
  Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
  415 Gute Street                     or: Andreas@DDPSoftware.com
  Owosso, MI 48867-4410               or: Andreas@Aerospace-History.net
  Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
---                                                                       ---

Andreas,

> For FTP we already switched to Marshall Soft's FCE4XB, because ASINET does
> not have the minimum required functionality and does not expose any of its 
> internals, so we can't add to it or change it.

You could alsouse my XbFTP library, which is free and comes with complete
source code.

> I wouldn't even mind fixing Alaska's code or post working or enhanced 
> replacement functions, classes, or methods, but I don't have the time to
> write everything from scratch.

Ack.

> As a programmer, I do not want my development tool to baby-sit me and keep 
> all the nitty-gritty details secret from me. I like the development tool to 
> make my job easier, so I can use existing functionality in a simple and
> efficient way. But if there are any problems or special requirements, I want 
> to have full access to all the internals and want to be able to change the 
> behavior and functionality any way I want, especially if it is something 
> that the original developer (ASTAG) didn't think anyone would want to do or 
> should do, or when the original implementation is wrong or incomplete.

Ack.

> If all the existing iVars, Methods, and Functions of the ASINET library
> would be documented and made EXPORTED or at most PROTECTED, than it would
> be possible to enhance, modify, fix and actually use all the classes of 
> ASINET. The way it is now, ASINET is very, very limited in its usability,
> and if I were the programmer of ASINET, I would hate the thought that all
> my work and effort that I put into developing it is basically wasted, 
> because very few people can use it, due to some relatively minor issues,
> most of which could be fixed by the developers themselves. If it is 
> virtually impossible to sub-class anything of ASINET, due to a lack of
> information or documentation, then what is the purpose of using classes in
> the first place?

Ack! Ack!

> If ASINET (and this probably applys to most of ASTAG's add-ons) were opened 
> up like this, I bet that many more would use it, and that would be good for 
> all of us, including ASTAG!

Ack! Ack! Ack!

> If I misunderstood you, and you know of an easy way to fix, replace, or add 
> broken or missing functionality of any of the ASINET classes, then please 
> tell me about it, and I will publicly worship you as an Xbase++ semi-god. 

I don't know of an easy way to fix it, partly because the documentation is
not rich enough, partly because the library is - as you say - a black box,
and partly because I haven't looked.

However, I have a function which I use regularly which accepts an object
and then traverses the inheritance chain writing the iVars to disk with any
other info it can glean about them.  It also lists the methods.

Knowing which iVars/methods exist in which object is often useful for
debugging or hacking (e.g. examining oContext class will reveal the class
which handles communication between WAA1SRV and waa1gate).

I'll grab a dump of a mailmessage and see if it reveals anything
interesting.

Regards,

Phil Ide

***************************************
* Xbase++ FAQ, Libraries and Sources: *
* goto: http://www.idep.org.uk/xbase  *
***************************************

Windows? HA! C:\WINDOWS. DELETE *.* AH! Thats Better <g>

Andreas,

> I'll grab a dump of a mailmessage and see if it reveals anything
> interesting.

I've attached MimeMessage.chx, which is a plain-text dump of a message
retrieved from my pop3 mailbox (and was originally created and sent by an
ASINET SMTPClient() construct).

I'm not sure whether this helps or not, but it shows the methods and the
heirarchy.  Note that this doesn't walk through member vars, because there
aren't (apparently) any visible.

Regards,

Phil Ide

***************************************
* Xbase++ FAQ, Libraries and Sources: *
* goto: http://www.idep.org.uk/xbase  *
***************************************

KINGDOM.ZIP!! More than a game, it's an adventure!