InfoQube IM - Community

Submitted by Armando on 2009/08/31 17:21

My inefficient way to do that now is concatenate 2 fields (using a vb script) in another field "x" which has an "a:item = "x" ".

The problem with this is that the item can't get a further update if the field x is already populated.

I wanted to put an equation in the item field (=NameConcatenation(contact,item,FirstName,LastName) and have a corresponding VB function like :

Function NameConcatenation(contact,item,FirstName,LastName)    ' Concaténation des prénoms et noms
 
 if item = "" and contact = -1 then
   NameConcatenation = FirstName & " " & LastName
 
 elseif item <> "" and  contact = -1 and (FirstName <> "" and LastName <> "")  then
   NameConcatenation = FirstName & " " & LastName
 
 end if

end function

But... it doesn't seem to be possible...

How can I achieve that ? Any ideas ?

Thanks.

Comments

Ok... I forgot about the M: flag... Now everything works perfectly. Sorry.

The FullName field now has (in the auto assignment rule text box) :

AM:item=fullname | E:item=fullname

[edit : AM is better than M alone, of course... since M alone won't take into account situations where data is added on an empty field...]

And in the equation part :

=NameConcatenation(contact,item,FirstName,LastName)

And I've now modified my script -- previously, it was meant to protect those items which already had something in them... Useless.

Function NameConcatenation(contact,item,FirstName,LastName)    ' Concaténation des prénoms et noms
 
 if contact = -1 then
   NameConcatenation = FirstName & " " & LastName

 end if

end function

Just wanted to say to those who want to try such a thing that there are several ways of course to achieve that...

And :

"E:item=fullname"

Should probably removed for safety.

I should also probably write that use a new way (tried several) ... it's not perfect, not as concise as other ways, but it works well.

It contatenates FirstName + Name only when it's a contact, and protects the item field to avoid loosing data in certain conditions (Avoiding the "E:..." trap mentioned above, which empties the item field regardless...)

Here are 2 super simple functions to add to the user code or database code. (First you'll have to create 3 text fields (LastName, FirstNam, FullName) and 1 Yes/No field (Contact... but you could replace that by AdrsBook if you prefer...) -- in my dB, "contact" defines a contact in the address book.

===========================

function fullnameToItem(contact, fullname, item)

if contact = -1 then
fullnameToItem = fullname
else
fullnameToItem = item
end if

end Function

function clearItem(contact, item)

if contact = -1 then
clearitem = ""
else
clearitem = item
end if

end Function

============================

Now, in the "fullname" config ("Manage fields" dialog):

Autoassign rules:

AM:item= fullnameToItem(contact, fullname, item) | E:item=clearItem(contact, item)

Equation :

=FirstName & " " & LastName

==========================

Voilà. If the contact field is checked, The Firsname and LastName will be concatenated in the FullName field and copied in the item field. If Contact is unchecked, it will be concatenated in the fullname field but not copied in the item field.

If the FirstName and LastName fields are filled before the "contact" field is ticked, the item field won't be automatically filled with "fullname" content. This is by design, but I might change my mind... The firstName or LastName field have to be erased and re-entered to satisfy the AM: exigence in fullitem. This could be changed by creating a third function for the "equation" section of fullname... [edit : or by just adding "A:item=fullname" in the contact field (a bit less subtle)... (The danger is to replace the item field content if you check the contact field by mistake, even if "fullname" is empty. Oops. But some might prefer that...)]

Now, there are other simple ways, avoiding going through a secondary field named "FullName", but I like using this field for now... Like a backup/buffer in case something goes wrong. Not indispensable though.

Anyway, enough. Hope it can be useful to one or two users out there -- even if simplistic!

Armando, Thanks for posting this.

Over the years I've created contact lists by

LN > FN > MI

FN > MI > LN

Then one day I said: the hell with it & have been entering the full name as item for years on the assumption

that any dB worth its salt should be able to pull up an item either by searching part of the name, i.e. first or last name

I could never understand the logic of LN, FN as I usually refer to people as Armando or Pierre & not Rifkinson

I also include ID's, PW's, Lic # in Contact Base but can separate them by and boolean ID field

I'm not suggesting my way is the best way; just describing my logic

But for those who still separate FN, etc, having a way to join them as you have done (for labels, etc) is extremly useful

Jan Rifkinson

Ridgefield CT USA

HP Blackbird Vista Ultimate SP-2

[quote=jan_rifkinson]

Then one day I said: the hell with it & have been entering the full name as item for years on the assumption

that any dB worth its salt should be able to pull up an item either by searching part of the name

[/quote]

I know what you mean...

Usually separating info in several fields is convenient for sorting, having more flexibility in functions/equations or even displaying/printing (in templates, etc.). There are probably other uses apart from that, but if one is not going to do any of these, better keep it "simple.