05-31-2012 05:30 AM
I hope someone can help since this is driving me up the wall!
I have a Lookup where its necessary for the solution that I pass a SQL stmt to the relevant LookupContactsReplace() overload. This happily works and returns a ContactLookup object that can be used to populate the ContactList View in the UI. The only problem is that it has a Criteria.length =0 and so this means that Users cannot do further Narrow-downs or Appends to.
I thought the way around this issue might be to manually create a Criteria and then do a in-code narrow-down on the existing ContactLookup result to recreate it, however the key field I need is the CONTACTID which would reliably retrieve the Unique contacts.
Unfortunately the CONTACTID field is not an exposed MutableFieldDescriptor required to create CriteriaColumn...doh! Is there another way to do what I am trying to do that I have missed? Or how do others do this?
06-06-2012 07:27 AM
Well I'm still nowhere near an answer to this one sadly, maybe if I understood the design decision as to why the CONTACTID column is not exposed as a CriteriaColumn or a ReadOnly ContactFieldDescriptor I might have a better understanding of why what I am trying to do is unachieveable?
Failing that, how about having it as a SDK feature request?
06-06-2012 07:40 AM
Sorry for the delay in responding, I was hoping to have a better solution by the time I responded, but this wasn't as straightforward as I thought it might be when I delved into it.
I did have one thought on this, while it's not elegant it could be an immediate solution.
Create a new field in the application to store the contacts ID, no need to display the field but this way you'd have a mefd that you could use for your criteria. I can't speak to the design decision but hopefully this can be a work around for you.
06-06-2012 08:15 AM
No worries and thanks for trying and replying anyhow. I suppose I'm kind of relieved I didn't miss anything obvious!
Unfortunately that is the workaround I'm having to use, it does seem very ugly since playing around with schemas just for a plugin is not great! Looks like I will have to have a 2nd plugin watching for Contact Creation to populate the ID field (another workaround rather than event if memory serves me right).
I did get briefly excited when I saw the ActFramework.GetIDFieldDescriptor(Type) method but that was a dead end as well sadly.
06-08-2012 09:41 AM - edited 06-12-2012 05:33 AM
This is just a shot in the dark. If you know what the ContactID is, could you just use that in the SQL statement and filter using that?
I know this probably isn't the "proper" way, but it sure seems simpler than having a plugin to watch a plugin. Just my 2 cents.
*Edit: saw typo that changed meaning of the sentence.
06-12-2012 02:56 AM - edited 06-12-2012 02:56 AM
The problem with approaching via SQL is that you would need to either hard code or have some form of local store of SQL instance login data with the plugin to use the .NET ADO objects.
Another approach I had thought about was the OLEDB but the OLEDB does not expose the tbl_attachments table.
Thanks for the suggestion anyhow.