Do-more Email questions

[Tdub]

1. In the SMTP Client device configuration, is there any way to implement a ‘friendly name’ in the ‘From’ Email Address field?   Example -  From: Sleepy Joe [s.joe@mycompany.com]

2. How can one specify a ‘From’ email address on the fly, rather than having to hard code it into the SMTP Client device?  Can it be exposed via DEVWRITE, or can the SMTP Client device be made to reference a String structure?

3. With the DEVREAD and DEVWRITE instructions, the available device registers seem to be commingled between @IntSerial and those of a user-created SMTP Client.  Is this intentional? What am I not understanding about the relationship between the two?

Thanks!

[BobO]

Great questions!

1. Sorry, no.

2. Not at this point, primarily because DEVREAD and DEVWRITE are set up for single register access only. It might be possible to work out something on this though, so we will take a look. We are planning a maintenance release pretty soon. If we were able to work it out, it would be a string variable, not a hard coded string.

3. DEVREAD and DEVWRITE are low level register accessors...a back door to the driver. Because the driver reference can be an indirect reference, rather than a hard definition, there are cases where we don't what the specific driver is until runtime. To that end we made the list of properties global, then depending on whether you do a hard reference or indirect reference, we can tell you at programming time whether a particular register number is valid for the device or not.

[Tdub]

Thanks, Bob.

1. It doesn't seem like it should be a huge technical challenge to implement, but it’s certainly not a show stopper for me.  It’s just a nice feature that the ECOM100 offers, so I use it there.

2. This is a bit of a concern for me.  The problem is, if a write a program for a customer or end user, there’s no way the ‘From’ can ever be changed without a new program.  I would like for them to be able to configure their unique setup, without having to rely on the programmer (me) to make changes when necessary.  With the ECOM100, at least the user can access it via the web interface.  IMHO, the most straight forward approach would be to simply include the ‘From’ information in the Send Email instruction, just as the To, Cc, and Bcc are.  The info could then be populated on the fly.

3. I was just curious – Thank you for the look under the hood. 

Thanks again.

[BobO]

Hmmm...ECOM100 does it? Well, can't let that happen. I'll take a look at that too.

As for point #2, we're going to add it. It is of manageable complexity, and we will probably do all of the authentication parms as well.

[Tdub]

Great news, Bob.   Thanks a million!

I really liked the DL line of processors (and DirectSoft).  Having done tons of projects with them over the years, I developed my “standard way” of doing things that I eventually never even thought much about anymore.  When Do-more came along, I began to realize just how many tricks, workarounds, and hand-rolled solutions I was having to implement previously.  Not to bash the older devices – they’re still great.  I’m just really appreciating the expanded capabilities and ‘slicker’ way of doing things with Do-more.  What an awesome product!  It's already so shiny that I need sunglasses, but thanks for continuing to polish it. 

[BobO]

Great news, Bob.   Thanks a million!

I really liked the DL line of processors (and DirectSoft).  Having done tons of projects with them over the years, I developed my “standard way” of doing things that I eventually never even thought much about anymore.  When Do-more came along, I began to realize just how many tricks, workarounds, and hand-rolled solutions I was having to implement previously.  Not to bash the older devices – they’re still great.  I’m just really appreciating the expanded capabilities and ‘slicker’ way of doing things with Do-more.  What an awesome product!  It's already so shiny that I need sunglasses, but thanks for continuing to polish it. 

You're welcome! We consider it an honor that people use our products, and when they make good requests with strong justifications, we're like Pit Bulls on pork chops. You should see what happens when you tell us something isn't possible. Sometimes it isn't as easy as this has proven to be, but even when we are forced to say 'no', we want to hear the requests and we definitely consider them. Turns out that this wasn't that hard, does address a point of need, and is an improvement that might open the door to more in the future. Wins on many levels. Look for these improvements in 1.2.2...still a few weeks out, but shouldn't be too long.

[Controls Guy]

Having done tons of projects with them over the years, I developed my “standard way” of doing things that I eventually never even thought much about anymore.  When Do-more came along, I began to realize just how many tricks, workarounds, and hand-rolled solutions I was having to implement previously.  Not to bash the older devices – they’re still great.  I’m just really appreciating the expanded capabilities and ‘slicker’ way of doing things with Do-more.  What an awesome product!  It's already so shiny that I need sunglasses, but thanks for continuing to polish it.  

I could have written that myself!  Doing my first major work on DLx (major additions to a 2010 project) after a couple Do-More projects, and the difference is amazing, especially dealing with strings, the pointer arithmetic you have to do, etc.  I'm suffering Koyo shock.  Well, I can just....no.  But, you can just....uh, no.   So yeah, it's making me more of a Do-More fan than ever.