Re: [evolution-patches] Patch for ... adding three new important function for EContact...

[Chris Toshok <toshok ximian com>]

On Thu, 2004-08-05 at 18:36 +0530, Jayant Madavi wrote:
> Hi all,
> 
> Am a OOo hacker, my application(OpenOffice.org: "mail merge") required
> all the "synthetic structured field " in plain "char *" just like 
> e_contact_name_to_string(EContactName) or 
> e_contact_date_to_string(EContactDate)
> 
> I have added three function
> 1> e_contact_address_to_string(EContactAddress) 
> 2> e_contact_address_to_string_with_separator(EContactAddress,char)
> 3> e_contact_address_equal(EContactAddress,EContactAddress);
> 
> Attached with this mail is diff's for the same.
> 
> There is one more thing missing though E_TYPE_CONTACT_ADDRESS is defined
> but E_IS_ADDRESS(obj) is not defined. Actually it seems like e_contact_get
> (contact,E_CONTACT_ADDRESS_HOME) does not return "Object" but a pointer
> to struct EContactAddress !!! Please let me know if my guess is correct
> so that i can go ahead and write the function for same(if it is
> required :) ).
> 
> 
> Thanks,
> (aZEN_JM)


+ * Info for developer: Though address format is used for comparision
+ * but it is not actually used adr_setter does not even get the value
of it
+ * the address_format is put as "".

This block isn't needed.  Depending on the semantics we want, the code
should either 1) check to make sure they're equal, or 2) not use the
format when deciding if addresses are equal.  Either way, the block
should go.

I personally think that EContactAddress's should be considered different
if the format changes, but I'm willing to entertain arguments to the
contrary..

+gboolean
+e_contact_address_equal(EContactAddress *ad1, EContactAddress *ad2) {
+       if (ad1 && ad2) 
+       {
+               if ((0==strcmp(ad1->address_format, ad2-
>address_format)) &&

please use !strcmp(...) instead of (0==strcmp(...)). (we don't need the
extra parens).

+                       (0==strcmp(ad1->po,       ad2->po)) &&
+                       (0==strcmp(ad1->ext,      ad2->ext)) &&
+                       (0==strcmp(ad1->street,   ad2->street)) &&
+                       (0==strcmp(ad1->locality, ad2->locality)) &&
+                       (0==strcmp(ad1->region,   ad2->region)) &&
+                       (0==strcmp(ad1->code,     ad2->code)) &&
+                       (0==strcmp(ad1->country,  ad2->country)) 

and add the "!strcmp (ad1->format, ad2->format)" check.

+                       )
+               return TRUE;
+       }
+               
+       return FALSE;
+}

I also think if we're going to put address formating into EContact in
any way, we should do it the right way, i.e. using address->format to
determine the format to use.  This specific code for both
address_to_string and address_to_string_with_separator is probably
better placed in the mail merge program directly.

Also, the reason for not having E_IS_ADDRESS or something similar is
that EContactAddress is not a GObject.  It's a boxed type, so the
GObject macros won't work on it.  To free the object use
e_contact_address_free (or the slightly larger g_boxed_* equivalent).
e_contact_get does indeed return a pointer to the struct.  as it does
for names and dates and images and the other structured types.

Chris