I think I’ve already worked out this answer but just want to confirm.
I’m using a pattern picture for entering phone numbers and had the “brilliant” idea of defaulting an area code when the entry in blank then highlighting the remaining portion for entry using SELECT.
Doesn’t work of course and I’m pretty sure it’s because of the pattern picture.
Am I correct in assuming that there is no way around it using standard Clarion?
Buying a 3rd party tool isn’t worth it for this.
I’m not sure of your question, but I’ve found insisting on a format for phone numbers to be somewhat fraught. Different people and countries have different ideas about what format is correct.
for example in Australia ph numbers are usually (nn) nnnn nnnn , sometime without the () but mobile numbers are usually formatted as nnnn nnn nnn I personally prefer the first format for everything and get annoyed when forced into the 2nd format
So my stuff for phone numbers I use s20 and leave it at that
1 Like
I gave up on using pattern pictures for phone numbers and other data where I do not control the format, eg postal/zip codes.
It does make things look nice, but when your customer has a client from another country the number of digits in the phone number may be different.
3 Likes
To answer your question jock, you could use 2 entry controls, with IMM set on the first one .
However as others have noted, forced formatting always ends up being a bad idea in the long run.
The short reason why is because sooner or later you come across exceptions to the rule. For phone numbers the obvious exception are “international numbers”. A tourist walks into your shop, a contractor from overseas is employed, and so on.
Phone numbers are “pure data”. Youre not going to do math on them. The person supplying the data should be allowed to enter it anyway they like. They know how to do it correctly, not you.
This is true for names, addresses, phone numbers, id numbers, and so on. Make the fields big. Make them strings.
Oh I get what everyone is saying about formatting phone number etc. In this case however it’s a small bespoke application for one & only one specific client who operates in only 2 Caribbean countries with identical formats.
If this was intended for general use then no way I’d even consider this.
It was just a little helper for the data entry and not required or even requested. Since it won’t work, no loss.
Forcing someone to use “Address1”, “Address2”, “Address3” to shoehorn their data is not doing anyone any favors either. I like large multiline address controls. Their city/state/zip (or whatever you call it in your particular region) can all be made consistent with lookup tables. Addresses can be looked up too, but oftentimes the user knows better what should go there, especially in areas where landmarks could be more useful than addresses.
however it’s a small bespoke application for one & only one specific client who operates in only 2 Caribbean countries with identical formats.
You forgot to add
“The company will never change, the countries will never change, and the company will never have a dealing with any individual outside of the countries.”
For 30 years I’ve been dealing with issues in my own software brought about by changing specs, and things that were "never going to happen " happening.
…but in this case this is almost absolutely so and in the very unlikely event that any of that does happen, I won’t be involved. 
Yes I’m well aware of the “never gonna happen” actually happening. It’s been a source of both frustration and sometimes finance in my nearly 40 years of writing code.
But really you guys are overthinking it. What I really wanted to know was if selecting a block in a pattern field was possible. The fact that I was playing with a phone number field was what prompted the question.
Don’t get hung up on the question of phone or address etc. That was not the question.
Agreed!! That’s not what this was about though.
The actual question was can SELECT be used to select a block in a pattern picture field. Apparently the answer is no which is fine.
Think outside the box. If the Area code never changes… why enter it all? Make the phone number two fields and default the area code to the correct value and use the skip attribute.
In Riverside, we used to be 714, then 909, then 951. And cellular phones could be anything.
Seem like everybody is missing the actual question - can SELECT highlight a block in a field with a pattern. That’s it - that’s all… and the answer is apparently not.
Everybody is fixated on the whole phone number format thingy which was only used to illustrate the point. It could have been any other pattern but it’s just that example the prompted the query.
Hi
I wrote this very simple test and it seems to work if you use PROP:SelStart and PROP:SelEnd
PROGRAM
MAP
END
PhoneString STRING(11)
Window WINDOW('Caption'),AT(,,176,88),GRAY,FONT('Segoe UI',9)
BUTTON('&Select Entry'),AT(45,26,41,14),USE(?SelectEntry),DEFAULT
ENTRY(@p###-###-###p),AT(90,28),USE(PhoneString)
BUTTON('&Close'),AT(102,53,42,14),USE(?Close)
END
CODE
PhoneString = '123000000'
OPEN(Window)
ACCEPT
Case ACCEPTED()
OF ?Close
BREAK
of ?SelectEntry
SELECT(?PhoneString)
?PhoneString{PROP:SelStart} = 5
?PhoneString{PROP:SelEnd} = 11
END
END
Close(Window)```
Pressing the button seem to achieve what you are after?
MarkIn fact it works if you just issue SELECT(?PhoneString,5,11)
So I might be missing what you are asking.
Updated example below, including handling when the field is selected by tabbing. I do note it seems to get unselected when you select with the mouse probably because that is placing the cursor.
PROGRAM
MAP
END
PhoneString STRING(11)
Window WINDOW('Caption'),AT(,,176,88),GRAY,FONT('Segoe UI',9)
BUTTON('&Select Entry'),AT(45,26,41,14),USE(?SelectEntry),DEFAULT
ENTRY(@p###-###-###p),AT(90,28),USE(PhoneString)
BUTTON('&Close'),AT(102,53,42,14),USE(?Close)
END
CODE
PhoneString = '123000000'
OPEN(Window)
ACCEPT
Case ACCEPTED()
OF ?Close
BREAK
of ?SelectEntry
SELECT(?PhoneString,5,11)
END
Case Event()
OF EVENT:Selected
Case SELECTED()
OF ?PhoneString
SELECT(?PhoneString,5,11)
END
END
END
Close(Window)
Hi Mark, that’s the behaviour I expected but it didn’t work, hence the question. Thought it was rather odd.
Maybe I’ll just try different pattern just to see if it’s that particular pattern that was the issue.
Thanks for the input even though I’ve decided not to bother in this case as it was merely an idea I had rather than a requirement.