Full Version: ProperCase Function
UtterAccess Forums > Microsoft® Access > Access Forms
I have sourced allen brownes' Proper case function.How and where do I call the function.I never know where to place them or how to call them.Sometimes I can manage a subcall but I have trouble knowing where functions go.Thanks David
G’day David.
haven’t seen Allen Browne’s proper case function but wouldn’t mind having a look.
London to a brick it’s in a Public/Global/Standard module because that’s the way he writes.
Any chance of a link to his article?
OK, found it.


Hmmm…It goes in a public module but Allen is writing speed code here and it is not so simple to follow.

But first note the limitation that he states. I will simply add that it is not possible to proper case in all conditions.

Yes I have seen r_cubed’s efforts and it is a valiant and superb effort in the face of the impossible.

But I still think it is impossible. The fundamental reason is that… even if a lookup table can be constructed it would need to be maintained. The lookup table would not only need to be correct for today but for all time. Any new, and as yet undefined, name would need to be incorporated.

Incorporating the as yet undefined could get tricky.


Edited by: ChrisO on Mon Nov 8 1:53:03 EST 2004.
Chris, (taking you, slightly, to task here)
I am interested ....... I am not sure that you understand what the functionality of the (optional) table is to my utility, so could you expand on what you have stated.
Please note, the table in my utility IS OPTIONAL, and has NO BEARING on the 'normal ProperCasing' functionality of the utility.
The (optional) table is only applicable/used if required and for specific purposes, per application, if you like.
G’day Rob.
Chris, (taking you, slightly, to task here)”
Why only slightly to task? If I have stuffed up then go for it.
HAs the majority said in the last US elections…don’t beat around the Bush.
Your demo requires rules.
Rules need to be predefined.
Predefining rules requires a statement.
Predefining a statement requires an algorithm.
If there is a complete algorithm then storing even partial results violates normalization.
(Why, rhetorically, have a table at all but simply proper case names on the fly?)
Odon’t think it is possible.
I have had 1 16 hour day, so will NOT labour (with a "u") here long at this time, but will get back to you with the points you have raised.
However , your FINAL point about ...."have a table at all but simply proper case names on the fly" STILL seems to miss the point that the table that I (optionally) reference in my utility IS OPTIONAL, and in the main, all "proper case names" ARE "done on the fly" with NO reference to the table.
Microsoft (Access) 's strConv(xxxxx, vbProperCase) command does NOT handle names like :
mcdonald , mcpherson, o' toole, van leen, de groot.
By admission, Allen Brown'es code also does NOT handle mcdonald, van leen (not sure about the others).
For the mcpherson, mcdonald, o'toole examples, my utility DOES, .... AND without using the table.
For the van leen and de groot examples see a little later in THIS post.
The table is ONLY used, and maintainable by the user) for those SPECIAL words (or letter combinations) which the USER determines as ALWAYS wanting to be in a set-format
e.g. strConv, Allen Brown'es code, my code (without the table) would format NSW and BHP (2 words/terms that you and I recognise (being Aussies)) as:
Bhp , Nsw
However, via the use of the table in my utilty, a user can define within there that such words ALWAYS appear as:
whilst formatting any other words 'around' these lertter-combinations into the standard ProperCase format.
The same table can ALSO handle the van leet and de groot examples by simply adding the words 'van' and 'de' to the table, as special words. If they were NOT added to the table, I certainly admit that , for THOSE particular types of names, my utility would NOT format them correctly. Whether a user wishes to worry about THAT is entirely up to them.
The use of this table is VERY MUCH like the use of the auto-correct list that accompanies Microsoft Word, and which in itself, is maintainable by the user, as is MY table.
Please note, that, as far as I am personally conerned my utility is NOT simply used for the auto-formatting of names and places. It can be used whereever, and whenever a developer chooses, in ANY of the Access objects (i.e. forms, queries, module code etc).
At the moment, in both the demo AND in my currently active applications , the 'special table' contains ONLY 36 'special' words/letter combinations that , as of now, I have decided I need to handle both the demo and ANY/ALL 'live applications', and 12 of these revolve around the various combinations of Aussie state abbreviations that we can have (e.g. N.S.W. or NSW etc) so that they are formatted as I have indicated above.
G’day Rob.
o me the point of posting on a site like this is to try, the best we can, to educate.
I have a particular style of thinking…something I call end-point thinking.
(‘Site still under development’ so please don’t complain too much. wink.gif )
It involves pushing the logic till it either succeeds or fails. “Reductio ad adsurdum”
Rob…we are not talking about the same thing here.
HAs much as I dislike absolutes, or maybe because of it, I think absolutes in order to try to disprove them.
(My fundamental is to disprove my thinking…which is after all… myself.)
(And, incidentally, that is achieved with the help of others.)
Enough waffle from me, so back to the issue…
CAn algorithm that is perfect is… simply perfect. It should have no exceptions.
Any lookup table, required or not, would not be required for the perfect algorithm.
Therefore, the perfect algorithm requires no stored data but can calculate it.
The above three lines equate, in total, to False.
Ergo…there is no such thing as perfection (Except perhaps the perfect imperfection.)
Your demo does rest quietly with me.
It states the need for the exception and in doing so also states the imperfection of the algorithm.
As Manuel would say :
ue ???
G’day Rob.
ue ??? I come from Barcelona… I know nothing. shrug.gif
Seconds out…round 2. grin.gif
For better or for worse, here’s the way I see it.
The proper case function in Access does not work correctly under all conditions.
All it does is reduce a string to lower case and then convert the first letter of the string to upper case and any letter after a space to upper case.
This obviously doesn’t work correctly all the time, because of the known exceptions.
(And the exception is the thing that also applies to spelling checks as well.)
So the proper case function is not perfect… it, like the spellchecker, produces undesirable results sometimes.
So a workaround is included in your demo and the spell checker to improve performance, namely a table of known user entered exceptions to the general algorithm (rule if you like).
If the algorithm was perfect then there would be no need for an exception table.
The very existence of a possible exception table means that the algorithm is imperfect.
That is not a derogatory statement against your demo or the spell checker.
I see it as an excellent workaround to an algorithm, which is so complex that by nature must be imperfect.
Hi fellas thanks for your time and input unfortunately I did not understand a word you saying.Kind regards David
G’day David.
It should go in a Public/Global/Standard module (They at times all go by one name or another.)
The reason I suggest a Public/Global/Standard module is that a function like that can be used throughout the database not just locally behind a form or report.
You might see at times a word or reference to something called scope. Scope is the area from which the function or subroutine can be accessed.
There are basically two types of scope for functions or subroutines. (To save typing let’s call them procedures.)
A procedure can be defined as Private or Public.
A Private procedure can only be accessed from within the module which contains it.
This is typically done in the modules behind forms and reports.
For example: -
Private Sub Form_Open(Cancel As Integer)
The Private Sub Form_Open procedure is Private to that particular form. It can only be accessed from within that form’s module, called a Class module.
And the same goes for Reports.
So Private procedures are restricted in scope to the form or report class module.
But Allen Browne’s proper case function is likely to be used from many different places throughout the database. So it should be Public and in a Public module and have no restrictions in scope.
Hope that helps but fire away if it doesn’t.
thanks Chris I will give it ago.
This is a "lo-fi" version of UA. To view the full version with more information, formatting and images, please click here.