Missing data (keys and their values) using write key.vi??? (see attached vi)

[GRCK5000]

After clicking "write config" on the front panel, I'm expecting the "write key.vi" to write all the keys and their values. But when I open the text file, I only see two keys as shown below:

My goal is to write all the keys and their values only when I press "write config".

[Frozen]

---

@GRCK5000 wrote:

 But when I open the text file, I only see two keys...

---

That would because of this...

Do you know what a feedback node does? It holds the last value. You most certainly do not what you want in the inner loop.

You should move the "button reading" to its own case and have the "write config" SW part in its own case.

[GRCK5000]

Removing the feedback node is even worse. 

Now, I'm getting only 1 key with one value. 

I don't want to remain in the true state when I press "write config". I want to go back to false. 

No feedback node

By the way, with no feedback node, the boolean (write config) mechanical action is "latch when released".

[JÞB]

---

@GRCK5000 wrote:

Removing the feedback node is even worse. 

Now, I'm getting only 1 key with one value. 

I don't want to remain in the true state when I press "write config". I want to go back to false. 

No feedback node

By the way, with no feedback node, the boolean (write config) mechanical action is "latch when released".

---

Could you please attach the vi?

I am concerned about the third element in your string array constant.  Why does it indicate more info?  Should the elements show display format?  That arrow......

I can't have the only operational 8-Ball!

[altenbach]

Please don't maximize the panels to the screen. Annoying!

• What is the purpose of the inner FOR loop with 10 iterations. If you want the latch action boolean to be true for all 10 (???) iterations, the terminal belongs before the FOR loop.
• The green feedback node make no sense. Get rid if it.
• The entire FOR loop probably belongs into a case structure
• Your string array only has four elements, so four iterations are sufficient.
• If you want to iterate over the four strings, you would autoindex on the string array and eliminate the lower shift register.
• Your state constant don't match the tab control.
• Your "login" button has no label. Bad if you ever try to unbundle by name.. OK button is a poor label for "go to send page"

This entire thing is extremely convoluted and not really scalable.

[altenbach · Accepted solution]

See if this can give you some ideas...

[Martin_Henz]

another little important thing ...

never store passwords in plain text (Passwords should be stores as hashed value). Or: what's the reason for this dialog if everybody knows all usernames and passwords?

[Frozen]

---

@Martin_Henz wrote:

what's the reason for this dialog ...?

---

I assumed this was a proof of concept code. Certainly it would not be used as-is!

[GRCK5000]

Thanks Mr. Altenbach! I corrected my mistakes (see attached VI). I think it works as expected now. 

The only thing I forgot to remove the feedback node. The code should be as shown below:

[altenbach]

---

@GRCK5000 wrote:

only thing I forgot to remove the feedback node. The code should be as shown below:

---

• Yes, that feedback node needs to go, because it causes the case to be true twice (1: when the button is pressed, 2: At the very next iteration when the button is false again.
• That code just "smells". 😄 For example why is writing the configuration on the "sign up page" state while the "write config" page does not really do anything. Convoluted and confusing!
• You might want to keep the refnum and error in a shift register for the FOR loop. If the first iteration errors out the others will too. If the FOR loop can possibly iterate zero times, the reference would become invalid unless it is in a shift register, so that's a good habit to always do it. Same with the error. A zero iteration FOR loop would erase the error unless it is in a shift register.
• 10ms is unreasonably short. How fast can the user possibly interact?
• Appending first/last name belongs before the FOR loop. No need to do it four times (Yes, the compiler will fix it for you, but still....)
• A space constant makes the code more readable than a string with a space character where we cannot really tell what's in it.
• I typically keep Array diagram constants on the toplevel diagram
• You probably want to only write an entry if "password"="confirm password"
• As others have said, storing passwords in cleartext is highly insecure. A soft barrier would be to e.g. only store the md5 of the password, then compare the digest of the entered password.
• It probably makes no sense to store the "confirm password", right? Redundant info if they match and useless invalid  entry if they don't.
• If the state does not change, it is clearer to use the existing state wire instead of yet another diagram constant. Only use a constant if the state should change.
• Keep the logical "trains" horizontal. No need to zigzag the error, refnum, state, etc. wires.
• Showing the labels of well-known functions just clutters the diagram. You can use teh context help if you forget what they are.