Γειά σας,

Προσπαθώ εδώ και μια μέρα να θέσω σε μια ολόκληρη εφαρμογη την τελεία στο keypad να βγάζει δεκαδικό κόμμα. Χρειάζεται γιατί δεν διευκολύνει στην καταχώρηση κάθε φορά να πατάς το κόμμα για να έχεις δεκαδικό και όχι την τελεία. Έχουν βρεθεί και έχουν γραφτεί πολλές λύσεις. Να σας πω μια που δεν θεωρώ σαν λύση αλλά workaround.

παρακολουθούμε το keydown event στο control (textbox για την ακρίβεια) και δουλεύουμε αυτόν τον κώδικα

If e.KeyCode = Keys.Decimal Then

      e.SuppressKeyPress = True

      textbox.AppendText(",")

End If

Η λύση βρίσκεται στο System.Threading.Thread.CurrentThread.CurrentCulture.NumberFormat.NumberDecimalSeparator που στην culture

"el-GR" που δουλεύω είναι =","

Αυτό συμβαίνει γιατί σε κάθε culture της dotnet η αντιστοιχεία του δεκαδικού σε κόμμα η τελεία είναι αλλιώς. Εδώ στην ελλάδα πως το κάνουμε σωστα? Έχει κανείς ιδέα πως το φτιάχνω αυτό για όλη την εφαρμογή μια και καλή?

Δεν είναι καλή ιδέα να παίζεις με το Culture για να φέρεις την τελεία στα μέτρα σου. Ο χρήστης έχει ρυθμίσει τα Windows μέσα από τα Regional Settings να χρησιμοποιούν έναν συγκεκριμένο χαρακτήρα για τα δεκαδικά και αυτόν περιμένει να δει όταν πληκτρολογεί. Μήπως να κοιτάξεις πώς μπορείς να κάνεις σωστό parsing του input που δίνει;

Ο Μανώλης έχει δίκιο, αν και στην περίπτωση του δεκαδικού του αριθμητικού πληκτρολογίου είναι ξεκάθαρο τί θέλει να κάνει ο χρήστης. Απλά, αντί να το αντικαθιστά κανείς με καρφωτό το "," (το οποίο μπορεί να ΜΗΝ είναι το σωστό δεκαδικό στο μηχάνημα του χρήστη) θα πρέπει να το αντικαθιστάς με το δεκαδικό του culture του CurrentThread.

Το πραγματικό πρόβλημα είναι τί γίνεται όταν ο χρήστης πατήσει απευθείας το κόμμα ή την τελεία? Μπορεί να θέλει να βάλει χιλιάδες, ή να θέλει να βάλει δεκαδικό. Αν το πρόγραμμα δεν έχει τηλεπαθητικές ικανότητες (δεν είναι και πολλά τέτοια) δεν μπορείς να ξέρεις τί θέλει πραγματικά να κάνει ο χρήστης και θα πρέπει να σκεφτείς εσύ κάτι. Μία πιθανότητα είναι να επιτρέπεις μόνο την εισαγωγή του χαρακτήρα που αντιστοιχεί στο δεκαδικό. Είναι σχετικά σπάνιο οι χρήστες να θέλουν να προσθέσουν χιλιάδες, οπότε αυτή η λύση νομίζω δεν θα ενοχλήσει τους χρήστες.

Όλα αυτά μπορείς να τα μαζέψεις σε ένα δικό σου UserControl έτσι ώστε να το χρησιμοποιείς απευθείας από το Toolbox

pandelaras:

Αυτό συμβαίνει γιατί σε κάθε culture της dotnet η αντιστοιχεία του δεκαδικού σε κόμμα η τελεία είναι αλλιώς.

Τα culture του dotnet απλά κάνουν mapping τα regional options των windows. Αυτά τα τελευταία είναι που έχουν την υποδιστολή διαφορετική για κάθε χώρα.

Ίσως αυτό που μπερδεύει πολλές φορές τον κόσμο είναι ο ορισμός του NumberDecimalSeparator property στο documentation: "Gets or sets the string to use as the decimal separator in numeric values" που δείχνει και την μικρή σημασία που δίνουν πολλές φορές οι αμερικάνοι κατασκευαστές στο localization (αγγλικά μιλάνε οι άνθρωποι και είναι και χρόνια μπροστά από εμάς, οπότε συνήθισαν να προσαρμόζονται οι άλλοι σε αυτούς!).

Ένας πιο σωστός θα ήταν: "Gets or sets the string to use as the decimal separator in numeric values when these numeric values are represented in a user-friendly string". Ουσιαστικά το NumberDecimalSeparator σε απασχολεί όταν διαβάζεις ένα νούμερο από κάποιο textbox ή βάζεις ένα νούμερο σε κάποιο textbox, στο οποίο προφανώς έχει (οπτική) πρόσβαση ο τελικός χρήστης:

double myNumber = 3.324;

textbox1.Text = myNumber.ToString();

myNumber = Double.Parse(textBox1.Text); 

Και συγκεκριμένα χρησιμοποιώντας τον παραπάνω κώδικα, ουσιαστικά σε απασχολεί μόνο στο παρασκήνιο καθώς η ToString και η Double.Parse κάνουν όλη τη δουλειά για σένα. Η πρώτη γραμμή θα έχει πάντα τελεία καθώς είναι κώδικας. Δεν την βλέπει ο χρήστης. Το textbox1 θα πάρει την τιμή "3,324" στην Ελλάδα ή "3.324" στις ΗΠΑ. Όταν η τιμή επιστρέψει στο myNumber θα έχει φυσικά τιμή 3 κόμμα 324, ενεξαρτήτως regional options.

Από εκεί και πέρα στην εφαρμογή σου το νούμερό σου "κυκλοφορεί" σαν double και δεν έχει καμιά σημασία πως συμβολίζεται η υποδιαστολή. Απλά κάθε φορά που θέλεις να εμφανίζεις το νούμερο στον χρήστη ή να τον διαβάζεις από τον χρήστη πρέπει να χρησιμοποιείς τον παραπάνω κώδικα. 

Dimitris Papadimitriou Software Development Professional

Εεεεεε... Κάποιος (ονόματα δε λέμε, υπολήψεις δεν θίγουμε) δεν χρησιμοποιεί FxCop

Το σωστότερο είναι να παρέχεις τον IFormatProvider ώστε να είσαι σίγουρος. Πχ

string myNumberAsString = myNumber.ToString(CultureInfo("el-GR"));

double myNumber = Double.Parse(myNumberAsString, CultureInfo("el-GR"));

Εναλλακτικά, μπορείς παντού να χρησιμοποιήσεις το InvariantCulture

string myNumberAsString = myNumber.ToString(CultureInfo.InvariantCulture);

double myNumber = Double.Parse(myNumberAsString, CultureInfo.InvariantCulture);

Αν δεν βάλεις το IFormatProvider τότε χρησιμοποιείται εμμέσως το CurrentCulture, με τα γνωστά απρόβλεπτα αποτελέσματα. Επιπρόσθετα, ακόμα καλύτερα είναι να χρησιμοποιήσεις το TryParse.

Με δεδομένο ότι το πρόγραμμα τρέχει με το CurrentCulture, δεν νομίζω ότι θα έχει απρόβλεπτα αποτελέσματα, το αντίθετο. Το Culture του thread δεν επηρεάζεται από τη γλώσσα του πληκτρολογίου τη στιγμή που ο χρήστης πατήσει το δεκαδικό στο πληκτρολόγιο. Ο χρήστης μπορεί να το πατήσει και στο TextBox να φτάσει είτε "," είτε "." χωρίς να ξέρει η εφαρμογή τί από τα δύο είναι. Ξέρει όμως ότι είναι όντως το δεκαδικό του πληκτρολογίου.

Αν προσπαθήσουμε να κάνουμε parse χρησιμοποιώντας συγκεκριμένο culture οι πιθανότητες να πετύχει θα είναι 50-50. Αν π.χ. ο χρήστης πριν από λίγο κοίταζε το browser του, θα έχει γυρίσει το πληκτρολόγιο στα αγγλικά. Αν δούλευε στο Word, μπορεί να το έχει στα ελληνικά.

Δεν ξέρω τελικά αν τον βοηθήσαμε τον άνθρωπο ή τον μπερδέψαμε!

Όντως το fxcop βγάζει warning για οποιαδήποτε method έχει overload που παίρνει culture. Ήθελα να το ψάξω αυτό εδώ και καιρό! Κατά τα άλλα, όπως λέει και ο Παναγιώτης, δεν βλέπω που είναι το πρόβλημα.

Επίσης, σχετικά με το ότι ο χρήστης μπορεί να έχει γυρίσει στα αγγλικά και να το έχει ξεχάσει (οπότε τότε η υποδιαστολή στο αριθμητικό πληκτρολόγιο επιστρέφει τελεία αντί για κόμμα), μπορεί να χρησιμοποιηθεί και το άλλο overload της parse: Double.Parse Method (String, NumberStyles)

Με αυτήν έχουμε έλεγχο ως προς το τι μπορεί να γίνει parse, οπότε μπορούμε να μην δεχόμαστε π.χ. group separator (χιλιάδες) και να δεχόμαστε μόνο υποδιαστολή. Σε άλλη περίπτωση exception ότι το κείμενο που έβαλε ο χρήστης δεν είναι έγκυρος αριθμός. 

Dimitris Papadimitriou Software Development Professional

Απρόβλεπτα αποτελέσματα, εννοώ από σύστημα σε σύστημα με διαφορετικά regional settings. To parsing με συγκεκριμένο culture έχει να κάνει με το τι περιμένεις να διαβάσεις και το τι θες να δείξεις. Αν θες να δείξεις ένα νούμερο με δεκαδικά ως text με Ελληνικό format το CurrentCulture δεν αποτελεί εγγύηση ότι θα το δείξεις σωστά. Αν πάλι περιμένεις να διαβάζεις νούμερα με Ελληνικό format, τότε θα πρέπει να το προσδιορίσεις ανάλογα. Αν ελέγχεις εσύ τόσο το input, όσο και το output, παίζεις με το invariant και έτσι είσαι σίγουρος ότι η εφαρμογή θα συμπεριφέρεται το ίδιο, άσχετα με regional settings. Από εκεί και πέρα, το user input δεν είναι μόνο θέμα πληκτρολογίου. Αν ο χρήστης κάνει copy/paste νούμερα από Excel με λάθος format;

Άρα, τι θα περιέχει το myNumberAsString παρακάτω;

double myNumber = 1234.56;
string myNumberAsString = myNumber.ToString();

Άγνωστο, μπορεί "1234.56", μπορεί και "1234,56", εξαρτάται από το Culture. Τι θα μου δώσει το παρακάτω;

string myText = "1234.56";
double myNumber = Double.Parse(myText);

Άγνωστο, μπορεί να παίξει, μπορεί και όχι, εξαρτάται από το Culture. Και στις δύο περιπτώσεις έχουμε απροσδιοριστία.

Ταπεινή μου άποψη είναι ότι στην συγκεκριμένη περίπτωση του text input από πληκτρολόγιο είναι λάθος η προσπάθεια να αποφευχθεί το validation εκβιάζοντας συγκεκριμένη συμπεριφορά κατά την πληκτρολόγιση. Θα πρέπει να μην γίνεται επέμβαση κατά την πληκτρολόγιση και αν ο αριθμός τελικά δεν έχει το σωστό format να μαρκάρεται το πεδίο ως invalid και να πρέπει ο χρήστης να το διορθώσει. Όπως και να έχει, όταν περιμένεις δεκαδικούς ή ημερομηνίες να έρθουν από κάπου έξω, χρειάζεται πάντοτε έλεγχος.

Ρε παιδία, το switching από εφαρμογή σε εφαρμογή, αλλάζει και τη γλώσσα του πληγκτρολογίου ανάλογα. Και οι δύο λέτε αν το έχει γυρίσει σε άλλη γλώσσα και το ξέχασε, κλπ. Τι στο καλό, έχω ειδική έκδοση Windows?

Μα δεν λέμε (εγώ τουλάχιστον) απαραίτητα για switching εφαρμογών. Μπορεί απλά ο χρήστης να γύρισε αγγλικά και να το ξέχασε, να κάνει τυφλή πληκτρολόγηση και enter και να μην πρόσεξε ότι έβαλες τελεία αντί για κόμμα.

Κατά τα άλλα, για να ορίσουμε το απρόβλεπτο πρέπει να ορίσουμε τι θέλουμε. Σε όλο το αυτό thread έχω στο μυαλό μου ότι αυτό που θέλω είναι το εξής: Ο κάθε χρήστης της εφαρμογής μου να γράφει και να διαβάζει αριθμούς και ημερομηνίες ανάλογα με τα regional options που έχει στα windows. Αυτό πιστεύω ότι είναι το σωστό. Οπότε και από το excel να πάρει κάτι copy/paste θα το πάρει με τα ίδια κριτήρια. Οπότε δεν θέλω να κάνω κάτι για να αποφύγω την χρήση του thread current culture.
Αν πάλι κάνω κάτι πολύ ειδικό και θέλω ντε και καλά να εμφανίζω ένα νούμερο με τελεία σαν υποδιαστολή, τότε όντως πρέπει να βάλω στην parse κάποιο συγκεκριμένο culture και να αποφύγω το culture του thread (οπότε κατ' επέκταση τα regional options).

Από η συμβουλή μας προς τον φίλο μας που έκανε την ερώτηση είναι να μην το κάνει αυτό, εφόσον δεν υπάρχει ιδιαίτερος λόγος. Να αφήσει τον χρήστη να γράψει την υποδιαστολή όπως θέλει (όπως δηλαδή είναι στα regional options) και να αφήσει την parse να κάνει την μετατροπή.

Τώρα γιατί το fxcop βγάζει warning είναι ένα θέμα σκοτεινό σημείο για μένα. Αν μπορεί κανείς να το φωτίσει...

Dimitris Papadimitriou Software Development Professional

Σας ευχαριστώ πολύ όλους, με βοηθήσατε όντως να εντοπίσω το πρόβλημά μου και την λύση του!

Όταν ο χρήστης έχει regional settings στα windows ΕΝ τότε η τελεία στο keypad είναι διαχωριστικό για τις χιλιάδες.

Όταν ο χρήστης έχει regional settings στα windows EL τότε η τελεία στο keypad είναι διαχωριστικό για τους δεκαδικούς.

και όντως είναι πιο καλό να μην το πειράξω γιατί μπορεί να έχει απρόβλεπτο αποτέλεσμα (ή είναι μπελάς για να έχει το προβλέψιμο σε όλα τα regional settings !).

Ωραία, να ορίσω κι εγώ τι θέλω ή μάλλον τι κατάλαβα ότι θέλει ο φίλος μας. Υποθέτω ότι εφόσον θέλει να αντικαθιστά την τελεία (όποτε πληκτρολογείται) με κόμμα, άρα περιμένει πάντοτε να διαβάσει input στα Ελληνικά.

Συμφωνώ ως προς το ότι τελικά προτείνουμε "να μην το κάνει αυτό, κλπ", ωστόσο επειδή δεν γνωρίζω παρακάτω (ή παραπάνω) πώς χρησιμοποιείται το input αυτό, θα πρέπει να ελέγξει μήπως χρειάζεται να προσδιορίσει το culture.

Ιδανικά, αν το ζητούμενο είναι να περιοριστεί η πληκτρολόγιση σε valid νούμερα την ώρα που πληκτρολογούνται ώστε να μην γίνεται τσάμπα πληκτρολόγιση, θα πρέπει να χρησιμοποιήθεί ένα textbox control που να κόβει οποιοδήποτε key πατηθεί και κάνει invalid το γραμμένο νούμερο. Σε αυτήν την περίπτωση δεν αρκεί η αλλαγή από τελεία σε κόμμα, θα πρέπει να κόβονται τα γράμματα, κλπ. Εγώ θα το έκανα κάπως έτσι:

• Στο KeyDown και το MouseDown αποθηκεύω τα περιεχόμενα του TextBox
• Στο TextChanged κάνω TryParse και αν φέρει false, κάνω discard τα περιεχόμενα και επαναφέρω τα αποθηκευμένα.

Dimitris Papadimitriou:

Τώρα γιατί το fxcop βγάζει warning είναι ένα θέμα σκοτεινό σημείο για μένα. Αν μπορεί κανείς να το φωτίσει...

Υποθέτω ακριβώς λόγω της απροσδιοριστίας που ανέφερα.

Όντως αυτό ακριβώς ήθελα να κάνω. Απλά προσπαθούσα να γίνει χωρις να χρειαστεί να το κάνω αυτό για όλα τα textbox controls της φόρμας. (δεν ξέρω αν είχα και grid αν θα είχα το ίδιο πρόβλημα). Γι' αυτό και ρώτησα μήπως υπήρχε κάποια ποιο απλή λύση. Σωστά αναφέρετε ότι είναι καλύτερα να μην παίζουμε με πράγματα που δεν γνωρίζουμε τι επιπτώσεις μπορεί να έχουν (αναφέρομαι σε εμένα).

Και σας εύχαριστώ για την βοήθεια γιατί όντως έλυσα το πρόβλημά μου!

Αν φτιάξεις ένα TextBox που δουλεύει όπως θέλεις, μπορείς μετά να βασίσεις όλα τα υπόλοιπα TextBoxes σου πάνω σε αυτό, δηλαδή δεν είναι ανάγκη να κάνεις copy/paste τον κώδικά σου πολλαπλές φορές. Θα φτιάξεις ένα "Custom" TextBox Control που αλλάζει τη συμπεριφορά του κλασικού TextBox control.