Community
Showing results for 
Search instead for 
Do you mean 
Reply

ContactLookup, iContactSource issues

Bronze Elite Contributor
Posts: 2,115
Country: United_Kingdom

ContactLookup, iContactSource issues

Hi, 

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? 

 

TIA.

Vivek Gargav
Caldere Associates Ltd.
www.caldere.com
vgargav@caldere.com
My Blog
Bronze Elite Contributor
Posts: 2,115
Country: United_Kingdom

Re: ContactLookup, iContactSource issues

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?

Vivek Gargav
Caldere Associates Ltd.
www.caldere.com
vgargav@caldere.com
My Blog
Employee
Posts: 1,163
Country: USA

Re: ContactLookup, iContactSource issues

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.

Matthew Wood
Act! SDK Support
Community Moderator
Bronze Elite Contributor
Posts: 2,115
Country: United_Kingdom

Re: ContactLookup, iContactSource issues

Hi Matthew,

 

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.

 

Cheers anyway.

Vivek Gargav
Caldere Associates Ltd.
www.caldere.com
vgargav@caldere.com
My Blog
Nickel Contributor
Posts: 175
Country: USA

Re: ContactLookup, iContactSource issues

[ Edited ]

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.

Bronze Elite Contributor
Posts: 2,115
Country: United_Kingdom

Re: ContactLookup, iContactSource issues

[ Edited ]

Hi Knif,

 

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.

Vivek Gargav
Caldere Associates Ltd.
www.caldere.com
vgargav@caldere.com
My Blog