Hi @Saeed and @mipiano , I've edited the file I shared above to provide a bit more refinement (and corrected a typo in one country name's spelling ).
In this file, if the country code is already entered but it matches the newly selected country code, the user is not asked if they wish it replaced.
There is also a different option for selection from a card window, the appropriate country code to be inserted if one chooses Dominican Republic or Puerto Rico; a card window offers a portal from which to select.
To see this effect, NAVIGATE TO THE SECOND SLIDE PANEL and simply select Dominican Republic for the country value.
I did not add a search method example (find as you type? or?) as I'm not sure what @Saeed envisions for the U/X, and my users prefer pop-up menus or drop-down lists for such selectors. If help is needed with this part I'm sure the Soup can help.
This was not thoroughly "smoke tested" so there may be some quirks if I missed a possible user workflow differing from mine.
Hi @daleallyn , I love the card window for such purposes!
In the next few days I will try to collect the regional and mobile area codes of each country: For a better presentation (e.g. +49 9078 12345678) and to be able to check to some extent whether the number matches the country.
This will take a few days because I have other work to do "on the side". But I'll deliver later.
Hopefully the conversation helps lead @Saeed towards what they need, @mipiano. There are lots of ways to handle such tasks.
Telephone numbers are tricky (or can be). In the U.S. area code fields (not country code) are becoming less popular for some, because now such phone numbers are "portable" for mobile numbers, and many have moved to all mobile options. The area codes may not longer indicate the locale. E.g. my US mobile number has a "California" area code, while I no longer have an address in California. Such numbers are now completely portable within the U.S.
Here in Thailand mobile phones are probably most important, but of course businesses typically have land lines. All land lines dialed in the greater Bangkok area without country code use "02" prior to the telephone number, but with +66 (country code) it's just "+66 2 123-4567", i.e. no "0".
Further, mobile numbers (often the only number(s) for many businesses) started with "081" back in the day. Now there's "083", "089", "063", "09X"... and a plethora of others, since the demand of new mobile numbers exploded. Mobile numbers start with 08, 09, or 06 (newest), followed by an additional digit. And yet they don't indicate region at all.
Personally, I try to store all of my Thai contact phone numbers (and really all contact's numbers) fully formatted, e.g. +66 81 123-4567 because they work inside or outside of Thailand when dialing, as well as Apps such as WhatsApp (sadly very popular here and also almost exclusively used in Bahrain; LINE app is also very popular here in Thailand). That's also how I store them (by calculation) in data management systems so that they can be easily integrated for various needs.
The telephone numbers are saved in a diable format anyway. I only want to use the formatting for the display on the screen.
Here in German-speaking countries, this is not yet as extreme as you have described. Landlines are still frequently used - especially in the business sector. Landline numbers can only be taken within an area code when moving.
And with smaller companies, I often find that people look up numbers in the app and then dial them manually on the phone. That's why I want the phone number display in the app's home country to be set to the domestic spelling and nicely formatted. If you initiate the call via the app, the saved international number is of course used.
Following your advice, I will initially only implement this display formatting using domestic area codes for European countries.
Perhaps Soup members from other countries can give me more information about their regions. What would make sense for their country?
I would be grateful for your tips!
My goal is to make this little technique useful for developers no matter where they live.
One shortcut I took in my little sample file was that I hard coded the test for the two countries with multiple country codes. Not my preferred approach, but I was being lazy since there are only two (that I know of) at this time. A better approach would be make it dynamic for any with multiples, but with only two I might put such a better practice off until I see another country adding the practice of multiple codes.
It’s a small enough list (~250) that making it dynamic to test for multiples every time wouldn’t be too bad of a hit. Just lazy today, as I had work to do.
Apologies for the delayed response. I want to express my gratitude to @mipiano and @daleallyn for their contributions and comments. I have greatly benefited from the new methods shared here.
I will now attempt to include the +971 is default plus , implement a search function to make it easier for visitors to select their desired country.
Typically, our visitors come from various locations, including the internal region, the Arabic Gulf, China, Japan, France, the UK, and the US.
After introducing a new table for country codes and confirming that the existing functionality is operational, I encountered a challenge in enhancing the script. Specifically, I am seeking to refine the script to ensure that the telMain field contains 8 digits for the country "United Arab Emirates." For other countries, the script should enforce a minimum length of 5 digits. Regrettably, the current script overlooks this condition and proceeds to the same layout.
Hi, @Saeed , please have a look at line 38 in your script where the "≥" operator is used. For enforcing users to enter at least 5 digits you'll want to use "≤" with "4" for the conditional challenge, or "< 5". As is written now it sends the user to the telMain field if there are five (5) or more digits, not fewer than 5. OR you could add "not" to the IF statement so that you're stating "IF not (Length... ... ... ) ".
Also, I'm not sure where this script is running (what layout/context), but if I understand correctly, on the lines after the "Go to field (Visitors_System::telMain)' you don't need the steps to Go to Layout (original...). You'd just go to the field you wish them to correct.
You may like to consider a custom dialog informing of why you're sending them to correct the telephone number as well.
).
