10-01-2012 11:44 AM
When I put a valid guid in the GetHistory method it returns an empty HistoryList. I'm using ACT! 2013. Can someone else test this for me and see if they get the same results?
10-02-2012 05:10 AM - edited 10-02-2012 08:02 AM
Are you using a history ID or an entity ID as the guid parameter? Unless I'm mistaken it only accepts the latter.
I did not test this in the current gold build but in a more recent one and I could not produce the results. If you are using an entity ID and this is occurring let me know and I'll get that version installed and test.
10-02-2012 07:39 AM
I was using a History ID but I thought that was the Entity whose ID I was supposed to use. Are you saying that it is expecting a ContactID, GroupID, OpportunityID or CompanyID? I guess in retrospect that would make more sense since they are considered Entities in ACT! and a History isn't an Entity but is a Sub Entity. I haven't tested using an Entity ID but I'll test it to see what happens. I'm a little surprised that it would work that way though because it would have to search all four tables since there isn't a type constraint associated with the method. When using Generics you usually have a type associated with it. I would have expected something like GetActivity(of Contact,ContactID) or GetActivity(of Group, GroupID), etc.
I would like each entity and sub entity to have a GetEntities method that returned all entities of that type and a GetEntity method that returned the specific entity by ID (both entities and sub entities). It should probably be constructed like a Generic. For example:
GetEntities(of Group) as GroupList
GetEntity(of Group, GroupID) as Group
GetSubEntities(of History) as HistoryList
GetSubEntity(of History, HistoryID) as History
That would simplify a lot of things that we need to do. I actually wrote my own yesterday using Generics so I have generic methods now that will do it but they aren't as elegant as they would be if I were writing them using SQL statements. I basically used the existing SDK methods to get all the information that I needed to construct my methods writing a sort of facade layer of my own. I've done that in other areas but this is the first time I did it for all the various sub entities.
While we're on the topic it would be nice if we could easily add and remove entities or sub entities from the lists. For example:
gList.Add(Group) would result in the new Group being added to the GroupList and gList.Remove(Group) would result in the Group being removed from the GroupList. We would want that for all of the various lists.
One way to achieve this would be to extend Mutable Entities to all of the entities and support those features. That would seem to be the logical way to do it based on the current system. If you were to extend the Mutable Entity paradigm so that it supported those methods using Generics that would be the simplest solution from Sage's end. So it would be:
GetMutableEntities(of Contact) as ContactList
GetMutableEntity(of Contact, ContactID) as Contact
MutableEntityList.Add(of Contact, Contact)
MutableEntityList.Remove(of Contact, Contact)
GetMutableSubEntities(of History) as HistoryList
GetMutableSubEntity(of History, HistoryID) as History
MutableSubEntityList.Add(of History, History)
MutalbeSubEntityList.Remove(of History, History)
That way we could start using those methods for future applications. It occurs to me that I haven't actually tested that to see if MutableEntities has already been extended in that way to all the entities but I think the last time I checked that it hadn't.
10-03-2012 07:53 AM
First and foremost thanks for the feedback.
Yes, the method does expect an EntityID rather than the ID of the subentity, whether it be notes, histories or activities. I'm unsure why the method doesn't have an additional parameter to narrow down the entity that needs to be searched that does seem like it would be more efficient.
There's still an open suggestion to add methods to get the specific sub-entities by their own ID, so in addition to GetNotes(entityID ID) there would be GetNotesByID(noteID ID), there just hasn't been a great deal of demand for it since, as you've done, most folks who've encountered this have developed around it already.
In regards to Add and Remove being added to all the existing lists, I believe the reason this isn't done is because those lists are bound to particular set of critiera, in other words there's a query associated with the objects in the list, if we're able to add and remove objects from the list on the fly, if filter criteria were used it would no longer apply.
10-03-2012 12:23 PM
I know that it would break the filter criteria and we would end up with a list based on the ID but that would still be useful from time to time. There are plenty of cases where ACT! does this already such as selecting a set of contacts and saying lookup selected.
I like efficient solutions and part of the problem is that if I write my own there is a little delay while I'm coming up with the sub entity or sub entity list. End users really do appreciate it when things happen much more quickly.
10-03-2012 02:05 PM
Would it be useful if you could add contacts to the contactlist?
This way you could create your own contactlist from your entityID's
Dim myContactList as act.framewkr.contacts.contactlist
Do while x = 1 to 99
Dim contact as act.framework.contacts.contact
contact = getContactbyID(myGUID)
Then stuff the UI
HostApplication.applicationstate.currentcontactlist = myContactList
I requested to add a method to ADD to the contactlist a few years ago but never got a status.
The ADD method would be useful in many areas, one of them creating a contact list based on the date order of activites. Something ACT 6 used to do.
-- Jim Durkin
10-03-2012 03:22 PM
With regards to the EntityLists implementing Generic List type functionality by introducing an .Add() method, I think there is already precedence within the SDK for a ContactList not having a critieria object; namely the LookupManager.ContactLookup(string,bool,bool) overload. With this overload you can pass in an SQL string but the returned ContactList cannot be narrowed down etc.
In addition to this, the EntityList objects do have a Remove() and RemoveAt() methods, I've never used these I must be honest, but do they affect the Criteria object within the list or if they do not, I would presume that they have logic in place to update the Criteria, so ultimately it is doable and makes the API much more standardised with expectations.
Personally I would prefer if DataLists inherited from GenericLists since they're much nicer to deal with anyway and you could have code like ContactList cList.....return cList.Find(c=>c.FullName=="Chris Huffman"); and compare that to the .Find() for the ACT! DataList which'll only return an index anyway.
10-03-2012 07:46 PM
I agree. It would just be a lot simpler to have an ADD method. You can actually do what you want to do by putting all of the contact ids into a guid aray and then doing a GetContactsByID but I still don't think you can use a non-standard sort. There doesn't appear to be a way in the UI to tell it to use "None:None:None" to sort the contacts on which would theoretically allow us to put them in order by ids and then create the lookup and display them in the order of our id list. I honestly haven't tried it to see if I could turn off the sort criteria with the SDK.
10-03-2012 07:48 PM
DON'T DO IT!!! That Remove method is a DELETE. It will actually delete the contact that you tried to remove from the list (it does remove it from the list of course :-)). Needless to say I've tried it before much to my dismay.
10-04-2012 05:59 AM