Custom FormatString and GraphInteractionModes.EditRange

[jsytniak]

Hello -

I have provided a sample application (extended from the sample used in this thread). The sample now runs in two modes (Offset/Duration) based on the toolbar button.

I have noticed two problems with the GraphInteractionModes.EditRange functionality... 

1. click to edit the X axis range when in Offset mode and note that the format changes... I would expect it to stay as the xaxis is formatted
2. switch to Duration mode and edit the xaxis range... appears to show the underlying double value.... again I would expect it to stay as the xaxis is formatted

I realize that I am extending functionlity a bit here but these behaviors would seem to be bugs.

Thanks.

Joe

Message Edited by jsytniak on 03-23-2009 05:20 PM

Message Edited by jsytniak on 03-23-2009 05:20 PM

[Eric_B.]

Hi Joe,

I know this may seem like a bug, but it is actually expected behavior.  When you change the LabelFormat of an axis, you are only changing the display format, not the format of the value when you are editing it.  I agree that this would be a good thing to have.  If you would like to see this changed in a later version of Measurement Studio, you can file a product suggestion at the Product Suggestion Center.

[jsytniak]

Eric -

I guess I may have been a little rash in calling them possible bugs. It just did not line up with my expectations. I can see where your current behavior would be by design.

I would like to request this enhancement. For the datetime formats this would seem to be straightforward. But for my TimeSpan based display, I am not so sure. It almost seems like there would need to be an additional value added to the FormatStringMode enum for TimeSpan and possible changes to the Format string class for default behaviors for this enum value. Your thoughts?

I'll handle the enhancement request later.... My first priority is to get something working in my own app.....

So is there anything I can do to alter this behavior in the current version. I do not see any event overrides for when the edit mode occurs on the axis end values.... am I missing something?

Thanks.

Joe

[Eric_B.]

Joe,

 It looks like there is actually a way to set the format of the edit-time value of that scale.  The code would be:

waveformGraph1.XAxes[0].EditRangeNumericFormatMode = new MyFormatMode();

where MyFormatMode is a class that inherits from NumericFormatMode.  In MyFormatMode, you can override FormatValue (which changes the format of the number as it is displayed in edit-time) and TryParse (which converts from the inputted value to the underlying value).  I've attached an example that shows range editing in action.

[jsytniak · Accepted solution]

Eric -

Yes your example was very helpful. I had a TimeSpan based version of it working very quickly.

Thanks much for following up.

Joe

BTW - I did submit a Product Suggestion for this and I refer to this thread in the suggestion. So you may want to follow up as the functionality I asked for is already available. Thanks again.

[jsytniak]

Eric -

There is one other thing I forgot to ask about on this one.

I am using WaveFormGraph objects on a form that does not have an AcceptButton specified. As a result, whenever the enter key is pressed after editing the end label on an axis I get the irritating system beep sound. On most other controls one needs only to do something like this...

 private void tscboTimeFormat_KeyPress(object sender, KeyPressEventArgs e)

{

    // Form has no AcceptButton - prevent default beep on hitting enter

     if (e.KeyChar == 13)

    {

        e.Handled = true;

    }

}

I tried doing this with a WaveFormGraph KeyPress event handler... no joy. I think the control with focus is a textbox provided by the WaveFormGraph. I've looked for an event to try to emulate the code above... again no joy. Can you point me in the right direction?

Thanks again.

Joe

[Eric_B.]

Hi Joe,

I've tried getting around this with the WaveformGraph, but to no avail.  I believe the problem lies in the fact that your workaround requires access to a KeyPress event handler, and there is not an (exposed) event when you press enter in that edit window.  I can file a product suggestion on this after I verify with R&D that there is no way currently to handle that KeyPress event to avoid the system beep.

[jsytniak]

Eric -

Thanks for looking into this.

My workaround is only for the situation where the form does not have a defined AcceptButton. I find that I still get the system beep even when an AcceptButton is defined. And I would find it hard to believe this is by design, and also an obscure thing that might not get caught in testing. However, I would consider this a bug rather than an enhancement. This is a benign symptom... certainly not a show stopper... but one that can be terribly annoying.

Thanks

Joe

[Eric_B.]

Joe,

I agree with you that this is not expected behavior...so I've filed a bug report on this so our developers will look into it and see if there is anything to be done to fix it for future versions of Measurement Studio.  The reference number is 158863.  All releases of Measurement Studio have a list of the bugs fixed in the readme with their bug report numbers listed, so you can check the next release to see if this issue has been addressed.  You can also call in, if you have service, and ask the Applications Engineer to check the status of the bug report if you'd like to get an update.