Override text in indicator or text box

[MarkGreally]

Hi Folks.

Is there a way to override the text in an indicator. I want the user to be able to manually change the values (if necessary) displayed in the box before it gets saved. Is this possible or is there there a better way to manually override the data.

Thanks,

Mark.

[Taki1999]

The use case sounds a bit weird to me. One approach would be to make your text indicator a control and keep it disabled most of the time and only enable it when the user indicates that they want to do a manual override. The downside is that you'd have to do your non-user updates using a local variable.

[MarkGreally]

Got it sorted. I used a property value and two variables and works a treat. Its a little bit long winded, I would have thought one could override a text box after calculation via its property settings. The majority of applications everywhere allow this.

[Taki1999]

Are you actually using an Event Structure? If not, your property node is not necessary and you're taking a performance hit to do a no op.

Writing a local variable to a Value Property node is not something you want to do unless you want to force an Event.

[MarkGreally]

It is a state within a state machine which is triggered by a button press event. It also repeats the process for different text sources. Its actually OCR device numbers, sometimes the characters may not be perfectly read so I give this as an option for the user to correct.

The method seems to work ok now. Do you forsee any problems with it or is there a more efficient way to do it?

[Taki1999]

If you have an Event for text<ValueChanged> then your approach is ok.

I'm a bit suspicious of your state machine setup since there really should never be a need to write a local variable to a property node for the same except to trigger an event.

(i.e. I don't think you need the local variable write to property node at all. I think your file read should write to a local variable and shift register and you should have your text control terminal in your Event Structure for text<ValueChanged>.)

Are you using shift registers in your state machine? If so, I would keep the OCR data in a shift register and allow the user to update the shift register data via a control.

Also, if you expect the OCR to be successful most of the time, I'd keep the text control disabled to prevent accidental alteration of data.

EDIT: Attached an example of how I think this should be done.

[MarkGreally]

I have taken your comments on board but I do feel like its creating more work when the simpler method seems to work fine. I have attached my project if you fancy having a look. The OCR values save to the spreadsheet as normal and when I manually overide the text box and save the data they are written to the spreadsheet fine. I dont feel I should complicate things by adding shift registers.

Adding an extra button is not ideal but I may add a user warning if they enter text.

[MarkGreally]

I have taken your comments on board but I do feel like its creating more work when the simpler method seems to work fine. I have attached my project if you fancy having a look. The OCR values save to the spreadsheet as normal and when I manually overide the text box and save the data they are written to the spreadsheet fine. I dont feel I should complicate things by adding shift registers.

Adding an extra button is not ideal but I may add a user warning if they enter text.

[Taki1999]

Fair enough. 

I'm taking a peek at your code and we may just have philosophical differences related to how test systems should be done where we should agree to disagree.

Since you did post it, I will throw in my 2c though.

- I think your front panel is way too busy.

- Your block diagram doesn't fit on my monitor which is a no-no for me.

- You are over-using property nodes which will cause you perfomance hits in the long run (Shift registers will save you here, Local Variables would be an incremental improvement)

- I would seriously consider looking into a pre-built state machine such as the JKI

- Your number to string ramp prior to entering your loop could be replaced with a string constant (negligible improvement)

- Your sequence structures are largely unnecessary. Error cluster wiring will control your flow.

- Your Config File setup seems like something you're going to want to do in an array. Currently, you have off-screen indicators which you might consider replacing with shift registers.

- Stacked Sequences hide code and I avoid them if at all possible.

- Clusters and Arrays would go a long ways towards making your front panel organized and scalable.

- You can safely delete your local variable write to property nodes of the same. (Please do this if even if you don't agree with any of the other pieces)

I know you didn't ask for a code critique. I'm somewhat familiar with this device and think your testing of it could be improved with a little more time spent on state machine architectures and appropriate use of shift registers.

If you rearchitect now, it's a good sized piece of work. If you don't rearchitect it now, the task gets much larger the longer you wait. I think you're already finding that it's difficult to maintain in it's current state.

Again, just my 2c.

[MarkGreally]

Thanks for your comments. Its always nice to get someone elses thoughts. I am the only person in my office who does labview and I must confess I have picked up a few bad habbits.

- I think your front panel is way too busy.

 This is not the final UI, just to get things up and running. It will deffinately be altered later on to make more user friendly.

- Your block diagram doesn't fit on my monitor which is a no-no for me.

I have a fairly big monitor but I agree it is way to big.

- You are over-using property nodes which will cause you perfomance hits in the long run (Shift registers will save you here, Local Variables would be an incremental improvement)

Are you refering to the reinit to default properties?

- I would seriously consider looking into a pre-built state machine such as the JKI

I may look into this.

- Your number to string ramp prior to entering your loop could be replaced with a string constant (negligible improvement)

That keeps changing so a formula is quicker.

- Your sequence structures are largely unnecessary. Error cluster wiring will control your flow.

Could you elaborate on this

- Your Config File setup seems like something you're going to want to do in an array. Currently, you have off-screen indicators which you might consider replacing with shift registers.

Never thought of using arrays here but will look into it. Off screen indicators are for debugging.

- Stacked Sequences hide code and I avoid them if at all possible.

These really only have repeated code behind them so I am not too concerned

- Clusters and Arrays would go a long ways towards making your front panel organized and scalable.

Deffinately something I will address

- You can safely delete your local variable write to property nodes of the same. (Please do this if even if you don't agree with any of the other pieces)

Do you mean write a variable to another variable.

Im also curious as to how you are familiar with this device, its still in development.