Custom dialogs with LARGE text.

[Viper]

LabVIEW 2010

Since the regular dialog vi's use standard text and I need large txt I have generated  my own. I link errors chains so that I can bypass the dialogs on error (sort of). However since they are called but not run they flash briefly on the screen. In order to solve this problem I have used wrapper vis for each dialog that do the error handeling complete with unitialized shift registers to remember the last item entered.

Requirements.

1. Prompt user for info in large text.

2. Variable prompting text.

3. Remember prior entry (per instance)

4. Handle error to bypass dialog with error in.

5. Error trap "cancle" selection

6. Key focus on the entry control

7. Multiple instances so that when I prompt for serial number it doesn't remember the Part Number that I just prompted for.

This last part is the tricky part. Where to I put the reentrant execution. Do I put it for the wrapper or for the dialog? Maybe there is a alternate that I'm missing that makes this easy.

Norm

[GoCougs]

I don't see in the VI you included where you have tried to implement any of this. Please attach what you have tried to accomplish this and explain exactly what you are trying to do and what you are seeing. I understand that these requirements are what you want to see, but please attach the work you have already attempted and we can look into it.

[Viper]

Scott, thanks for the reply:

Attached is a llb with a top app and sub-vis. Running the app will prompt the user for  a part number and then a serial number. It also has all of the above properties except for it only remembers the last entry. I made the wrapper re-entrant with pre allocated clones. But when you run it the second dialog call always has the last entered string. Which vi should be reentrant so that P/N remembers the last P/N and S/N remembres the last S/N?

Thanks

[Michael_78]

Hi Viper,

You need to make both VI's reentrant for this to work, but it is not really necessary to do all this.  Have a look at this example I have done for you.  You need to add extra functionality, but I have given you a framework that will retain the values. You will not need the wrappers with this dialogue.

If you need any more help just ask,

Michael.

[GoCougs]

Viper,

You don't need to have the wrapper, but what you do need is to set the VI to reentrant for it to work. You can do this be going to File->VI Properties. The screen shot below shows the options you should select.

By making the VI reentrant and preallocating the clone, you are able to have exactly what you need. Let me know if you have any other questions.

[Viper]

Scott,

The purpose of the wrapper is to keep the dialog from opening if there is an error upstream of the dialog call. Without a wrapper if there is an error before the dialog call and the error is detected by the dialog vi it will open and self close that will cause a disctracting flash on the screen. The wrapper cleans this up. Is there another way to handle this?

Norm

[Viper]

Indeed making both reentrant makes it work. Your example does indeed make it more simple but I wanted it to be arbitrary (in the number of uses)  for the prompt so that it could work on any number of inputs that I need to get from the operator. I didn't want to have to add specifically for each case.

Thanks for your solution.

Norm

[Michael_78 · Accepted solution]

HI Viper,

Yes there is.  It is good practice to set up a dialogue before it is displayed.  To do this, un-check 'display front panel when called' in VI properties so the dialogue will not be shown initially.  Then, use the property node FP.Open in your dialogue VI after you check for errors.  It would also be good to populate the old data before showing the VI.  I use this tecnique to re draw dialogues before they are displayed (show/hide controls etc.)

Michael.

[Viper]

Michael, Now that I have used the FP.open I have lost the key focus. How do I get it back?

Norm

[Viper]

Nevermind. I forgot to break the error chain and the FP.open and keyfocus were on chance hapening in the wrong order. Fixed