Prev: VB6 - How-to print Excel spreadsheet from VB?
Next: Creating a DLL and calling it from an app
From: Karl E. Peterson on 26 May 2005 15:46
Hi --

I have an odd set of requirements that got flummoxed by the maximum URL length
limitation. In short:

* VB5 app with no dependencies other than runtime,
* Create an email, ready to send, using default mail client,
* Stuff the body text with 100K or more of diagnostics info,
* Maintain absolute trust/transparency!

I know I could send the email directly from code, but that's not the goal. The
*user* is the one who must press Send, on an email they have full access to edit, in
order to preserve every shred of trust that only information they're willing to
divulge will be sent.

The old standby, ShellExecute a mailto: link, fails because URLs are limited to 2083
characters (ref: Q208427). Other ideas?

Thanks... Karl
--
Working Without a .NET?
http://classicvb.org/petition


From: Casey Provance on 26 May 2005 20:57
Karl -

Are we talking about an email generated by the default email client? Or an
interface that is specific to your application?

- Kev


From: Karl E. Peterson on 26 May 2005 21:12
Hi Casey --

> Are we talking about an email generated by the default email client?
> Or an interface that is specific to your application?

I want to basically replicate the effects of ShellExecute("mailto:..."), but stuff
the body text with reams of data. So, hmmmm, I suppose I'd be causing the default
mail client to generate a mail, and providing it with the data to fill it. (My
current solution is to stuff the clipboard, and just put "[Paste here]" (in essense)
in the email body. Not too elegant, but functional. The point is to ensure the user
feels comfortable with what system information is being sent back to the devteam.

Thanks... Karl
--
Working Without a .NET?
http://classicvb.org/petition


From: Jim Carlock on 26 May 2005 21:12
Winsock?

The URL you are connecting to is an IP address over a SMTP port
number? Grab the UID (email id) from the default mail client, provide
a small dialog for the password, connect to their SMTP server as the
email client does, then send via SMTP?

Based upon the KBID it looks like you've got a webpage using, so
that doesn't quite identify that you're using a mail server to send the
information. I'd be thinking along the lines of using the mail server if
that's possible.

If you're thinking a client-side app, that's where I'd be leaning, is to
use a winsock to connect to their mail server, send the message via
their mail server. Either that or leave a port open on your web-
server awaiting a certain connections, that way you wouldn't have to
use email.

Hope that helps.

--
Jim Carlock
Please post replies to newsgroup.

"Karl E. Peterson" <karl(a)mvps.org> wrote:
Hi --

I have an odd set of requirements that got flummoxed by the maximum URL length
limitation. In short:

* VB5 app with no dependencies other than runtime,
* Create an email, ready to send, using default mail client,
* Stuff the body text with 100K or more of diagnostics info,
* Maintain absolute trust/transparency!

I know I could send the email directly from code, but that's not the goal. The
*user* is the one who must press Send, on an email they have full access to edit, in
order to preserve every shred of trust that only information they're willing to
divulge will be sent.

The old standby, ShellExecute a mailto: link, fails because URLs are limited to 2083
characters (ref: Q208427). Other ideas?

Thanks... Karl
--
Working Without a .NET?
http://classicvb.org/petition



From: Casey Provance on 26 May 2005 21:47
Karl -

Well, you being the VB guru here, I'm not sure how much I could offer....but
I can share with you what I've done in the past.

My apps come with a "system information" tool which when opened shows the
user their system specs (kind of like MS's System Information viewer, only
much simpler and to the point) with additioanl space for input from the user
(standard text box). The user could 1) Open this tool at any time via the
program group or from the app's About box or 2) opt to open the tool when my
error handler trapped an error.

When ready to send, the user would click a "send report" button and the
program would email me the results, all via the winsock API and smpt, as Jim
has suggested. It's all very neat and simple for the user (as I believe it
should be) while my program did all the work in the background. This way I
never had to bother with email programs (considering the vast amount
available, it would be impossible to support them all) and the information
was delivered to me as a support email, at which time I could make a
diagnosis based on what was sent. FWIW, my error handler also logs errors
with as much information as I can gather from the program at the time the
error occured.

I don't know how much this would be useful to you. I'd be happy to share
with you what I have (especially considering all I have learned from your
MVP site) if you so desire.

Cheers

- Kev


 |  Next  |  Last
Pages: 1 2 3 4 5
Prev: VB6 - How-to print Excel spreadsheet from VB?
Next: Creating a DLL and calling it from an app