STRPRINT or EMAIL formatting oddly

[Controls Guy]

During the previous conversation about emailing, I believe I said somewhere that DEVWRITE didn't seem to be working for me.  I based that belief on the fact that if I opened the device configuration from DMD, the values in the dialog were not updated.

Now I'm back to this task (commissioning the email functions) and decided to confirm my earlier observation, but using DEVREAD.  All the parameters that I've verified using DEVREAD DID in fact write as expected, so the dialog is showing not current values, but values that (presumably) were buffered somewhere the last time the dialog was used to edit them.

It's not life-threatening, but it seems to me it would be both more helpful and more correct if the dialog refreshed with current values when opened, regardless of whether the values were manually entered or the result of a DEVWRITE, if it's an easy change.

Thanks!

[Controls Guy]

Or....is there any way to view device parameters in a data view?  I haven't found any way to do so.

That might be a nice short-term workaround and/or supplementary fix to having the dialog refresh every time.

[BobO]

During the previous conversation about emailing, I believe I said somewhere that DEVWRITE didn't seem to be working for me.  I based that belief on the fact that if I opened the device configuration from DMD, the values in the dialog were not updated.

Now I'm back to this task (commissioning the email functions) and decided to confirm my earlier observation, but using DEVREAD.  All the parameters that I've verified using DEVREAD DID in fact write as expected, so the dialog is showing not current values, but values that (presumably) were buffered somewhere the last time the dialog was used to edit them.

It's not life-threatening, but it seems to me it would be both more helpful and more correct if the dialog refreshed with current values when opened, regardless of whether the values were manually entered or the result of a DEVWRITE, if it's an easy change.

Thanks!

It isn't an easy or feasible change. The system configuration isn't changed from DEVWRITE, only the current state of those same settings in the runtime driver. Y'all have said repeatedly that you wanted program control of configurations and this was the manageable answer for doing so. Pushing that information back into the FLASH-based SysConfig simply isn't viable.

Having an extended device view that would read current settings out of the driver is do-able, but there are at least 15 things you want sooner.

[Controls Guy]

If it's not feasible to change that behavior, that's fine.  It's more important that the parameters be writable at runtime, as you noted.  I'll just try to remember not to configure a device using the dialog on a project where it needs to be written dynamically, so I don't get confused if I happen to open the dialog.

Thanks!

[BobO]

If it's not feasible to change that behavior, that's fine.  It's more important that the parameters be writable at runtime, as you noted.  I'll just try to remember not to configure a device using the dialog on a project where it needs to be written dynamically, so I don't get confused if I happen to open the dialog.

Thanks!

We don't really know the difference between an important runtime changes and not, which means we would have to write them all. So every time you looked up the current IP address of the Google SMPT server, we'd be pushing that back to flash. Running flat out, the flash would be constantly erased and rewritten...and might die in a month.

[Controls Guy]

How about just writing back to flash when someone opens the device config dialog?  Or giving the user the choice in the dialog which version to look at?

That would prevent wear on the flash as well as the slowdown from writing to it all the time.

[BobO]

It does write to flash when you download a new SysConfig, which is the result of editing the device config.


Lest you think I am being hard to get along with, please let me elaborate a bit. The SysConfig is a complex document containing lots of critical stuff, serving lots of subsystems in the controller. Think of it as a big ZIP file containing the Laws of Physics. When the system starts up, the various subsystems read their part of that file and initialize themselves to whatever was specified by the user. Writing that file is a Big Deal that only happens in program mode. Modifying that file at runtime is the stuff of nightmares...like changing the Speed of Light. Bad.

At startup, the SMTP Client Device Configuration provides the SMTP Client all of the nice stuff you specified. DEVREAD and DEVWRITE give you runtime access to the state of the driver, but do not access or modify the config. Modifying driver values at runtime is easy and safe. Modifying the SysConfig at runtime is Very Bad.

In short, it isn't happening. I am an old engineer. Part of my ability comes as an experience base that tells me when to *not* do something. This falls in that category.

I am well aware of how this way of handling the issue seems counterintuitive from a user's perspective. We really do see that and care about that...but...in the case, it is architecturally a bad plan that can screw many things up. My rule is simple: I'd rather apologize to 20% for what I chose not to do, than to apologize to 100% for what I did poorly. Please consider this an apology.

[Controls Guy]

I think in your previous explanation of why this is a bad idea, you didn't go into too much detail, so I thought the barriers stated were the only ones, and when a way around that occurred to me, I posted it.  I can see now in more detail why you don't want to do it.  Thanks!

No apology required.