This document gives a brief description of most of the GroupWise Object API related defects submitted to GroupWise Engineering by Developer Services during the past several years. The list includes both resolved and unresolved defects. It also includes numerous notes about individual methods and properties found in the Object API.
The list is arranged alphabetically according to Object name. Within each Object is another alphabetically arranged list of the Object's properties and methods. If there have been any submitted defect descriptions or notes that relate to a particular method or property, these descriptions or notes will be listed immediately below the method or property (in no particular order).
The list will always be a work in progress. The intent is to keep it informative and current with input from both Novell and third parties wishing to contribute information.
On Novell's part, information may be periodically inserted regarding any new recently discovered issues. When fixes become available for any unresolved defects in this list, the defect may be updated to inform developers of the fix. Notes may be added from time to time.
Third parties wishing to contribute to this document are encouraged to do so. There is a vast wealth of information regarding the use of the Object API that developers have learned over the years. This information needs to be collected and identified. Hence, any developer wishing to contribute information can click the "Post Comment" button at the bottom of this document and add his/her comment. The contributor should include the object(s) and method(s) that the comment relates to. The comment will then be reviewed by Novell. If accepted, the comment will be inserted into the document. These comments will be labeled "CUSTOMER COMMENT" and dated. Note, however, that there is NO guarantee that these comments will be independently verified by Novell.
Finally, note that this document may not include information about when interface enhancements were made. Developers wishing to find out this information can do so by reviewing the progression of gwoapi.h header files, or look through an Object Browser for the GroupWise Object API type library.
Novell hopes the publication of this document will help all developers quickly determine if there are any known Object API issues in the area of their interest.
WARRANTY DISCLAIMER. This information is provided "AS IS" without any warranties or representations. Novell expressly disclaims any warranties or representations as to the accuracy, currency, or completeness of the contents and disclaims any implied warranties of merchantability or fitness for a particular purpose.
LIABILITY DISCLAIMER. Novell will not be liable for any indirect, special, or consequential damages (including loss of profits, business, or data) which may arise out of or result from the services or use of this information.
Trademarks. Any trademarks referenced in this document are the property of their respective owners. Consult your product manuals for complete trademark information. Internal Use. This information may only be used internally within your organization. The contents are not suitable for use in all situations, and any use by you of the contents is at your own risk. You are responsible for verifying the validity of any information that you use. This information may be updated or modified by Novell at any time, including to correct errors.
Copyright Novell, 2005. All rights reserved.
.NET Access: Defects # 330941 and # 339132: The Object API did not work with .NET. The cause of the problem was a GroupWise issue with the DocumentType2 interface. Fixed in GW 6.0.4 and GW 6.5.1. COM+: NOTE: The Object API has never supported distributed COM, nor are there any plans to support it. Date Data Type: NOTE: If you use Visual Basic, several DATE forms are available. For example, 12/25/2004 8:00:00 AM will work. You can also use 24 hour time. You can invert the date order, as 2004/12/25 8:00:00 AM. You can put # signs around the string. If you are using C++, one way to use dates is to fill out a C SYSTEMTIME structure for the desired date. Then make a call to the SystemTimeToVariantTime C function. This system takes as input a pointer to the SYSTEMTIME structure you created, and returns a pointer to the DATE structure that you can use for the Object API. Drag and Drop: NOTE: There is no drag and drop capability in the Object API. Error Codes: NOTE: There is no document that lists the error codes for the Object API. Those error codes would not be easily gathered. Java Access: The Object API can be accessed by any computer language that supports COM. That does not generally include Java. To use Java you would probably have to use your own COM wrappers, or use some Microsoft flavor of Java. Netware Client Not Required: NOTE: The Object API makes no NDS calls, and hence does not need the Netware Client. Rules: NOTE: The Object API does not include any rules making or reading capability Server usage: NOTE: The Object API cannot run where the POA is running on a Netware server. It can run where the POA is on an NT server (because it requires COM). If you have the POA running on a Netware server, you would need an NT server somewhere to run any ASP server pages. The Object API can run anywhere the ASP server pages can run. Threading: NOTE: The GroupWise Object API should be thread-safe except when going through MAPI providers. It is as Thread Safe as COM/OLE allows. That is why GroupWise exposes the ability to bypass the MAPI address books. NOTE: The GroupWise Object API follows the "Single Threaded Apartment" model. In general, the 3rd party calls CoInitialize in a thread it uses to access the Object API. Any object it receives within this thread must be used only in this thread. Object API objects cannot be passed between different threads. NOTE: A 3rd party can use as many threads as it wants when talking to the Object API. However, there are several gotchas in doing this. First, the Object API was built as a Client side application. It contains many Semaphores and Locks to prevent multiple threads from accessing the GroupWise engine at the same time. These threads can't access the same Object at the same time. Each thread may be locked out as other threads access the GroupWise Engine. Second, updates in one thread will NOT be automatically made in other threads. So, if you open multiple threads with the same user in it, and then add messages using one thread, the other threads will not see the new message until you either call Refresh on the collection, or completely release the objects and reread them. Type Library For Delphi: NOTE: The GroupWise Development team has never published a type library for Delphi. You must load the Object API into Delphi and then build your own type library. Unicode Support: GroupWise does not yet have full Unicode support. The GW 7.0 release has support for Unicode in the following fields: Message body, subject, attachement file names and folder names. Other fields are still limited to the same set of characters that are supported in the GW 6.5 releases. Plans are being made to incorporate full Unicode support in the future. Visual Basic Packager: NOTE: You should not put the gwcma1.dll (Object API DLL) as a dependency. The VB packager only adds gwcma1.dll. It doesn't add the dependencies of gwcma1.dll. It doesn't allow for gwcma1.dll to be put where gwcma1.dll is normally installed. The installation of the Object API needs to be separate from the install of the VB application.
AccountRights: NOTE: The AccountRights collection lets a user know of all users that have proxy rights into a particular account. To find the opposite, to find all of the accounts that I could proxy into, that have given me rights, there is no way to do it. Even the GW client does not alert you when someone grants you proxy rights. The reason is security. (If it happened by accident, you shouldn't be allowed to take advantage of it). The Object API shouldn't give you more rights than the client allows. Defect # 254466: Assume User A granted proxy rights to User B, and User B then proxied into User A's account with the Object API, the value of Account.Proxied = TRUE. If User B then used the Account.AccountRights to see what proxy rights User A had granted him, instead of seeing his own proxy rights User B would see a collection of the rights of all users to whom User A had granted proxy rights. This was an error in the way the Account.AccountRights property had been implemented. The implementation error was corrected by reducing the size of the Account.AccountRights collection for proxy cases so that the collection would only show User B's proxy rights. The correction was made in GW 5.5.5, in GW 6.0, and in GW 5.5 EP SP3 (GW 5.5.5.1). Defects # 294535 and 100293977: If you granted someone specific proxy rights through the GroupWise client, when you used the Object API to view the AccountRights of the other account by proxying to that account, the AccountRights granted were incorrect. Fixed in GW 5.5 EP SP5 (GW 5.5.7.1), GW 6.0.2 and GW 6.5. AddressBookDefaultDisplayNameSort: Defect # 393370, #393371, #393373: You could not add a new address book entry based on display name because there was no way to tell whether the address book accepted first.last or last.first type display names. This property was therefore added to GW 6.5.3, GW 6.5.4, and GW 7.0 Nov, 2004. AllFolders: Defect # 376448, #376524. The Folders collection object lacked a way to refresh the contents. That meant that any changes to the Folders - especially by other programs - were not reflected in the collection. The only way to refresh the collection was to completely exit the program, then relogin. To duplicate: Inside VB .NET, login to the Object API. Loop until the user stopped the test or closed the program on the next instructions. Retrieve the AllFolders collection. Display the Count of the collection. Then delay for a short time. While this program is running, go to another computer and run the GW Client against this same account. Add a new folder to the Cabinet. The All Folders::Count() in the loop never changed. Fixed (9/10/2004) in GW 6.5.3, and in GW 7.0 in July, 2004. AllMessages: NOTE: The AllMessages collection includes all messages that are in the box EXCEPT the trash. This method has always worked this way, and will not change. If someone wants to search the trash, they can retrieve the TrashEntries collection, then use the Find method inside there. ConvertEmailAddress: NOTE: Used to force the correct form of the email address. You can return a user-postoffice-domain form (UPD), and DPU form, or a form after all the addressing rules and other parsing has occurred. However, there isn't a quick way to guarantee a "userID@Internet.Domain style of address is always returned. The Object API doesn't offer a style without a post office. DefaultAccountRights: NOTE: This property corresponds with a user's minimum proxy rights. The property is not accessible for a proxy user. DistinguishedName: NOTE: You cannot access the Account.DistinguishedName property in caching or remote modes. Since the Remote (or caching) database has no connection to the Domain or Post Office databases, there is no way to get the Distinguished Name. FieldDefinitions: NOTE: You cannot creating new field definitions in an Archive account without causing mismatched tags. NOTE: Some customers have mistakenly concluded that you cannot delete field definitions of an Account object. You can delete field definitions of an Account object, but the definitions are deleted in a deferred fashion, and only then when the deleted FieldDefinition object and the entire FieldDefinition collection are released. Make sure these conditions are met. GetArchiveAccount: NOTE: If UserA archives data, and later UserB proxies into UserA's account, UserB cannot access the archived data (either with the APIs or the GW client). Presumably against GroupWise policy. GetSystemAddressBook: Defect # 384831. Fixes for Defects # 383681, 383682 made it so you cannot see hidden address book entries. Defect # 384831 modified this fix so that you "can" see hidden system address book entries, but only by using a trusted application. You have to use set GetSystemAddressBook(TRUE), and you also have to set the MultiLoginAddressBookSupport flag to TRUE. Both fixes made in GW 6.5.3 around Sep, 2004. LastBackupDate: (See LastRetentionDate also) Defect # 358943: Accessing or setting the Account.LastBackupDate property in Online mode caused an error. Fixed in GW 6.5.2 (as long as POA is also upgraded). This property always worked in Caching and Remote modes as well as Path-To-Host mode. NOTE: The LastBackupDate represents the last time someone backed up this account. It was originally set by the GroupWise TSA. The LastRetentionDate is similar, except that it refers to the last time a 3rd party product archived or digested the account. Only 3rd party programs can set this date; the GroupWise TSA knows nothing about retention policies. NOTE: The LastBackupDate and LastRetentionDate values are used to prevent a user from deleting items in their trash folder. A GroupWise administrator may require that a user's data be backed up before they can purge the trash. Once the GW admin has set this flag, the GW engine will not remove items in the trash that were created after the last backup. On the other hand, a GW admin may buy a third party archive solution. The third party product then sets the LastRetentionDate. Similar to the LastBackupDate, an item can not be purged from the trash until it passes the LastRetentionDate. LastRetentionDate: (see LastBackupDate) MergeArchive: Defects # 289845, # 289848 and # 320658: If you merged two archives together that contained messages that were linked to additional folders, those linked messages were duplicated (and hence the count doubled). Fixed in GW 6.5 and GW 6.0 SP3. PathToArchive: Defects # 384912, # 394388 and # 395670: If UserA proxied into UserB's account, and then examined the Account.PathToArchive value expecting to see the path to UserB's archive, he would see the path to his own archive instead. Fixed in GW 6.5.4 (Dec, 04). NOTE: When you use the SetArchiveTo method to reset the archive path to something else, and then read the PathToArchive property, it will show the new value you just set. However, in the GW client, (tools | options | environment), it will still show the old value. Archive paths are not written out and saved. PeekMode: Defect # 387735, #387736. Originally, the PeekMode flag was used only in trusted applications to prevent the Message.Read and Message.Opened flags from being set. This procedure was modified in GW 6.5.3 beginning in Oct. of 2004. Since then, normal accounts (regular Login or MultiLogin) can turn PeekMode on - not just trusted apps. In that mode, the USER_STATUS_DOWNLOADED flag will be set on a message instead of automatically marking the USER_STATUS_OPENED and USER_STATUS_READ flags. By default, Trusted Applications in Peek Mode will also only set the USER_STATUS_DOWNLOADED flag. However, a Trusted Application can specify which flags (or no flags) should be set when they access a message using PeekMode. Fixed in Oct, 2004, in GW 6.5.3. PeekModeFlag: (See PeekMode also) NOTE: This flag was created in GW 6.5 as a result of the change in the behavior of the PeekMode flag described immediately above. It is used within trusted applications. If you use it within a non-trusted application, it will have no effect. (PeekMode controls non-trusted applications). See the NDK documentation for details. ProxyAccounts: NOTE: This collection is simply a list of all the accounts you have proxied into at the same time. If User A logs into his account, and in addition proxies into User B's account and User C's account, then the ProxyAccounts.Count value will be "2". QuickMessages: Defect # 390253. When you attempted to get the QuickMessages collection for Tasks, setting the StartDate to some value and using the egwNewMessages value, you got all the tasks and not just the tasks since the StartDate. Fixed in the GW 6.5.3 version dated Oct. 28, 2004. Refresh: Defect # 401166: Accessing QuickMessages and Account::Refresh from multiple users, each user running in a different thread, causes a hang or crash. Fixed in GW 7.0, Feb. 2005. SetArchiveTo: NOTE: When you use the SetArchiveTo method to reset the archive path to something else, and then read the PathToArchive property, it will show the new value you just set. However, in the GW client, (tools | options | environment), it will still show the old value. Archive paths are not written out and saved. SetPassword: Defect # 281570: The Account.SetPassword method was originally added to GW 6.0 SP1. It was added later to GW 5.5.5 and GW 5.5 EP SP4 (GW 5.5.6.1). SystemAddressBook: Defect # 384831. Fixes for Defects # 383681, 383682 made it so you cannot see hidden address book entries. Defect # 384831 modified this fix so that you "can" see hidden system address book entries, but only by using a trusted application. You have to use set GetSystemAddressBook(TRUE), and you also have to set the MultiLoginAddressBookSupport flag to TRUE. Both fixes made in GW 6.5.3 around Sep, 2004. Defect # 388857: When using ASP.NET, and when the MultiLoginAddressBookSupport flag is set to FALSE, or when you use a normal login (not MultiLogin), you cannot access the SystemAddressBook. You get an error. If you set the flag to TRUE, then after doing the FIND operation in the attached application, it will get an execution error when you use the MyAddBookEntries.Item(MyAddress) call. Defect submitted to GroupWise Development.
Defect # 254466: Assume User A granted proxy rights to User B, and User B then proxied into User A's account with the Object API, the value of Account.Proxied = TRUE. If User B then used the Account.AccountRights to see what proxy rights User A had granted him, instead of seeing his own proxy rights User B would see a collection of the rights of all users to whom User A had granted proxy rights. This was an error in the way the Account.AccountRights property had been implemented. The implementation error was corrected by reducing the size of the Account.AccountRights collection for proxy cases so that the collection would only show User B's proxy rights. The correction was made in GW 5.5.5, in GW 6.0, and in GW 5.5 EP SP3 (GW 5.5.5.1). BitMask: Defects # 294535 and 100293977: If you granted someone specific proxy rights through the GroupWise client, when you used the Object API to view the AccountRights of the other account by proxying to that account, the AccountRights granted were incorrect. Fixed in GW 5.5 EP SP5 (GW 5.5.7.1), GW 6.0.2 and GW 6.5.
NOTE: The AccountRightsCollection lets a user know of all users that have proxy rights into a particular account. To find the opposite, to find all of the accounts that I could proxy into, that have given me rights, there is no way to do it. Even the GW client does not alert you when someone grants you proxy rights. The reason is security. (If it happened by accident, you shouldn't be allowed to take advantage of it). The Object API shouldn't give you more rights than the client allows. Add: NOTE: You must be the owner of the account in order to use this method NOTE: The first argument in the argument list is a VARIANT address. It will not take a string object.
DisplayName: Defect # 356483: In some cases, the Address.DisplayName was returning an email address instead of a display name. This was fixed in GW 6.5.2. EmailAddress: NOTE: Different forms of the EmailAddress property may be returned depending upon how the EmailAddress was accessed. For example, Account.Owner.EmailAddress returns an address of the form User@InternetDomain.com. However, the form of Account.Cabinet.Folder(i). FolderRights(k).Address.EmailAddress is User.DOMAIN.POSTOFFICE@InternetDomain.com. If you need to change forms, use the Account.ConvertEmailAddress method.
NOTE: There is no way to determine who owns a shared address book through the Object API. NOTE: You cannot sort a GroupWise "System" Address Book by domain. You can only sort name, email address, and department. However, you can sort a personal address book by domain, or most anything else. NOTE: The GroupWise engine maintains a small set of items that it will use to notify clients of changes. Currently, Address Books and Categories are not included in those notifications. So, until the GW client is rebooted, the items will not be refreshed. An enhancement request has been submitted to GroupWise Development. FieldDefinition: FieldID NOTE: Field IDs are only valid on Address Book fields. No other field collection or field definitions will return a non-zero field ID. The Address Book field IDs that are returned are the system MAPI property tags associated with each field. If the property is NOT defined by MAPI, then it will not have a value. FieldDefinitions: (See also, FieldDefinitions and Fields objects) Defects # 264621 and # 100271062: Accessing the AddressBook.FieldDefinitions property caused an access violation. Although it appeared to work in GW 5.5 and GW 5.5 EP versions prior to the development of GW 6, it mainly caused a problem in GW 6 Beta 3. This was fixed in GW 6.0, GW 5.5.5, and in GW 5.5 EP SP4 (GW 5.5.6.1). NOTE: There is no limit to the number of fields that can be added to a personal address book. NOTE: CreateDate, LastModificationDate, and PABGuid field definitions were added to the Address Book fields collection in January, 2002 (GW 6.0 SP1). The PABGuid field provides a unique and persistent way of identifying each particular address book entry. In order to use these values, the Account.MultiLoginAddressBookSupport flag must be set to TRUE to eliminate the MAPI layer normally used to access an address book. NOTE: The PABGuid is a unique ID assigned to each entry. There is no guarantee that it will be 128 bytes long. And there is no way to parse that ID. (At least there is no way to parse it for a 3rd party. It is a unique string of bytes that is never duplicated inside this users database.) NOTE: There are restrictions for accessing any Date field, such as the Birthday field. The user must be logged in using the MultLogin call. The user must also set the Account.MultiLoginAddressBookSupport flag to TRUE. If these restrictions are not followed, the Object API can only display the String fields given by the MAPI address book providers. NOTE: If someone is running under MAPI, the Object API will ask the MAPI provider for Field Definitions. Mismatches could occur (with what is seen in the GW client) because the GW client doesn't use the AB Provider to get these fields. In non-MAPI mode the Object API tried to match an earlier version of the System Address Book. However, GroupWise has not updated those fields (as of April, 2005). Fields: Defect # 258800. The organization field in an address book was displaying as blank. Fixed in GW 5.5 EP in Feb, 2001. Defect # 403362. Create a couple of organizational type entries into a personal address book, using the GW client. Give the entries the same name. Then use the Object API to create a new user entry, and attempt to set the field value of the organization field equal to the same name as the other names used previously. The new entry never shows up in the address book. Fixed in Feb, 05, in GW 7.0. Defect # 403192. The Japanese to English conversion of address book fields appeared to be faulty using UNICODE. The relevent GroupWise code was fixed to use unicode functions in Feb, 2005, in GW 7.0. . SortOrder: NOTE: There are restrictions in sorting the entries in a system address book (as opposed to sorting the entries in a personal address book). You can only sort name, email address, and department, and not by other categories such as domain.
Add: Defects # 262754 and 276324: It was possible in some situations to get a GPF after adding an address book entry. This problem was fixed in GW 6.0 SP1, GW 5.5.5, and GW 5.5 EP SP4 (GW 5.5.6.1). Defects # 288185 and # 288306: This code did not act the same way as the Windows Address Book Client namely that when a Company (Organization) is added, the Windows Address Book Client automatically checked to see if an organization by that name existed, and linked the current entry to that organization. If the organization did not exist, then an entry was made for that company. Fixed in GW 6.5 and GW 6.0 SP2. Defect # 393370: You could not add a new address book entry based on display name because there was no way to tell whether the address book accepted first.last or last.first type display names. Therefore, the Account.AddressBookDefaultDisplayNameSort property was added to GW 6.5.3 (11/19/2004). NOTE: When adding large numbers of entries to a personal address book, there will be a slowdown in performance. Defect # 406719: Crash if Delete and Add of ABEntries occurs too fast. To duplicate, add 10 Address Book Entries to the Frequent Contacts address book, then delete those 10 entries. After several iterations (with no chance to refresh), the system will crash with a NULL Pointer exception. Fixed in GW 7.0, March, 2005. Count: NOTE: If you are iterating through all the address book entries in a collection, the AddressBookEntries.Count value may not match the number valid items in the collection. The Count property includes entries where the visibility for the entry is none. However, during the iteration of all entries, non-visible entries are skipped. Hence, always check for empty items when looping through an addressbook entry collection. Another reason is that GroupWise relies on what MAPI reports that may not reflect the true number of entries in the collection. Defect # 384830, #384831. Fixes for Defects # 383681, 383682 made it so you cannot see hidden address book entries. Defect # 384831 modified this fix so that you "can" see hidden system address book entries, but only by using a trusted application. You have to use set GetSystemAddressBook(TRUE), and you also have to set the MultiLoginAddressBookSupport flag to TRUE. Both fixes made in GW 6.5.3 around Sep, 2004. Also fixed in GW 7.0 in Sep, 2004. Find: Defect # 314321: The AddressBookEntries.Find method was returning everyone in the address book, instead of the desired subgroup, when the normal MAPI access layer was eliminated. Fixed in GW 6.0.3 and GW 6.5. Defect # 340028, #351662: If you search for an <E-Mail Address> with the form of "John.Doe@XYZ.Com", with the MATCHES keyword, while in caching mode, no addresses will be found (even though the Online mode works fine, and even though other forms of addresses are found fine in both Online and Caching modes). There may also be additional problems when searching for email addresses if the MultiLoginAddressBookSupport flag is set to TRUE to get rid of the MAPI layer. Defect has been submitted to Development. Defect # 315807: Using the OR keyword in a filter expression did not work. Hence, something like (<First Name> MATCHES John) OR (<Last Name> MATCHES Doe) did not work. Fixed in GW 6.5. Defect # 283915. The AddressBookEntries.Find method worked fine in GW 6 with the August 2001 code, but did not work with the October code for the system address book. Fixed in October (GW 6 SP1). NOTE: The Find method uses a <MyField> MATCHES ... syntax rather than a <MyField, STRING> MATCHES ... syntax like messages use. NOTE: <UserID> only works for Frequent Contacts Book, and not for the System Address Book. NOTE: In the GroupWise client, select Address Book | View | Define Custom Filter | Drop down box to see list of possible fields for each address book. NOTE: Fields are case sensitive. NOTE: The only special characters that can be found through the FIND method are * and ?. Note also that the FIND method can find whole words, but not subsets of words e.g. message but not message. NOTE: To access any date field, like birthday, you must log in with the MultiLogin command, and then set the Account.MultiLoginAddressBookSupport flag to TRUE to eliminate the MAPI layer usually necessary to access the Address Book. If you don't do this, the Object API can only display the String fields given by the MAPI Address Book providers. NOTE: The BEGINSWITH keyword does not function NOTE: To search for a birthday, three birthday fields were added in 2003. Use BIRTHDAY_DAY, BIRTHDAY_MONTH, and BIRTHDAY_YEAR. These statements take the form of a numeric filter expression. For example, (BIRTHDAY_MONTH=4) would find all AddressBook entries with a birthday in the month of April. NOTE: The AddressBookEntries.Find method doesn't work with the "Name" field in the system address book. Defect # 390952, #390953: The Find method did not hide hidden entries. Call to get the new System Address Book Entries collection, which hides the non-visible entries by default. Then call the Find() method. Hidden entries are now visible. Fixed in GW 6.5.3 and GW 7.0, Nov. 2004. Defect #376571. When calling the AddressBookEntries.Find method with a search filter using the PABGuid field, any PABGuid value with "*" or "?" characters would use wildcard searches, which may return one or more hits. Since the PABGuid field contains a variety of unusual characters including * and ?, this was undesirable to find the unique AddressBookEntry that had the PABGuid field. Hence, the Find method was changed in GW 7.0 to return only the one unique entry. Item: Defect # 208771: Prior to GW 6.5, using this method with an Address object argument would cause the method to fail if the email part of the Address object was not in the old UserID.PostOffice.Domain format. After the fix in GW 6.5, the problem was taken care of except for one known case where the Address argument is found initially by using the Account.Owner property (that returns an Address object). In that case, since the Account.Owner property retrieves the Owner display name format (firstname, lastname or lastname, firstname) from the administratively defined ConsoleOne setting, and not from the user defined address book setting in the GW client, the two settings must agree if the AddressBookEntries.Item method is going to work. To work around this limitation if you only have an Account.Owner address object available, get the individual parts of the Address object (email address, display name) to build a filter expression, and then use the AddressBookEntries.Find method. NOTE: If you are iterating through all the address book entries in a collection, the AddressBookEntries.Count value may not match the number valid items in the collection. For example, non-visible entries are skipped. Another reason is the GroupWise relies on what MAPI reports ? which may not reflect the true number of entries in the collection. Hence, when iterating through a collection, and accessing the AddressBookEntries.Item property, check for empty items first. Defect # 383682. Any System Address Book Entry marked with "Visibility None" could still be seen in the Object API. Fixed in GW 6.5.3 (10/1/2004). Defect # 351184, # 380191: The AddressBookEntries.Item method would not take an Address Object argument (even though it is suppose to) IF the initial account login is made using MultiLogin, and the MultiLoginAddressBookSupport flag has been set to TRUE. Fixed in GW 6.5.3, Sep. 2004. Fixed in GW 7.0. Defect # 388857: The AddressBookEntries.Item method will not accept an Address argument using ASP.NET. Submitted to GroupWise Development. Defect # 406108: Calling AddressBookEntries::Item() with an address that contains Name Parts with spaces causes GPF. To duplicate, add an entry to the System Address Book with a First Name or Last Name that has multiple parts. For example, a First Name of :"Tom M" or a Last Name of "Van Horn." Fixed in GW 7.0, March, 2005. Defect # 404005: Calling the AddressBookEntries::Item() method with a valid display name occasionally returns a NULL pointer, but no error. To duplicate: Login to the Object API, turn off MAPI Access to the Address Books, then call to retrieve an Address Book Entry from the Item call using a Display Name. Some entries return a NULL pointer, but no error. Fixed in GW 7.0, Feb. 2005 Defect # 380501: The ABEntries::Item() method failed when called with an Address that has 3 names in the Display Name. For example, in the GW System Address book at Novell, Jay Don Gray will not succeed when passed in as a Display Name. Fixed in GW 6.5.3 and GW 7.0, Dec. 2004. Defect #410259: There was a problem with looking up names if there were spaces in the first or last name and the sort order was by last name. Fixed in GW 7.0 in May, 2005. ItemByGuid: Defect # 376432, #376571. This method was added in GW 6.5.3 (Oct, 04) to search for PabGuid values that contain ? or * marks. If a PabGuid contained one of these marks, and you attempted to search for it using Find, it would do a wildcard search instead. The new method doesn't do that. Also added to GW 7.0
Categories: Defect # 390492, # 395001: There was a crash when you tried to access the AddressBookEntry.Categories object, at least using C. Fixed in GW 6.5.4 (12/2/2004) Delete: Defect # 406719: Crash if Delete and Add of ABEntries occurs too fast. To duplicate, add 10 Address Book Entries to the Frequent Contacts address book, then delete those 10 entries. After several iterations (with no chance to refresh), the system will crash with a NULL Pointer exception. Fixed in GW 7.0, March, 2005. EmailAddresses: NOTE: There is only 1 item in the collection if using the system address book. Defect # 393291: Adding Multiple EMail Addresses to ABEntry loses one address in the collection. Defect submitted to GroupWise Development Fields: (see also Fields object) Defect # 360264, #100353575: The Middle Name and Suffix fields were not available if you had set the Account.MultiLoginAddressBookSupport flag to TRUE. Fixed in GW 6.5.2 and GW 7.0. Defect # 368964: The GUID value returned for a System Address Book entry was 1 byte short. Most GUIDs should be 36 bytes in length. The ones returned from non-MAPI mode were 35 bytes in length. Fix made in GW 6.5.2. Defect # 384856, #378164, #387547: If you logged in using MultiLogin, as opposed to a normal Login, and you accessed certain address book fields, you could not change their values. These fields included, for regular users, the Display Name, Office Web Site, Personal Address, Personal City, Personal State, Personal Zip Code, Personal Country, and Personal Web Site do not update. For an Organization, the Display Name, Web site, and Primary Contact fields can not be changed. For a Resource, the Display Name, Owner, and Type can not be modified. Fixed in October, 2004, in GW 6.5.3, and in GW 7.0. Defects # 400976 and # 402359. A customer read the address field from an address book entry, and then wrote it right back. It was a multiline address. When it was written back, it had an extra CR/LF in it, and hence there was an extra line inserted in the address in the GW client. It only happens when using MultiLogin with the MultiLoginAddressBookSupport flag set to TRUE to eliminate the MAPI layer. Fixed 2/10/2005 in GW 6.5.5. Defect # 403362. Create a new organizational type entry in a personal address book. Create another organizational type entry with the same name. If the Object API is used to access the personal address book, create a brand new entry, and then attempt to set its organization field equal to the same name you called the other two new entries - i.e. "MyOrg". It would cause an error when the attempt was made to Add the new field. Fixed in GW 7.0 on 2/22/2005. Defect # 376049 and # 376050. If using VB.NET to access an Address Book Entries Fields collection, every Field object returned after the 1st AB Entry is accessed has the same values as that 1st AB Entry. Fixed in GW 6.5.3 and GW 7.0 - June 29, 2004. NOTE: The "CreateDate", "LastModificationDate", and "PABGuid" fields were added to the Address Book Fields collection in January, 2002. The PABGuid field provides a unique and persistent way of identifying a particular address book entry. NOTE: The PabGuid is a unique ID assigned to each entry. There is no guarantee that it will be 128 bytes long. And there is no way to parse that ID. (At least there is no way to parse it for a 3rd party). The PABGuid is a unique string of bytes that is never duplicated inside the user's database.) Defect # 380580. Retrieving the Address Book Field "Last Modification Date" resulted in a string that contained the "MM/DD/YYYY HH:MM am" value. This string was missing the Seconds from the time value. This string should read "MM/DD/YYYY HH:MM:SS am". Fixed in GW 6.5.3 in October, 2004. Defect # 378172: The Last Modification Date was only good to the minute. Changed to add seconds in GW 7.0 (Aug, 2004). Defects # 387115, 387116: Using MultiLogin with the MultiLoginAddressBookSupport flag set to TRUE, you could not add an Organization field value to a new address book entry fields list. Fixed in GW 6.5.3 (Oct, 2004). Defect # 376837, #376838. Adding an EMail Address using an ABEntries Fields collection returns an error if the EMail address is "a"; however if it is an "a@" all works. Fixed in GW 6.5.3 (9/10/2004), and in GW 7.0 in July, 2004. NOTE: The Object API added support for the birthday field, and other date fields. However, the user must be logged in using the MultiLogin call. The MultiLoginAddressBookSupport flag must be set to TRUE - although if you don't set it at all it may still be TRUE, depending upon what was last done. Defect # 389876. The Prefix field of a personal address book could not be updated when you used MultiLogin and set the MultiLoginAddressBookSupport flag to TRUE. Fixed in GW 6.5.3 (10/28/04) NOTE: The ObjType values for a group always returned 0. Fixed in GW 5.5.3. Defect #401880. The phone number field didn't show up for organizations. Fixed in Feb, 05 in GW 7.0. NOTE: In non-MAPI mode (i.e. the MultiAddressBookSupport flag is TRUE), a 3rd party is never allowed to modify the Last Modification Time field. Defect # 377164 and # 377175. Unable to find the Birthday field in an address book. Fixed in GW 6.5.3 and GW 7.0 NOTE: When accessing address book entry fields, there is always memory cached by the MAPI address book provider. There are object dependencies also which require that memory for some objects be kept until other objects are released. The loss of memory has been confused at times by some customers as a memory leak. It is not. The memory will be returned when all address book objects are released. Defect # 376522, #376523. Adding an Organization to any Address Book Entry was too slow. Access an AddressBookEntries collection. Add a new ABEntry or edit an existing one. Retrieve the ABEntry Fields collection object. Add an Organization field to this entry. Fixed in Sep, 2004, in GW 6.5.3. Fixed in July, 2004. Defect # 387547: In non-MAPI mode (i.e. the MultiAddressBookSupport flag is TRUE), a 3rd party can not modify or update the Last Modification Time or Primary Contact fields of an Address Book Record. To duplicate: Call MultiLogin to access a GW Account. Set the MultiLoginAddressBookSupport flag to TRUE. Access a Personal Address Book. Read the Address Book Entries collection, then select one Address Book Entry. Now access the Fields collection for this entry. Although the Last Modification Time and (if an Organization or Company Record) Primary Contact fields are present, calling Field->put_Value() to change the field will NOT return an error, but will also not update the field in the database. Fixed in March, 2005, in GW 7.0. Defect # 404367. There was a memory leak of about 200 bytes every time the Fields.Item method is called. This may only occur when the field value is empty. Fixed in GW 7.0 in June, 2005. Defect #387268, #387269: When accessing an Address Book Entry objects Fields collection, certain fields will not update. For Contacts (i.e. individual people), the Display Name, Office Web Site, Personal Address, Personal City, Personal State, Personal Zip Code, Personal Country, and Personal Web Site do not update. For an Organization, the Display Name, Web site, and Primary Contact fields can not be changed. For a Resource, the Display Name, Owner, and Type can not be modified. Fixed in GW 6.5.3 and GW 7.0, Oct. 2004. MAPIEntryID: NOTE: This variable is the unique identifier that a MAPI Address Book provider gives for any entry. You need to use SafeArrayAccessData in C to unlock the VARIANT. ObjType: The ObjType values for a group in an address book always returned 0. This problem was fixed in GW 5.5.3. RevisionNumber: Defects # 291986 and # 291995: When using late binding instead of early binding, the AddressBookEntry.RevisionNumber property was using the earliest intrface version of AddressBookEntry instead of the latest interface (AddressBookEntry3). Since the RevisionNumber property was not introduced until the AddressBookEntry2 interface, using AddressBookEntry.RevisionNumber was resulting in an error. Fixed in GW 6.0.3 and in GW 6.5. Defects # 291992 and # 291996: The AddressBookEntry.RevisionNumber property was not being refreshed properly from within an application. Fixed in GW 6.0.3 and in GW 6.5.
AddEx: Defects # 281327 and # 100273550: When trying to accept a shared personal address book as specified in the first parameter, there was an error message popup indicating a mismatched data type. Fixed in GW 6.0 SP1 and GW 5.5 EP SP4 (GW 5.5.6.1). Note that this method only ACCEPTS shared notifications; it does not allow you to create your own shared notification message. It takes a shared notification from someone else and allows you to accept it and specify a different name if you'd like. NOTE: The memory associated with the address book associated objects, such as AddressBooks, AddressBook, AddressBookEntries, AddressBookEntry, etc., is interconnected with each other. The memory held by one object can sometimes not be released until the memory held by others address book related objects is released. Do not confuse this property with a memory leak.
NOTE: The AllMessages collection has an advantage over Messages collections. It can return more than 5000 messages. The Messages collection is limited to around 5000 (as of 2004). NOTE: This message can be slow when there are large numbers of messages. NOTE: The AllMessages collection includes all messages that are in the box EXCEPT the trash. This method has always worked this way, and will not change. If someone wants to search the trash, they can retrieve the TrashEntries collection, then use the Find method inside there. NOTE: To search for a custom field, use angle brackets. For example, to search for a custom field in a message, use <MyCustomField, STRING> MATCHES whatever. Find: Defect # 405404: If you search for messages with more than a certain number of recipients, using the TOTAL_RECIPIENTS key, and then access these messages and look at the number of recipients in each message, there is a discrepancy. The number of recipients (Message.Recipients.Count) includes the TO and CC recipients, and not the BC recipients. However, when the AllMessages.Find operation is used with a TOTAL_RECIPIENTS >= X filter, it finds TO, CC, and BC recipients. Hence, you can find messages that show more than X recipients, and when it is printed out using Recipients.Count, it shows less than X. It appears that the filter is not working properly. Defect has been submitted to GroupWise Development. Defect #373436: Using the TOTAL_RECIPIENTS keyword in a filter gives an error. The fix is to be made in GW 7 SP1. NOTE: When you search on GW.MESSAGE.MAIL classes, such as using GW.MESSAGE.MAIL.MYTYPE in a filter, note from the NDK documentation that you can only search on the custom part of the message class (MYTYPE).
NOTE: In Visual Basic, CreateObject(NovellGroupWareSession) will always create an Application object, not an Application2, Application3, etc. object. The code underneath will not automatically convert the Application object to one of these later objects. You need to do this yourself. For example, in Visual Basic, if MyApp is dimensioned as an Application object, and MyApp3 is dimensioned as an Application3 object, then after setting MyApp = new Application, you can set MyApp3 = MyApp and access the properties of the Application3 object. Login: Defect # 303693: When either the Application.MultiLogin or Application.Login methods were called, a spinning world or splash screen was briefly displayed. Fixed in GW 6.5. The splash screen no longer appears. Note that the /bl switch for disabling the splash screen, documented in the GroupWise help under command line switches, is only valid for the GroupWise Windows Client, and not valid for the API. NOTE: To set the password using the second argument, use /pwd = mypassword NOTE: It is better to use the Application.MultiLogin command when you are using an NT service. The MultiLogin command has no interfaces. If you use an NT service with either the Login or MultiLogin commands, use the /ntservice switch in the second argument. NOTE: If GroupWise is up and running, you can use the Login method without any arguments. Even if arguments are supplied, they will be ignored. If GroupWise is not up, you can still often use this method without arguments if you have logged into GroupWise previously. In this case, GroupWise will search in other places for any information not found in the login command. It will search first in eDirectory (assuming you have the the Netware Client installed), then the registry, and finally an DNS lookup of the IP address. If you want to login to GroupWise as a second user (or use the MultiLogin command), you must at least supply the UserID. The necessity of a password depends upon the default security level set for the post office, and upon the password options set for each user. Once the user sets a password, the mailbox is high security regardless of the security settings of the post office. NOTE: It is possible to log into the wrong account if some background process is running such as Notify, GWSync, HotSync, Outlook, or some other process. You can't log into GroupWise with the Object API using only the wphost.db post office database. The WPHost database is only used by the MTA and POA as a list of authorized users. To login using the Object API, you also need the user's database (USERFID.DB), the guardian, and a possible host of other databases. Defect # 394054, #394587. The Object API Login method was expanded to return the UserID and Mode (Online, Caching, etc) when these values were not supplied to the Login procedure. Fixed Jan. 24, 2005 in GW 6.5.4, and in GW 7.0. NOTE: The Application.MajorVersion and Application.MinorVersion refer to the Object API version, and not the GroupWise version. The Object API versions are updated independently of the GroupWise version updates. Defect # 404303. GroupWise Development changed the version numbers so that they now reflect current GW shipping status with Major and Minor version numbers. Effective March 1, 2005, in GW 7.0. NOTE: There is no equivalent "Logout" method. In VB, set any objects to Nothing to release memory. Defect # 309168: The Login was too slow due to accessing SSL certificate. Fixed in GW 6.5, Oct. 2002. SSL access performance improved. MajorVersion: NOTE: The Application.MajorVersion and Application.MinorVersion refer to the Object API version, and not the GroupWise version. The Object API versions are updated independently of the GroupWise version updates. Defect # 404303. GroupWise Development changed the version numbers so that they now reflect current GW shipping status with Major and Minor version numbers. Effective March 1, 2005, in GW 7.0. There are also new BuildNumber and VersionRevision properties of the Application object. MinorVersion: (see MajorVersion) MultiLogin: Defect # 303693: When the Application.MultiLogin method was called, a spinning world or splash screen was briefly displayed. Fixed in GW 6.5. The splash screen no longer appears. Note that the /bl switch for disabling the splash screen, documented in the GroupWise help under command line switches, is only valid for the GroupWise Windows Client, and not valid for the API. NOTE: Use of the MultiLogin command can lead to problems when multiple users try to access address books through the normally present MAPI layer. The problem exists because MAPI can only access one address book at a time. If you wish to access more than one address book, get rid of the MAPI layer by setting the Account.MultiLoginAddressBookSupport flag to TRUE. NOTE: This command has no interfaces, and hence is preferred over the Login command when used with an NT service. If you use an NT service, use the /ntservice switch in the second argument. NOTE: The MultiLogin command may fail if not used properly with trusted applications. A possible reason includes inappropriate setting of the Requires SLL flag when creating the trusted application key and restricting the trusted application to one machine. NOTE: If you use MultiLogin without an IP address (as the second argument), it will error if the account you are logging into is not using the same TCP/IP address as the last account you logged into using the GW client. In addition, when you supply no IP address, would happens in your application may depend on what is in the registry. Look at HKEY_CURRENT_USERSoftwareNovellGroupWiseLogin Parameters. There are multiple entries that determine where GroupWise / OAPI application logs in (online, cache, etc). NOTE: If you are calling MultiLogin in a loop using the C language, make sure that CoCreateInstance and CoInitialize are called outside the loop. Otherwise, a few handles may not be deallocated from memory on each loop. Defect # 394054. The Object API MultiLogin method was expanded to return the UserID and Mode (Online, Caching, etc) when these values were not supplied to the Login procedure. Fixed Jan. 24, 2005 in GW 6.5.4. NOTE: A couple of main reasons for a MultiLogin failure, after setting the SetTrustedApplicationCredentials item for a Trusted Application, includes setting the Requires SLL flag, and then not using SSL encryption for the connection between application and POA. Also, an administrator can restrict a Trusted Application to one Client machine using the TCP/IP address. Proxy: Defect # 100257123: You could not proxy into a mailbox on another post office. Fixed in GW 5.5.5, GW 5.5 EP SP3 (GW 5.5.5.1) and GW 6.0 NOTE: If User A archives data, and User B proxies into User A's account, User B cannot access the archived data. This is by design. NOTE: In order to proxy to another account, make sure a POA is running for every post office involved, and the GroupWise client or Object API must be running against that post office. Direct mode (path-to-host) won't work. NOTE: You can't proxy into someone's account unless you have first logged into the main account using Login. If you use MultiLogin, and then try and proxy into someone's account, it won't work. Proxies are allowed only from the Main user - not from a MutliLogin user. Defect # 342745: There may be problems when trying to proxy into an account with over 5000 records. Defect submittted to GroupWise Development. ProxyHistory: NOTE: This collection is similar to the list you see when you click on the proxy button at the bottom left of the GroupWise client. It is a list of accounts that you have proxied into at one time. To be included in the list, an account must have granted you proxy rights at one time, you must have actually used those proxy rights, and then refreshed the GroupWise client. NOTE: Since the ProxyHistory is a property of the Application object and not the Account object, you cannot log into various accounts using a trusted application and expect to see a unique ProxyHistory for each account. Instead, the ProxyHistory will remain the same, and will be equal to the proxy history of the account you originally logged into using the Login command.
Accept: Defect # 371847, 412668, 412669: If UserA has the client options set to receive notifications when an appointment is accepted, and he sends out an appointment to UserB, and UserB accepts the appointment via the Object API - then UserA will receive back "2" notifications rather than 1 when the appointment was accepted. If UserB had accepted the appointment via the GW client, only 1 notification would have been sent to UserA. Defect fixed in GW 7.0 and GW 6.5.5 in May, 2005. AlarmTime: NOTE: The AlarmTime property in the Object API actually reads a time after midnight. Thus, if you use the GroupWise Client to set an alarm time of 15 minutes before an appointment, the Appointment.AlarmTime property will read 12:15 a.m. The user must adjust accordingly. Defects # 346982, #348573 and # 365350: When an appointment alarm was disabled in the GroupWise 6.5 Client, the Object API Appointment.AlarmTime value did not change. Thus, in the note above, the AlarmTime value would remain at 12:15 a.m. (This was not a problem with GW 6.0.4) Fixed in GW 6.5.2 and GW 7.0 in Nov, 2004. AutoDate: Defects # 391293, # 391278. You could not create a personal autodate appointment. You can now do so. To do this, do not create any recipients. Fill in the StartDate value, and then use the DraftAutoDates.Add method to add any other dates for the appointment. Fixed in GW 6.5.3 and GW 7.0. AutoDateMessages: Defects # 391296, # 391297, #391226. If you located a single Appointment object, and asked for the AutoDateMessages collection, the pointer would be returned as NULL, meaning no Autodates existed for the object. No error message was returned; not even a warning was given. The fix was to return an S_FALSE warning along with the NULL pointer. Fixed in GW 6.5.3 (11/5/2004), GW 6.5.4 (11/5/2004), and in GW 7.0. BusySearchResult: Defect # 322286: A memory leak occurred when accessing the Busy Search elements of a draft Appointment. Fixed in GW 6.5. CommonMessageID: NOTE: The CommonMessageID property was added in November of 2002 to GW 6.5. This Message ID will have the same value across all Post Offices. However, this property was never added to the Query or Find parser. Hence, it cannot be searched on across post offices. The property can be used for all the message types (see individual message types in documentation) - but not for the parent Message object. StartDate: NOTE: If the Appointment object came as a return value from the Messages.Add method, dimension the object as an Appointment2 or Appointment3 object, and not as an Appointment object.
NOTE: To get the size of a file attachment, you must first save the attachment to disk. NOTE: A 3rd party can not change anything about an attachment. For example, you must get the original message to set the Read flag. NOTE: Messages sent with an attachment but no text in the message body caused a problem if sent through GWIA. The attachment may be truncated )missing). Fixed in GW 6.0.3.: Source# = 497 Message: NOTE: You cannot access the text of a MIME attachment message via the Object API. Save: Defect # 377638: When downloading attachments to a Caching or Remote system, the GW code can be set to limit the pieces that are downloaded, including not downloading any attachments above a certain size. If the attachment is not downloaded, the GW client will show the attachment as a grey icon. In such cases, the Object API reads this attachment record, then outputs only the size of the greyed out (ghosted) attachment (one byte). To save the attachment properly, it must be downloaded first. Defect submitted to GroupWise Development to change this behavior.
Defect # 100266876: If you accessed a message type attachment from a non-GroupWise user, there was an error. Fixed in GW 6.0.1 and GW 5.5 EP SP4 (GW 5.5.6.1) Add: Defect # 350712, #351101: A user was able to add an attachment to a received message using the Attachments.Add method. This was contrary to GroupWise policy. Fixed in GW 6.5.2. A user can no longer add an attachment to a received message. Fixed also in GW 7.0. Defect # 363447, #363449: You could not add a message type attachment to a new draft message if the message type attachment was currently attached to some other message. Fixed in GW 6.5.2 and GW 7.0. Defects # 250082 and # 100267093: You could not add a Message object as an attachment to a message. Fixed in GW 5.5.5, GW 5.5 EP SP4 (GW 5.5.6.1) and GW 6.0.1. Defect # 325705: The Attachments.Add method can take a Message object as an argument. When the message object is found through the Object API, the Attachments.Add(MsgObject) seems to work fine. However, when the message object is found through the client state of a C3PO, it does not work. You get an error message saying the "Description Class does not support Automation or does not support excepted interface." Defect submitted to GroupWise Development. NOTE: If you add an attachment called text.htm, GW 6.5 will recognize it as the HTML part of the message and display it properly. This gives the capability to send HTML formatted messages with the Object API. NOTE: You cannot use the Attachments.Add property to add a message object if the message object has been archived. You can probably use the Message.Archived = FALSE method to unarchive the message first. Defect #325705: When you use a C3PO to get the ClientState.SelectedMessages collection, a then get a specific message in that collection, and then try to add that message to a collection of attachments using the Attachments.Add(Message) function of the Object API, an error resulted saying the "Description Class does not support Automation or does not support excepted interface." - Fixed in GW 7.0, May, 2005. Count: Defect # 281451: In some circumstances, the Attachments.Count value was being returned as zero even though there was an embedded attachment. Fixed in GW 6.0 SP1.
NOTE: As long as a program can log into GroupWise, using the Object API, it should be able to use the BusySearch capability. It should work across post offices and domains. NOTE: It will not work if you are trying to search someone's schedule over the internet, unless their MTA is outside their firewall and they are using the GroupWise Enhancement Pack or above (like GW 6 and GW 6.5), or unless a small hole is poked in the firewall. A GroupWise user (or a third party application using the Object API) is given a specific TCP/IP address to use during the GW login. This TCP/IP address is visible outside the firewall. When this TCP/IP address is hit, it redirects the request to the proper POA inside the firewall. When the POA responds, it responds to the internal TCP/IP address, which then redirects the traffic to the original user. NOTE: There is no way to determine what a person's "regular" work schedule is. The GroupWise Windows Client does have settings to determine those hours. However, the Object API has never given out settings.
Completed: Defect # 351423, #351431: The BusySearchElement.Completed flag only returned FALSE. Fixed in GW 6.5.2 and GW 7.0 (Ooct, 2003).
NOTE: Category changes are seen only after refreshing the GroupWise client. Defect # 353542: Problem reported that if an application is accessing the Categories collection for an address book entry, and then when finished the application uses the same Categories collection variable name to access a Categories collection of a second address book entry, without first setting the Categories collection to nothing (in VB, to get rid of memory used for the first collection), the application may not reset the Categories collection object to the new values. It may still be using the old ones. Whether or not this problem is seen may depend on the order that the entries are accessed. It may also depend on the workstation. Defect closed by engineering since the correct approach, and workaround, is to set the Categories collection object to nothing after each use. Item: Defect # 344748: Using the Categories.Item method resulted in a runtime error if the category was a predefined category (like Personal, Urgent, etc.). Fixed in GW 6.5.2 Defect # 405939, #407397. After deleting all the categories of an address book entry, when you add one of these back in, you can no longer access the categories.item value, or set the category.primary value. Fixed in GW 7.0 on March 15, 2005, and GW 6.5.5 in April, 2005. Release: Defect # 390487, Defect # 394830: Calling the Categories.Release method caused a crash if you deleted a customer category first. Fixed in GW 6.5.4 (12/1/04)
Defect # 374267, #380259. Category information was being left out when you cloned a message using the Message.Clone method. It was added in GW 6.5.3, Aug. 19, 2004. Fixed in GW 7.0, Dec. 2004. NOTE: The GroupWise engine maintains a small set of items that it will use to notify clients of changes. Currently, Address Books and Categories are not included in those notifications. So, until the GW client is rebooted, the items will not be refreshed. An enhancement request has been submitted to GroupWise Development.
Defect #335734: Refresh problem with creating new Category Definition objects through the Object API. If you create a new Category Definition object through the Object API, and assign it a color, you will not be able to see any color changes in mailbox items until you refresh the GroupWise client. Submitted to GroupWise Development.
Defect # 405895: Program locks up when accessing Category Definitions from multiple threads. Fixed in GW 7.0, March, 2005. Count: Defect # 358762: On some accounts, even though all the Category Definitions were deleted in an account, the CategoryDefinitions.Count value was still greater than 0. If you tried to access one of them in a loop by finding its name, the application would crash. Fixed in GW 6.5.2 and GW 7.0. Defect # 362909: The CategoryDefinitions object did not list all the pre- defined categories in the Feb 26 version of GW 6.5 SP2. Fixed in the March 11 version of GW 6.5.2.
Additional Rights: Defects # 265559, #265779. There was a memory allocation error (overwriting the memory buffer) when using this property. Fixed in GW 6.0 SP1 (April, 2001). Also fixed in GW 5.5 EP SP4 and in GW 5.5.5.
Defects # 265559 and # 265779: There was a memory allocation error when using Object API applications dealing with the DocumentAccessRights object. This error was corrected in GW 6.0 SP1, GW 5.5 EP SP4 (GW 5.5.6.1) and in GW 5.5.5. Delete: NOTE: You need to set the DocumentAccessRights.RevokeAllRights to FALSE before you can use the Delete method.
Next: Defect # 374971: Under certain conditions, the DocumentIterator.Next property may sometimes say that no document exists, even if it does. It always seems to work fine if you do something unrelated first, like call DocumentLibrary.GetDocument. Submitted to GroupWise Development.
NOTE: A document library can reside on any post office. The Object API makes calls to the Document Management engine, and then the Document Management engine calls the POA responsible for the library to fulfill certain requests. If the POA goes down for a certain PO, an error will result when you try to access a property of a particular document in the library where it resides. It doesn't matter if you log in using TCP/IP or Path-To-Host. NOTE: If the GW client is operating in caching mode and a document is requested, the GW client actually goes online to retrieve the document. Once the GW client has retrieved the document, the Object API can probably also get at that document. But if the document has not been retrieved by the GW client, the Object API has no way to go get it from the online system.
Document: NOTE: If someone else shares a folder with you, and you access a document reference in that folder, beware that you have rights to the associated document. You may not be able to access it otherwise.
Add: Defects # 215091: If you created a new document of some unidentified document type, even though that document type did not exist, and then used the Documents.Add method to add the document, it would accept the document fine. It should have only accepted valid document types. Fixed - early version of GW 5.5.
Defects # 330939, # 330941 and # 339132: The DocumentType2 interface was not installed in the registry. This prevented proper access to the Object API using .NET. Fixed in GW 6.0.4 and GW 6.5.1.
Defects # 278092 and #100272898. The Object API was used to copy the Query.Expression filter from one Query Folder, and use the same filter on another folder. It included a reference to the Official Document Version. After doing so, an extraneous 65536 was introduced into the expression syntax for the Document Version. It also unchecked the "Find only official document versions" check box in the client, which it should not have done. Fixed in GW 5.5 EP SP4 and in GW 6 in Sep, 2001.
BodyTextState: Defect # 271003: Suppose you used Hit the Road in the GW client to download only the subject line of messages. The Object API would report incorrectly that for some messages, the body text was downloaded. This error was fixed in GW 5.5.5, GW 5.5 EP SP4 (GW 5.5.6.1) and in GW 6.0.
Value: Defects # 287066, # 287084, and # 100276179: Custom message field values, when accessed through a C3PO, were not refreshed properly. You had to shut down GroupWise before the values were refreshed. Fixed in GW 6.0.2 and GW 6.5. Defect # 387547. In non-MAPI mode (i.e. the MultiAddressBookSupport flag is TRUE), a 3rd party could not modify or update the Primary Contact fields of an Address Book Record. Fixed in GW 7.0 (March, 2005). NOTE: In non-MAPI mode (i.e. the MultiAddressBookSupport flag is TRUE), a 3rd party is never allowed to modify the Last Modification Time field. (Using Field.Value) Defect # 258800. The organization field in an address book was displaying as blank. Fixed in GW 5.5 EP in Feb, 2001. Defect # 380580. Retrieving the Address Book Field "Last Modification Date" resulted in a string that contained the "MM/DD/YYYY HH:MM am" value. This string is missing the Seconds from the time value. This string should read MM/DD/YYYY HH:MM:SS am". Fixed in GW 6.5.3 in October, 2004. Defect # 389876. The Prefix field of a personal address book could not be updated when you used MultiLogin and set the MultiLoginAddressBookSupport flag to TRUE. Fixed in Oct, 2004, in GW 6.5.3. Defect # 400976, # 402359. A customer read the address field from an address book entry, and then wrote it right back. It was a multiline address. When it was written back, it had an extra CR/LF in it, and hence there was an extra line inserted in the address in the GW client. It only happens when using MultiLogin with the MultiLoginAddressBookSupport flag set to TRUE to eliminate the MAPI layer. Fixed in GW 6.5.5 in Feb, 2005, and in GW 7.0 in March, 2004.
Delete: NOTE: This method was designed to work for field definitions of messages and documents, but not for address books. Do not use it for deleting address book field definitions. Address book field definitions cannot be deleted. NOTE: Some customers have mistakenly concluded that you cannot delete field definitions of an Account object. You can delete field definitions of an Account object, but the definitions are deleted in a deferred fashion, and only then when the deleted FieldDefinition object and the entire FieldDefinition collection are released. Make sure these conditions are met. FieldID: NOTE: Field Ids are only valid on Address Book fields. No other field collection or field definitions will return a non-zero field ID. The Address Book field Ids that are returned are the system MAPI property tags associated with each field. If the property is NOT defined by MAPI, then it will not have a value.
Add: Defects # 284447 and # 287188: A problem would occur if you did the following: 1) create a new custom field definition for an archive account of a numeric or date type, and 2) add some field values with the appropriate data for some record. If you then go into the GroupWise client and try to unarchive the record, you got a C00C error. Fixed in GW 6.5. The fix was not put into GW 6, GW 5.5 EP, or GW 5.5. NOTE: Adding a field definition to one personal address book adds it to all personal address books. This is by design. You cannot add a field definition to the system address book using this method. NOTE: You cannot create a field definition for a document library. NOTE: There is no limit to the number of field definitions that can be added to a personal address book. NOTE: You cannot creating new field definitions in an Archive account without causing mismatched tags. NOTE: CreateDate, LastModificationDate, and PABGuid field definitions were added to the Address Book fields collection in January, 2002 (GW 6.0 SP1). The PABGuid field provides a unique and persistent way of identifying each particular address book entry. In order to use these values, the Account.MultiLoginAddressBookSupport flag must be set to TRUE to eliminate the MAPI layer normally used to access an address book. NOTE: The PABGuid is a unique ID assigned to each entry. There is no guarantee that it will be 128 bytes long. And there is no way to parse that ID. (At least there is no way to parse it for a 3rd party. It is a unique string of bytes that is never duplicated inside this users database.) NOTE: There are restrictions for accessing any Date field, such as the Birthday field. The user must be logged in using the MultLogin call. The user must also set the Account.MultiLoginAddressBookSupport flag to TRUE. If these restrictions are not followed, the Object API can only display the String fields given by the MAPI address book providers. NOTE: If someone is running under MAPI, the Object API will ask the MAPI provider for Field Definitions. Mismatches could occur (with what is seen in the GW client) because the GW client doesn't use the AB Provider to get these fields. In non-MAPI mode the Object API tried to match an earlier version of the System Address Book. However, GroupWise has not updated those fields (as of April, 2005).
Defects # 258800 and # 100256023: The Organization field of an address book was not displaying correctly. If you set it to a new value using the Object API, the GW client would not show the new setting. It would either display a blank, or the old value. The defect was fixed in GW 5.5 EP SP3 (GW 5.5.5.1) and in GW 6.0 SP1. Defect # 360264, #100353575: The Middle Name and Suffix fields were not available if you had set the Account.MultiLoginAddressBookSupport flag to TRUE. Fixed in GW 6.5.2 and GW 7.0. NOTE: When dealing with message, address book, and document fields, the Fields.Count value will be 0 for all system defined field definitions. For custom fields, you must fill out a field value in order for it to be included in the count or collection. Defect # 384856, # 378164, # 387547: If you logged in using MultiLogin, as opposed to a normal Login, and you accessed certain address book fields, you could not change their values. These fields included, for regular users, the Display Name, Office Web Site, Personal Address, Personal City, Personal State, Personal Zip Code, Personal Country, and Personal Web Site do not update. For an Organization, the Display Name, Web site, and Primary Contact fields can not be changed. For a Resource, the Display Name, Owner, and Type can not be modified. Fixed in October, 2004, in GW 6.5.3, and GW 7.0. Defects # 400976 and # 402359. A customer read the address field from an address book entry, and then wrote it right back. It was a multiline address. When it was written back, it had an extra CR/LF in it, and hence there was an extra line inserted in the address in the GW client. It only happens when using MultiLogin with the MultiLoginAddressBookSupport flag set to TRUE to eliminate the MAPI layer. Fixed 2/10/2005 in GW 6.5.5. Defect # 403362. Create a new organizational type entry in a personal address book. Create another organizational type entry with the same name. If the Object API is used to access the personal address book, create a brand new entry, and then attempt to set its organization field equal to the same name you called the other two new entries - i.e. "MyOrg". It would cause an error when the attempt is made to Add the new field. Fixed in GW 7.0 2/22/2005. Defect # 376049 and # 376050. If using VB .NET to access an Address Book Entries Fields collection, every Field object returned after the 1st AB Entry is accessed has the same values as that 1st AB Entry. Fixed in GW 6.5.3 and GW 7.0 - June 29, 2004. NOTE: The LastModificationDate (non-MAPI mode) is created based on a string in the GroupWise Language Resource file. The format of that string can change, based on the country you are in. For the United States, the format is MM/DD/YYYY HH:MM:SS am/pm. It will be given in the timezone of the machine running the Object API. It is not in the timezone of the POA. The 3rd party does not have to worry about adjusting it to GMT. The answers do not change based on whether you are running in direct mode or TCP/IP. Defect # 378172: The Last Modification Date was only good to the minute. Changed to add seconds in GW 7.0 (Aug, 2004). NOTE: There are restrictions for accessing any Date field, such as the Birthday field. The user must be logged in using the MultLogin call. The user must also set the Account.MultiLoginAddressBookSupport flag to TRUE. If these restrictions are not followed, the Object API can only display the String fields given by the MAPI address book providers. NOTE: To search for a birthday, three birthday fields were added in 2003, BIRTHDAY_DAY, BIRTHDAY_MONTH, and BIRTHDAY_YEAR. Defect # 401880. For an organizational type address book entry, the phone number may be blank or it may show up as an office phone number, depending upon how it was entered. Fixed in GW 7.0 in Feb., 2005. Add: NOTE: You are allowed to add a custom field to a received message. This will allow third parties to determine if they have processed the message. It would also allow third parties to add new features to the product. Defects # 287066, 100276179: This method failed to permanently reset custom field values. When used within the Execute function of the Open Command of a C3PO, immediately after calling the Fields.Add method it would appear to set the new field value, but the value of the field would revert back to the original value after the application had run. Fixed in GW 6.0.2 (2/13/2002) and GW 6.5 (9/17/2002). Defects # 387115, 387116: Using MultiLogin with the MultiLoginAddressBookSupport flag set to TRUE, you could not add an Organization field value to a new address book entry fields list. Fixed in GW 6.5.3 (Oct, 2004). Defect # 376522, #376523: Using MultiLogin with the MultiLoginAddressBookSupport flag set to TRUE, it took too long to add an Organization field value to the field collection of any existing or new address book entry. Fixed in GW 6.5.3 and GW 7.0 (Jul, 2004). Defect # 403362. Create a couple of organizational type entries into a personal address book, using the GW client. Give the entries the same name. Then use the Object API to create a new user entry, and attempt to set the field value of the organization field equal to the same name as the other names used previously. The new entry never shows up in the address book. Fixed in Feb, 05, in GW 7.0. Defect # 353456: If you try to add a field value to a message that is a string, and that string contains a CR/LF pair, it doesn't show up in the GW client for GW 6.5.1 and afterward. It used to show up for GW 6.0. Defect submitted to GroupWise Development. NOTE: Users may notice a memory loss that occurs when using the Fields.Add method with various arguments. For example, if you start out with a brand new personal address book, with no entries in the book, and start adding entries, the apparent memory loss per entry gets larger the more entries you add. The time it takes to add an entry also slows down. The reason is that in the Object API, GroupWise has dependencies where it needs to hold on to all dependent objects until all of the dependencies are released. Hence, there is no memory leak, but rather a temporary holding of memory until all dependent objects can be released. Much of this memory dependency is caused by MAPI. The MAPI address books need to hold on to the data until they are released. (Because of some architecture dependencies, the Account object holds on to the MAPI provider until the Account object can be released. The Account object can't be released until the Session/Application object can be released. As a workaround, use the non-MAPI (internal / GroupWise) address books. Or, logout and login in occasionally to free the objects. Defect # 376837, #376838: Adding an EMail Address using an ABEntries Fields collection returns an error if the EMail address is "a"; however if it is an "a@" all works. Fixed in Sep, 2004, in GW 6.5.3. Fixed in GW 7.0 in July, 2004 Defect #387268, #387269: When accessing an Address Book Entry objects Fields collection, certain fields will not update. For Contacts (i.e. individual people), the Display Name, Office Web Site, Personal Address, Personal City, Personal State, Personal Zip Code, Personal Country, and Personal Web Site do not update. For an Organization, the Display Name, Web site, and Primary Contact fields can not be changed. For a Resource, the Display Name, Owner, and Type can not be modified. Fixed in GW 6.5.3 and GW 7.0, Oct. 2004. Count: NOTE: For messages, the count value will be "0" for all system defined field definitions, such as "from", "subject", etc. For custom defined field definitions, you have to fill out a field entry before count will be incremented. The message object has no field definition because these field definitions are accessed through the Account object. For Address Books, the count property only includes those custom fields that have a value. Item: Defect # 404367. There was a memory leak of about 200 bytes every time the Fields.Item method is called. This may only occur when the field value is empty. Fixed in GW 7.0 in June, 2005. Fixed in GW 6.5.5 in July, 2005. Defect # 377164 and # 377175. Unable to find the Birthday field in an address book. This was done using MultiLogin and setting the MultiLoginAddressBookSupport flag to TRUE. Fixed in GW 6.5.3 and GW 7.0
Expression: (covers Filter Syntax used in a variety of places, such as Query: Expression, Messages.Find, MessageList.Find, AddressBookEntries.Find, etc) Defect # 313546: There was no ability to search on task priority or category. Added in GW 6.5. NOTE: Even though the CATEGORY keyword is a string keyword, it can only be used with the MATCHES operator. It cannot be used with the CONTAINS, BEGINSWITH, or DOESNOTCONTAIN operators. NOTE: To search for text within documents, use ANY_FIELD in the filter expression. The type of document can make a difference in the success of the search. NOTE: There is no ability to search on special characters, such as punctuation characters. For GroupWise, this is working as designed. Also, you cannot search on partial words. NOTE: The only date field in any database index is the StartDate for a task, appointment, or reminder note. All other dates have not been included in the GroupWise database indexes. That means that searches on other dates, such as LastModificationDate, will be slower. So issuing a Query or Find or a normal Messages or MessageList collection must also read every record in the database, looking for a match. Defects # 269413 and # 269800 (CPR). Use the Object API to acess a Find Results folder, and check on its Query.Expression syntax. There was a double "AND". Fixed in GW 6 (7/10/01) and in GW 5.5 EP SP4 and in GW 5.5.5. Defect # 270633 and Defect # 100272515: The Query.Expression of the Object API was not being parsed correctly. Some parentheses were taken out. Fixed in GW 6 by Aug 31, 2001. Fixed in GW 5.5 EP SP4. Defect # 278092. The Object API was used to copy the Query.Expression filter from one Query Folder, and use the same filter on another folder. It included a reference to the Official Document Version. After doing so, an extraneous 65536 was introduced into the expression syntax for the Document Version. It also unchecked the "Find only official document versions" check box in the client, which it should not have done. Fixed in GW 5.5 EP SP4. Fixed in GW 6 in Sep, 2001. Defect # 278524. When you set librarian rights in the client for a Query Folder, this filter is not reflected in the Query.Expression (doesn't see SEARCH_AS_LIBRARIAN added to existing Query string.). Fixed in GW 5.5 EP SP4. Fixed in GW 6 in Sep, 2001. NOTE: The AddressBookEntries.Find method does not allow the use of the BEGINSWITH keyword. NOTE: The <> syntax works for both system defined fields and custom defined fields. The AddressBookEntries.Find syntax uses only string fields (<MyStringField> whereas for messages you must supply the type also <MyStringField, STRING>. To search for a custom field, use angle brackets. For example, to search for a custom field in a message, use <MyCustomField, STRING> MATCHES whatever. NOTE: When you use DOESNOTCONTAIN in a filter for use in the Query object, to search on a custom field for messages, it will return everything. This functionality has never been implemented for custom fields. NOTE: You should only use the NOT operator for UNARY keywords, and not for strings, enumerations, etc. NOTE: The only Date field in any database index is the Start Date for a Task, Appointment, or Reminder Note. All other dates have not been included in the GroupWise database indexes. That means that searches on LastModificationDate or other dates will be slower. So issuing a Query or Find on a normal Messages or MessageList collection must also read every record in the database, looking for a match. NOTE: When you create a filter with a date, like CREATE_DATE = something, you can't specify hours and minutes and not seconds. You must specific the entire time. NOTE: Field names are language specific. You need to identify the local name correctly for a specific language version of GroupWise. NOTE: To search for a custom field, use angle brackets. For example, to search for a custom field in a message, use <MyCustomField, STRING> MATCHES whatever. Defect # 340028. If you use the AddressBookEntries.Find method in caching mode with a syntax of <E-MailAddress> MATCHES "first.last@roadkill.com" (with first name, period, last name), it will not work. It will work in Online mode, or with first.last exchanged for first, or last, or UserID. If the Account.MultiLoginAddressBookSupport property is set to TRUE, to get rid of the MAPI layer for accessing address books, you cannot search on Email Addresses in either caching or online mode. Defect submitted to GroupWise Development. Defect #353083: The DOESNOTCONTAIN operator didn't work. This was fixed in GW 7.0.
FindMessages: NOTE: For the Calendar Folder, which is a special type of folder, the Folder.FindMessages, unlike the Folder.Messages.Find method, will only return accepted appointments, tasks, and notes and not unaccepted ones. (It also returns unaccepted appointments sent to yourself). These unaccepted mail items still belong to the mailbox folder. On the other hand, the Folder.Messages.Find method for the Calendar folder actually run a query which finds all the items, both accepted and unaccepted. NOTE: Any query folder, such as the Task List, will return an error while trying to get the messages collection. For Query folders, you must retrieve the Query, and then get the messages collection from the Query. Defect # 346841: Likely memory leak of around 180 bytes when the FindMessages method is called. Defect submitted to GroupWise Development. Defect #373436: Using the TOTAL_RECIPIENTS keyword in a filter gives an error. The fix is to be made in GW 7 SP1. FolderRights: Defects # 266277 and # 100257534: Accessing the Folder.FolderRights property took took long to respond. The lengthy response time was corrected in GW 6.0 SP1 and GW 5.5 EP SP4 (GW 5.5.6.1). It now takes a much shorter time to access the FolderRights property. Name: NOTE: If developers rename a folder in caching mode to a name already in use as a hidden folder by the Outlook Plugin, such as Contacts, the system may rename the folder again to avoid a conflict like Contacts-1. Defect # 312169: The Folder.Name property, for the mailbox folder, was returning the name of Mail box (with a space) rather than Mailbox (without a space). This was fixed in GW 6.5. Shared: NOTE: If someone else shares a folder with you, and you access a document reference in that folder, beware that you have rights to the associated document. You may not be able to access it otherwise. NOTE: There is no way to determine the shared folder status of the sharee of the folder. Did the sharee accept it? Open it? Delete it?
Defect # 354588. UserA shared a folder with UserB. UserB accidentally deleted it. UserA tried to reshare it programmatically, by first deleting UserB's rights, then adding them back in and commiting the changes. The error was that the folder was not reshared with UserB. Defect submitted to GroupWise Development.
Add: Defects # 316133 and # 319522: The FolderRightsCollection.Add method was being used to add to add an Addresses object as the first argument to the Add method. This is OK. The Addresses object had a Group object in the collection. This resulted in a crash. This problem was fixed in GW 6.0.3 and in GW 6.5.
Add: NOTE: The Add method doesn't accept a full folder name, like John DoeMyFolder. You can't have any marks in the name. This is opposite to other methods and tokens, like the RuleAddActionMoveToFolder token - that needs the full folder path. You have to go to the folder level you want before calling Folders.Add. Refresh: Defect # 376448, 376524: The Folders collection object lacked a way to refresh the contents. That meant that any changes to the Folders - especially by other programs - were not reflected in the collection. The only way to refresh the collection was to completely exit the program, then relogin. To duplicate: Inside VB .NET, login to the Object API. Loop until the user stopped the test or closed the program on the next instructions. Retrieve the AllFolders collection. Display the Count of the collection. Then delay for a short time. While this program is running, go to another computer and run the GW Client against this same account. Add a new folder to the Cabinet. The All Folders::Count() in the loop never changed. Fixed (9/10/2004) in GW 6.5.3, and in GW 7.0. Defect #401896: Problem with a semaphore deadlock. Encountered while accessing a NewFolder and trying to delete an item from the Trash. Fixed in GW 7.0, Feb, 2005. Fixed also submitted for inclusion in GW 6.5.4.
PlainText: Defect # 355428: In rare circumstances, accessing the Plaintext or RTF properties of a message using C would not work. Fixed in GW 6.5.2 in January, 2004. RTF: NOTE: To change the color of the font, programmatically, you could use the Message.FormattedText.RTF property. Unicode: Defect # 386755: Retrieving the Unicode version of the message body did not return certain Unicode characters. Fixed in GW 6.5.3 (Oct, 2004)
Defect: The ObjType values for a group in an address book always returned 0. This problem was fixed in GW 5.5.3.
Add: Defects # 313593 and # 322592: When the AddressBookEntry argument to the Add method did not have a valid email address (as required), a faulty error message was being returned that said, Running in remote mode, method not available. Fixed in GW 6.0.3 and GW 6.5. NOTE: You cannot another GroupMember object to a GroupMembers collection. In other words, you cannot create groups of groups. NOTE: The first argument to the GroupMembers.Add method is an AddressBookEntry object. This object needs to have a valid email address.
Add: Defect # 261967: When a DocumentLibrary object was supplied as the argument for the Locations.Add method, (to perform a Query), it was first thought that there was a bug that required the DocumentLibrary object to be instantiated before it could be used. Thus, it appeared that Locations.Add (MyRootAccount.DefaultDocumentLibrary) would not work, but Locations.Add(vLib)would work where vLib had been defined previously as MyRootAccount.DefaultDocumentLibrary. Upon investigation, there were several other factors involved with memory allocation and refresh issues. The defect was fixed in GW 5.5 EP SP3 (GW 5.5.5.1) and in GW 6.0 SP1, but not in GW 5.5. Note: Make sure you supply a VARIANT argument to the Add method, and not a specific interface using early binding and the type library. This is because the Add method accepts only a VARIANT argument.
CommonMessageID: NOTE: This property is works the same way across post offices. However, the CommonMessageID property has not been added to the Query or Find parser. DelayedDeliveryDate: Defect # 357765: Accessing the Mail.DelayedDeliveryDate property in caching mode caused a crash. Fixed in GW 6.5.2. Defect # 376254, #376521: Sometime during the development of GW 6.5.2 the Mail.DelayedDeliveryDate property was broken. All mail was delivered immediately. Fixed in GW 6.5.3 in July, 2004. Also fixed in GW 7.0 July, 2004. Defect # 367548: When a draft message is saved into the Work in Progress folder with a delayed delivery date, the delayed date is wiped out. Defect submitted to GroupWise Development. NOTE: Even though the Mail.DelayedDeliveryDate property was not implemented until the Mail4 interface (according to the VB Object Browser), it still appears as a property of the Mail object in the watch window using Visual Basic - even for the Mail, Mail2, and Mail3 objects. It also can be set to a value in the application for Mail objects prior to Mail4, and applications will work fine using a Sep, 2004 version of GW 6.5.3. More investigation needed. NOTE: The GroupWise Delivered Date is the actual date the item was delivered to the Post Office. In most cases this is also the date the item is delivered to the User. However - if the message was sent as a "Delayed Delivery" message, the item will be delivered to the Post Office, but held from the User until the actual Delayed Delivery Date is hit. DeliveredDate: NOTE: see DelayedDeliveryDate:
Defect # 330328, # 332618: There was originally no capability for getting or sending HTML formatted messages through the Object API or Tokens. However,
now, if you add an attachment called text.htm, GW 6.5 and later will
recognize it as the HTML part of the message and display it properly.
Message3 Interface:
Defect # 283060: The Message3 interface had some initial problems
associated with it. It was modified in GW 6.0 SP1 and left in the
GroupWise code. The interface now points back to the Message2 interface.
If you need one of the methods that were new to the original Message3
interface (get_Archived, put_Archived, put_Sharer), get the appropriate
sub-message interface (Mail3, Appointment3, etc) instead.
Defects # 316753 and # 316754: The GUID values of the Message3 and
Message2 interfaces, as recorded in the registry, did not match the
values given the gwoapi.h header file. Fixed in GW 6.0.3 and in GW 6.5.
Archived:
Defect # 273141: The Message.Archived property did not work if you used
early binding with a Message3 interface in GW 6.0. The message was not
archived. As a result of this bug, the Message3 interface was modified
(GW 6.0 SP1). The workaround was instead of using a Message3 interface,
retrieve a Message interface on an object, determine the item type (mail,
appointment, task, etc), and then retrieve the appropriate interface from
the child message type that contains the Archived method.
Attachments: (see also Attachments Object)
Defect # 100266876: If you accessed a message type attachment from a non-
GroupWise user, there was an error. Fixed in GW 6.0.1 and GW 5.5 EP SP4
(GW 5.5.6.1)
NOTE: Attachments sent with a message, where the message had no bodytext,
were truncated or missing if the message was sent through GWIA. Fixed in
GW 6.0.3.
BodyText: (also see BodyText:PlainText)
Defect # 355428: On some accounts, when looping through all the messages
in an account, the Object API was unable to access the body text (either
plaintext or RTF) of a particular message. Fixed in GW 6.5.2.
NOTE: When an encrypted message is sent, it arrives as an attachment.
The body text is blank. Therefore, Message.BodyText will be blank
Defect # 392420, #392423: Retrieve any message that comes from a corrupt
GroupWise database. Then ask for the Message Body. The Object API will
never return. Fixed in GW 6.5.3 and GW 7.0, Nov., 2004.
BodyText: PlainText:
Defects # 294556 and # 100293998: When a user tried to access the bodytext
of a routed message, using the Message.BodyText property (or
Message.BodyText.PlainText), there may have been a runtime error. The
problem was fixed in GW 6 SP2, GW 5.5 EP SP5 (GW 5.5.7.1) and in GW 6.5.
Defect # 312909: The ability to modify bodytext for personal appointments
and tasks was added to GW 6.0, but not to the Object API. Hence, although
the first call to modify bodytext worked, subsequent calls did not work
because the GW client did not show the new text. Fixed in GW 6.5.
Defect # 383914: If you create a draft message using the GW client, and
save it, and then access it with the Object API, you cannot change the
body text field. You can only change the subject field. Defect submitted
to GroupWise Development. Workaround is to create a new Draft Message,
then change the BodyText in there.
Defect # 331866. Using the Object API, you could not modify the bodytext
of a message for personal appointments, tasks, or notes, and have that
modification appear in the GroupWise client, until GroupWise was
rebooted. Defect submitted to GroupWise Development.
Clone:
Defect # 374267, #380259: The Message.Clone method did not copy
category information. Fixed in GW 6.5.3 on Aug. 20, 2004, and in
GW 7.0, Dec. 2004.
Completed:
Defects # 294472 and # 100295312: When the Object API was used to mark a
routed message as completed, using the Message.Completed property, it
caused two messages to be sent to the next person in the routing chain
instead of one message. Fixed in GW 6.0 SP2, GW 5.5 EP SP5 (GW 5.5.7.1),
and in GW 6.5.
Defect # 296459: The value of the Message.Completed boolean value for a
routed message was always FALSE, even if you set it to TRUE. Fixed in GW
6 SP2, GW 5.5 EP SP5 (GW 5.5.7.1), and GW 6.5.
CreationDate:
Defect # 100273377: The creation date was off about 6 hours when a message
was put into a shared folder. Fixed in GW 6.0.1.
Delete:
Defect # 296459: The user was unable to delete a routed message after it
had been completed. There was a runtime error. Fixed in GW 6 SP2, GW 5.5
EP SP5 (GW 5.5.7.1), and GW 6.5.
DownloadStatus: BodyTextState:
Defect # 271003: Suppose you used Hit the Road in the GW client to
download only the subject line of messages. The Object API would report
incorrectly that for some messages, the body text was downloaded. This
error was fixed in GW 5.5.5, GW 5.5 EP SP4 (GW 5.5.6.1) and in GW 6.0.
EnclosingFolders:
NOTE: Using the Object API to find all message IDs in the calendar folder,
a message may be duplicated "if" that message is linked to another folder.
To verify if it is, check the "EnclosingFolders" property of the message
object. If it is > 1, it is linked.
Field: Value:
Defects # 287066, # 287084, and # 100276179: Custom message field values,
when accessed through a C3PO, were not refreshed properly. You had to
shut down GroupWise before the values were refreshed. Fixed in GW 6.0.2
and GW 6.5.
Forward:
NOTE: You can only forward or reply to a message once for the same
forwarding or reply rule. This is working as designed. It is to help
prevent intra-company spamming from vacation rules and the like. If a
rule doesn't have a subect OR uses the Does Not Contain method, then each
user will only receive a repy from the rule one time. Appointments are
exempt from this feature so they will always receive replies. In
ConsoleOne's client options there is a feature -> Send -> Send Options,
there's a radio button called "Allow reply rules to loop". Setting that
radio button will override this feature.
Defect # 357086: If you use the Object API to get some message already
in your inbox (or a sent item), and call its forward method, it will
create a new draft message for you with the original message as an
attachment. If you then fill out the fields of the draft message and call
its "Send" method, you get an error message saying the Send method of the
IGWMail5 object failed. Fixed in Feb, 2004, in GW 6.5.2.
Defect # 378163: If a 3rd party uses the Object API to Forward or Reply
to a message, the appropriate Forward and Reply bits are NOT set in the
current message. Without those bits, the GW Client will not display the
appropriate icon. Fixed in GW 7.0, Aug. 2004.
FromText:
Defects # 284074, # 284679 and # 285643: When the
Messages.AddExistingMessage function was used, the Message.FromText field
was being overwritten.and the From text was being truncated to the size
of the orignal text in the From field. Fixed in GW 6.0 SP2 and GW 6.5.
LocalDelete:
NOTE: The Message.LocalDelete property should be used through
the message subtypes instead. Retrieve a Message interface on an object,
determine the item type (mail, appointment, task, etc), and then retrieve
the appropriate interface from the child message type that contains the
LocalDelete method.
MessageID:
Defect # 223756: The GroupWise Message ID should be unique and persistent.
For GW 5.5 EP, if a GroupWise posted message is created, and assigned a
message ID, if the posted message was subsequently modified via the
GroupWise client, the posted message's ID was changed. The fix was
inserted into GW 5.5 EP SP1 (GW 5.5.3.1).
NOTE: The Message.MessageID property of a message may be duplicated if
the message is linked to another folder. Check the
Message.EnclosingFolders property to tell if the message is linked. If
the value is > 1, it is linked.
NOTE: There is no way to correspond the Message IDs in the MTA log with
the Message IDs in the GroupWise data store. They are different. Also,
the Message ID used by the Object API is not the same thing as the Message
ID used by GroupWise MAPI. The Object API MessageID was originally
intended for internal use only, but has become part of public knowledge.
NOTE: The Message ID of a draft message changes when it is sent. The ID
of the Sent Message is not the same as the ID of the message as seen by
the recipient.
NOTE: If you capture an outgoing message using a C3PO, there is no way
to get the MessageID in the handler.
Defect # 375690: If you get the message list of all the messages
(document references) in the "Default Library" folder, or the "Authored"
folder (both of these are Query folders), and then access a particular
message (document reference) in the collection, you cannot access its
MessageID. A runtime error says that memory could not be allocated.
On the other hand, if instead of using the Default Library or Authored
folders, you try other types of Query folders like a "Find Results"
folder, and get a document references collection, it works fine. Defect
submitted to GroupWise Development.
NOTE: GroupWise Development feels that as far as syncing messages is
concerned, the only way to prevent reprocessing of messages is to keep
track of the messages in some other database, then compare the new
messages with the old. For example, sync products keep a separate database
of items to give to the PDA. These sync products retrieve a collection
from the Object API, then store the Message ID in their database. The next
time the sync products request a messages collection they compare the list
they have to the list in their database. This is also a good way to find
what has been deleted and what is new.
NOTE: The MessageID is unique across all mail boxes in a domain. There
is a very small chance the ID could be duplicated if a second GroupWise
domain is created and the same userID is on both GroupWise domains and
a message is created at the exact same time on these two separate
GroupWise domains.
Name:
Defect # 100266954: When accessing the Message.Name property, there was an
error if the Message was a SharedAddressBook notification message. (A
SharedNotification type message). Fixed in GW 6.0 SP1 and GW 5.5 EP SP3
(GW 5.5.5.1).
Opened:
Defect # 392161, #392162, #392163: If a user changed the status of the
Message.Opened or Message.Read flags on one of his email messages
programmatically, this information was never relayed to the sender of
the message. When the sender clicked on the properties menu on this
message in his Sent Items folder, he saw no change in these values.
Fixed in GW 6.5.3 and GW 7.0.
NOTE: Even when a message has been opened, this property can be set back
to false when using the PeekMode property. See Account.Peekmode property.
Defect # 365001. If the Object API is used to read an unopened message,
the value of Message.Opened will be set to TRUE (GW 6.5). If you then
set the Message.Read status back to FALSE, and run the application again,
and read the message, the value of Message.Opened will be set back to
FALSE. Could not duplicate the problem in GW 7.0. Fixed in GW 6.5.5.
Private:
Defects # 264517 and # 268109: Setting the Message.Private property had
no effect. Fixed in GW 5.5.5, GW 5.5 EP SP4 (GW 5.5.6.1) and in GW 6.0
SP1.
Defects # 290956 and # 290998: Setting the Message.Private property
resulted in an error message saying Update access is denied to current
user. Error began occurring in GW 6.0 SP1. Fixed in GW 6.0 SP2 and in
GW 6.5.
Read:
Defect # 392161, #392163: If a user changed the status of the
Message.Opened or Message.Read flags on one of his email messages
programmatically, this information was never relayed to the sender of
the message. When the sender clicked on the properties menu on this
message in his Sent Items folder, he saw no change in these values.
Fixed in GW 6.5.3 and GW 7.0.
NOTE: Even when a message has been read, this property can be set back
to false when using the PeekMode property. See Account.Peekmode property.
Defect # 365001. If the Object API is used to read an unopened message,
the value of Message.Opened will be set to TRUE (GW 6.5). If you then
set the Message.Read status back to FALSE, and run the application again,
and read the message, the value of Message.Opened will be set back to
FALSE. Could not duplicate the problem in GW 7.0. Defect submitted to
GroupWise Development.
Defect # 394601: Problem only seems to appear when using VB Threads. If
you receive a new email and mark it read, the API will mark the message
unread when you access the body text of the email. Similarly, if you
create a new meeting and accept it, the API will change the meeting to
unaccepted when you access the body text of the meeting. This behavior
only happens once per object. For example, if you mark the email message
Read a second time, it will remain marked read.
Recipients: (see also Recipients Object)
Defect # 357680: Accessing the Message.Recipients collection repeatedly
during stress testing revealed that eventually after looking at around
65,000 messages you would see an error message saying an error occurred
trying to access the Windows System Registry. Fixed in GW 6.5.2.
Refresh:
NOTE: At one time, the Message.Refresh method had a memory leak. It was
fixed in January, 2000.
Reply:
Defect # 384529. Retrieve a Message from a folder. Call Message::Reply
to generate a NewMessage object. Call NewMessage::Send. The original
sender of the message will receive two replies to their message. Fixed
in GW 6.5.3 and GW 7.0, Sep, 2004.
NOTE: You can only forward or reply to a message once for the same
forwarding or reply rule. This is working as designed. It is to help
prevent intra-company spamming from vacation rules and the like. If a
rule doesn't have a subect OR uses the Does Not Contain method, then each
user will only receive a repy from the rule one time. Appointments are
exempt from this feature so they will always receive replies. In
ConsoleOne's client options there is a feature -> Send -> Send Options,
there's a radio button called "Allow reply rules to loop". Setting that
radio button will override this feature.
Defect # 378163: If a 3rd party uses the Object API to Forward or Reply
to a message, the appropriate Forward and Reply bits are NOT set in the
current message. Without those bits, the GW Client will not display the
appropriate icon. Fixed in GW 7.0, Aug. 2004.
ReplyDaysRequested:
Defect # 322990: This property was not being saved properly (was not
persistent). If you set the property to some non-zero value, and sent out
a message to a recipient, the value of ReplyDaysRequested as seen by the
recipient, using the Object API, was back to zero. Also, if the sender of
the draft message saved the message, and used the Object API to look at
the ReplyDaysRequested property later, it was zero. Fixed in GW 6.5.1
ReplyParent:
Defect # 405653. This method only appeared to work for received messages,
and only if another earlier received message in the reply thread is also
in the inbox as a received message. It then returned the grandparent
and not the parent. Fixed in GW 7.0. Also submitted to GW 6.5.5.
Retract:
NOTE: Only the sender of a message can retract it.
Routed:
Defects # 256253 and 100256647: After setting the Message.Routed flag to
TRUE, a message was suppose to proceed from one recipient to the next in
order of completion. However, the message went to all recipients at
once, ignoring the routed property. This defect was fixed in GW 6.0 SP1,
and in GW 5.5 EP SP3 (GW 5.5.5.1).
Defect # 296459. There were several problems with using the Message
object of the Object API of a routed message. Fixed in GW 6 SP2. Also
fixed in GW 5.5 EP SP5 and GW 6.5.
Send:
Defect # 276144: You used to be able to send off a draft message, and then
use it again a second time (or multiple times) after it had been put in the
trash. This was fixed in GW 6.0 SP1. It is no longer possible. The first
send should delete it, and make it unuseable (unless you retrieve it from
the trash).
NOTE: Using the Message.Send method to send out messages within a loop can
cause Sent Item property difficulties. The GroupWise code structure can
cause two messages to have the same ID if sent within the same second. The
person sending out the messages needs to slow down the iterative loop time.
Defect # 322402. When you send out X messages in a loop, through the
Object API, the Sent Items Folder may show more than X messages that were
sent. Some messages may be reported as duplicated. Defect submitted to
GroupWise Development.
Defect # 357086: If you used the Object API to access a message already in
your inbox, and call its forward method, it will create a new draft message
for you with the original message as an attachment. If you then filled out
the fields of the draft message and called its send method, you got an
error message. The problem only occurred in GW 6.5, not in GW 6. Fixed in
GW 6.5.2.
Defect # 100255903: The Recipients.Resolve method would hang when used in
an NT service. The Message.Send method calls the Resolve method. Fixed in
GW 5.5.5 and GW 5.5 EP SP4 (GW 5.5.6.1).
Defect # 394862: The Send method would crash if you first used the
MultiLogin command with the MultiLoginAddressBookSupport flag set to TRUE,
and had added your recipients by using the Recipients.AddByDisplayName
method. Fixed in GW 6.5.4 (12/3/2004)
NOTE: Messages are sent from the GroupWise Client on a Windows background
thread. When you create a message and push Send, the GroupWise Client
spawns a background thread in Windows and uses the background thread to
actually call into the GroupWise engine to perform the send. While the
SEND is in process, GroupWise returns control of the UI to the user.
There could be some cases where conceivably the SEND action is occurring
slowly enough some other action taken by the user after the Send button is
pushed, such as creating a rule, may actually occur before the message is
really sent.
Defect # 100354256: GroupWise 6.5 was too slow at start up. The problem
was that GroupWise 6.5 added support for SSL connections between the GW
Client and the POA. This supporting code was too slow. A fix was made
in GW 6.5.2, April, 2004.
Defect # 384529. Retrieve a Message from a folder. Call Message::Reply
to generate a NewMessage object. Call NewMessage::Send. The original
sender of the message will receive two replies to their message. Fixed
in GW 7.0, Sep, 2004.
Defect # 402937: NTService displays a dialog box when sending to a
Personal Group. Create a program that uses the Object API to send a
message. Login to the Object API as an NT Service. Also tell the Object
API to NOT use MAPI. Then send a message to a Personal Group. The Object
API/MAPI Address Book will report "The MAPI Session Handle of the Novell
GroupWise Object Request Broker could not be accessed. The address book
cannot run." Fixed in GW 7.0, Feb. 2005.
Defect # 403882: Sending to a PAB Group from a Shared Address Book does
not work. Add a Group from a Shared Address Book to a draft message,
then calling Send() will not send the message to the group. To duplicate:
have someone create a Shared Address Book, then share it with you. Also
have a Group created in that Shared Address Book using names from the
Shared book. When the message is sent, it will not be sent to the Group.
Fixed in GW 7.0, Feb. 2005
NOTE: The Message.Sharer property should be used through the
message subtypes instead. Retrieve a Message interface on an object,
determine the item type (mail, appointment, task, etc), and then retrieve
the appropriate interface from the child message type that contains the
LocalDelete method.
Size:
Defect #416988: It was not possible to get the size of a message directly.
That is, there was no Message.Size property. An indirect method was to
used to get the Size keyword within a filter. Using this keyword, you
could determine whether a given message is greater or less than a certain
size. This could be done a number of times on the same message in an
iterative loop using a type of binary search until you have pinpointed the
size of the message. This is still the only available way for GW versions
6.5 and before. GroupWise Engineering added the capability to get the
size directly in GW 7.0. Use the various message subtypes, such as
Mail.Size, Appointment.Size, etc.
ViewName:
Defects # 277861 and 100274737: Setting a custom view for a message to be
sent by using the Message.ViewName property did not work. The recipient
of the message received a regular mail view instead. The fix was made in
GW 6.0 SP1 and also in GW 5.5 EP SP5 (GW 5.5.7.1)
NOTE: Normal Object API Messages collections have a limit of 4962 messages in a folder (counted by records). This is the value that Messages.Count uses. If there are more messages than that in the Folder, the Object API user will not be able to see them (you must delete some messages in order to see the extra messages). MessageLists, however, are different. There are no limits to the number of items in a MessageList. So any results from a Query object or from the AllMessages::Find method will have no limits. When you use Messages.Add, the limit was 8192 (counted by DRN rather than records). This was fixed (see below). Defect # 400845, 400846: Enhance the Object API so that more than 4962 or 8192 messages could be contained in a folder. Fix made in GW 7.0, Feb, 2005. Also fixed in GW 6.5.5 (Jan, 2005) NOTE: GroupWise Development feels that as far as syncing messages is concerned, the only way to prevent reprocessing of messages is to keep track of the messages in some other database, then compare the new messages with the old. For example, sync products keep a separate database of items to give to the PDA. These sync products retrieve a collection from the Object API, then store the Message ID in their database. The next time the sync products request a messages collection they compare the list they have to the list in their database. This is also a good way to find what has been deleted and what is new. NOTE: The messages collection returns messages in no particular order. In other words, there is no guaranteed order of returned values. As a general rule, the Object API leaves any sorting of items up to the callers. Add: Defects # 345542, #346469 and # 346466: The Messages.Add method would not work when trying to add a new draft message to an account that already had too many messages in it (several thousand). Fixed in GW 6.0.4, GW 6.5.2 and GW 7.0. NOTE: If you use early binding with a Message object as the argument, it needs to be dimensioned as a VARIANT argument and not as a Message argument. NOTE: You cannot create a new SharedNotification message for a new address book by using the Messages.Add method with GW.MESSAGE.MAIL.NEW.SHARED.PAB.NOTIFY. Instead, you need to create an address book and share it with someone else. NOTE: If you define the Message object that the Messages.Add method returns as an Appointment object, and then access the StartDate property, you will get an error. The error says the object doesn't support that method. An easy workaround is to dimension the return Message value as Appointment2, Appointment3, Message, or Variant. It will then succeed. NOTE: If the Appointment object came as a return value from the Messages.Add method, dimension the object as an Appointment2, Appointment3, Message or Variant object, and not as an Appointment object. Defect #383833, #383834. The Messages.Add method returned an error when you tried to add a personal message (using egwPersonal as second parameter). Fixed in Sep, 2004 in GW 6.5.3 and GW 7.0. AddExistingMessage: Defects # 284074, # 284679 and # 285643: When the Messages.AddExistingMessage function was used, the Message.FromText field was being overwritten.and the From text was being truncated to the size of the orignal text in the From field. Fixed in GW 6.0 SP2 and in GW 6.5. Defect # 347806: A customer was creating a new message (Message A) by using the Messages.AddExistingMessage method, and then attaching that new message to a new draft message (Message B). He then used the Messages.AddExistingMessage method again to add Message B to a message collection. All this was done in a loop. This created a number of problems and runtime errors, seen at different times. Fixed in GW 6.0.5 and GW 6.5.2. Defect # 336778. If you used the Messages.AddExistingMessage method to add a new message, it would say "Pending" in the SentItems properties. Fixed in GW 7.0 so that the status now returns nothing. Defect # 383646, #383647. If you used AddExistingMessage with the 5th parameter equal to egwPersonal, the message never displayed in the GW client. Fixed in Sep, 2004, in GW 6.5.3 and in GW 7.0. Defect # 404500, 405760. The second parameter in AddExistingMessage was ignored. It is the sender's email address. Instead, the value of Message.Sender.EmailAddress returned the email address of the account you are using to run the application. Fixed in GW 7.0 (March, 2005) and in GW 6.5.5 (March, 2005). Defect # 411036: When the recipients for the new message were inserted by using the AddByDisplayName method of the Recipients object, and the display name was in the form of "last name, first name", and this draft message was used as input to the Messages.AddExistingMessage method, the first name was left off when the message created from AddExistingMessage was later viewed in the GW client. This can be partially resolved if each recipient object is first resolved. In this case, the resulting message after calling the AddExistingMessage function will show email addresses instead of display names. Getting the entire display name is not possible. Count: NOTE: The Sent Items folder will find any Outbox item in the Mailbox, Calendar, or Sent Items folder. Sent appointments or tasks will show up in the Sent Items folder, but not in the mailbox. Find: (See Filter Object also) NOTE: The Messages.Find property can only find the * and ? special characters. It also cannot find partial words. NOTE: For Calendar folders, the Find method only returns accepted messages, along with unaccepted ones sent to yourself. NOTE: The Find method uses a <MyField, STRING> syntax rather than a <MyField> syntax for Strings, like the AddressBookEntries.Find method uses. NOTE: This method will not only find messages in a particular folder, but also linked messages to that folder. NOTE: Cannot used the Find method to search for the CommonMessageID property of the message subtypes (mail, appointment, etc) across post offices. Move: NOTE: The Messages.Count value will decrease as soon as you move a message that is in the collection.
NOTE: Normal Object API Message collections have a limit of 4962 messages. If there are more messages than this number in the folder, the Object API will not be able to see them. In contrast, there are no limits to the number of items that are allowed in a MessageList. Add: Defects # 257824 and # 100269771: When adding a task to this message list, the MessageList.Item method failed to work correctly later to access messages in the list regardless of their type. The wrong messages may have been accessed. This problem was fixed in GW 5.5.5, GW 5.5 EP SP4 (GW 5.5.6.1) and in GW 6.0 SP1. Item: Defects # 257824 and # 100269771: When adding a task to this message list, the MessageList.Item method failed to work correctly later to access messages in the list regardless of their type. The wrong messages may have been accessed. This problem was fixed in GW 5.5.5, GW 5.5 EP SP4 (GW 5.5.6.1) and in GW 6.0 SP1. Defect # 354495: When you use MultiLogin() to connect to an account, then create a query, add some folders to the Query Locations object, perform the query, and then walk through the resulting MessageList, for some messages the MessageList.Item(vIndex) fails. Defect has been submitted to GroupWise Development.
Defect # 270166: The Query object did not work in GW 6.0 in caching mode when a password was used to log into caching mode. Fixed in GW 6.0 SP1. NOTE: A Query won't find a document until it has been indexed. By default, this is about every four hours. Defect # 354495: When you use MultiLogin() to connect to an account, then create a query, add some folders to the Query Locations object, perform the query, and then walk through the resulting MessageList, for some messages the MessageList.Item(vIndex) fails. Defect has been submitted to GroupWise Development. Defects # 310328 and # 314958: There used to be a limit on Query results of 4096. This limit was increased to 65536. Fixed in GW 6.0.3 and GW 6.5. NOTE: The CommonMessageID property of the message subtypes (added in November of 2002) was never added to the Query or Find parser. Expression: (See Filter Expression also) Defects # 269413 and # 269800: Suppose you created a Find Results folder through the GroupWise client that searched for documents only, and had checked the box labeled Find only official document versions. Suppose further that you had added some other criterion in your search filter such as the subject of the document had to contain GroupWise. When you later used the Object API to get the Query.Expression of this FindResults folder, the expression would include two ANDS instead of one like this: SUBJECT CONTAINS GroupWise AND AND OFFICIAL_DOCUMENT_VERSIONS_ONLY. Further, if you had not checked the Find only official document versions checkbox, the API application would have crashed. This bug was fixed in GW 5.5.5, GW 5.5 EP SP4 (GW 5.5.6.1) and in GW 6.0 SP1. Defects # 270633 and # 100272515: Assigning a complicated filter expression with multiple parentheses to the Query.Expression method would sometimes mess up the GroupWise parser with some nesting problems and change the meaning of the expression. Hence, the search would sometimes be for the wrong expression. The problem was fixed in GW 6.0 SP1 and in GW 5.5 EP SP4 (GW 5.5.6.1). Defects # 278092 and # 100272898: The Object API was used to copy the Query.Expression filter from one Query folder, and use the same filter on another folder. The expression included a reference to the Official Document Version. After making the copy, and extraneous 65535 was introduced into the expression syntax for the document version. It also unchecked the Find only official document versions checkbox in the GW client, which it should not have done. Fixed in GW 5.5 EP SP4 (GW 5.5.6.1) and in GW 6.0 SP1. Defect # 278524 and # 100272899: When you set librarian rights in the GW client for a Query folder, that filter was not inserted into the Query.Expression (doesn't see SEARCH_AS_LIBRARIAN added to existing Query string. Fix was in GW 5.5 EP SP4 (GW 5.5.6.1) and GW 6.0 SP1. Defect # 306635: A Query.Expression like (CREATE_DATE > THIS_MONTH 3) saved through Query.CreateFolder would not be displayed correctly in GroupWise Folder/Properties/Advanced Find. Even if you created the search expression in the GroupWise Client, and then use the same filter expression to create the new Query Folder, the result was the same. Fixed in GW 6.5. Defect # 313546: There was no ability to search on task priority or category. Added in GW 6.5. NOTE: To search for text within documents, use ANY_FIELD in the filter expression. The type of document can make a difference in the success of the search. NOTE: Cannot used a Query to search for the CommonMessageID property of the message subtypes (mail, appointment, etc) across post offices. Locations: Defect # 306634: The Query.Locations were not saved with the Query. When Query.CreateFolder was run, for example, whatever locations you had were reset to an empty list, so that the whole mailbox was searched. This happened after you exited the application. Fixed in GW 6.5. Defect # 361002: Queries were paying no attention to any Query.Location restrictions. If you restricted the search to one folder, messages in other folders were being found as well. Fixed in GW 6.5.2. NOTE: The Query object states in the Locations property that you can search within a document library. To search for text within documents, use ANY_FIELD in the filter expression. The type of document can make a difference in the success of the search. NOTE: You cannot specify locations in a proxied account. In other words, it is invalid to add a folder from a proxied user into a query of the user that did the query. (This used to not be the case, and hence this oversight was corrected in GW 7.0) QueryMessages: Defects # 310328 and # 314958: There used to be a limit on Query results of 4096. This limit was increased to 65536. Fixed in GW 6.0.3 and GW 6.5. Defect # 375690: If you use a Query to get all the messages in the "Authored" of "Default Library" folders (both query folders), and then access any message in this message list (which is really a list of document reference type messages), you cannot access the MessageID property. A runtime error says memory could not be allocated. Defect submitted to GroupWise Development. SearchLocally: NOTE: This is the only Query property that acts differently in online and remote or caching modes. Stop: NOTE: The Stop method issues a HALT command to the GroupWise Search Engine. The HALT will be handled the next time a set of Search Results is returned. Stop does not set the Query.Completed flag to TRUE. Take the current set of Messages found and use them.
NOTE: With the release of GroupWise 6.5.2, the GWOAPI.H header file for developers using C included a description of the QuickMessage interface. This description left off two properties - BoxType and ClassName. Any 3rd party that tried to use that file to build a C or C++ program, then access the QuickMessage object received errors. These two properties were quickly added to the header file.
Defect # 390253. When you attempted to get the QuickMessages collection for Tasks, setting the StartDate to some value and using the egwNewMessages value, you got all the tasks and not just the tasks since the StartDate. Fixed in the GW 6.5.3 version dated Oct. 28, 2004. Defect # 389728. When you use a trusted application to log into several accounts, and get the QuickMessages collection in each account about five seconds apart, the application hangs. Fixed in Oct. 28 build of GW 6.5.3. Defect # 400845: Enhance the Object API so that more than 4962 or 8192 messages could be contained in a folder (see Messages Object). Fix made in GW 7.0, Feb, 2005. Defect # 401166: Accessing QuickMessages and Account::Refresh from multiple users, each user running in a different thread, causes a hang or crash. Fixed in GW 7.0, Feb. 2005. Defect #378232: The QuickMessages collection was change in GW 7.0 so that the collection no longer includes hidden messages. Count: Defect # 390253: When you attempted to get the QuickMessages collection for Tasks, setting the StartDate to some value and using the egwNewMessages value, you got all the tasks and not just the tasks since the StartDate. Fixed in the GW 6.5.3, Oct., 2004. GetQuickMessagesCollection: NOTE: Like the normal Messages collection, the QuickMessages collection returns messages in no particular order. In other words, there is no guaranteed order of returned values. As a general rule, the Object API leaves any sorting of items up to the callers.
Defect # 307938: The Object API was returning blind copy recipients as well as normal recipients and CC recipients in the Recipients collection. This made it possible for normal recipients of a message to see a list of all blind copy recipients of the message. Only the Sender-Owner of the message should have had that capability. Fixed in GW 6.0 SP3 and in GW 6.5. Defect # 388190, #388191. If someone sent an email to you from outside GroupWise, with you are a BC recipient, you could not see it when iterating through the Recipients collection. Fixed in October, 2004, in GW 6.5.3, and in GW 7.0, Oct, 2004. Add: Defect # 358355: Messages sent with CC or BC recipients ended up as TO recipients instead when the message was opened. Fixed in GW 6.5.2. AddByDisplayName: Defect # 394862: The Send method would crash if you first used the MultiLogin command with the MultiLoginAddressBookSupport flag set to TRUE, and had added your recipients by using the Recipients.AddByDisplayName method. Fixed in GW 6.5.4 (12/3/2004) Defect # 411036: When the recipients for the new message were inserted by using the AddByDisplayName method of the Recipients object, and the display name was in the form of "last name, first name", the first name was left off when the message was later viewed in the GW cleint. Submitted to GroupWise Development. Count: Defect # 100253222: If a forwarded message had more than one of any of the types of recipients (TO/CC/BC), the Recipients collection would only return one item. The item returned was the ?TO? address of the original message, but had the type set to BCC. If there were no more than one recipient of any type in the forwarded message, then the Recipient's collection contained the correct expected values. Fixed in GW 6.5. Defect # 405404: If you search for messages with more than a certain number of recipients, using the TOTAL_RECIPIENTS key, and then access these messages and look at the number of recipients in each message, there is a discrepancy. The number of recipients (Message.Recipients.Count) includes the TO and CC recipients, and not the BC recipients. However, when the AllMessages.Find operation is used with a TOTAL_RECIPIENTS >= X filter, it finds TO, CC, and BC recipients. Hence, you can find messages that show more than X recipients, and when it is printed out using Recipients.Count, it shows less than X. It appears that the filter is not working properly. Defect has been submitted to GroupWise Development. Resolve: Defect # 100255903: The Recipients.Resolve method would hang when used in an NT service. Fixed in GW 5.5.5 and GW 5.5 EP SP4 (GW 5.5.6.1).
Defect # 100266954: When accessing the Message.Name property, there was an error if the Message was a SharedAddressBook notification message. (A SharedNotification type message). Fixed in GW 6.0 SP1 and GW 5.5 EP SP3 (GW 5.5.5.1). NOTE: There is no way to determine who owns a shared address book through the Object API. NOTE: You cannot create a new SharedNotification message for a new address book by using the Messages.Add method with GW.MESSAGE.MAIL.NEW.SHARED.PAB.NOTIFY. Instead, you need to create an address book and share it with someone else. Accept: Defects # 250248 and # 100257398: The SharedNotification.Accept method, when used to accept a shared folder notification message, caused an application crash. In spite of the crash, the shared folder was accepted although with a cryptic form of the original folder name. The defect was fixed in GW 6.0 and in GW 5.5 EP SP4 (GW 5.5.6.1) Defect # 281327 and # 100273550: The SharedNotification.Accept method, when used to accept a shared address book notification message, did not work. Fixed in GW 6.0 SP1 and in GW 5.5 EP SP4 (GW 5.5.6.1).
Defect # 268522: Tasks created and assigned through the Object API could not be printed later with the GroupWise Client. This problem was corrected in GW 5.5.5 and in GW 5.5 EP SP4 (GW 5.5.6.1). Presumably it was also fixed in GW 6.0 SP1, but no record is given. Completed: Defect # 294472. Marking a routed message as completed had the effect of sending "2" messages to the next person in the routing chain. Fixed in GW 6 SP2. Fixed in GW 5.5 EP SP5, and in GW 6.5. StartDate: NOTE: If a task is not completed, the client shows the startdate and duedate as the same original date of the task. However, the Object API shows that the StartDate is updated everyday, while the DueDate remains the original date like the client. This is working as designed. Tasks have a separate date (AssignedDate). When it is first created the AssingedDate is set to the StartDate. At midnight, the StartDate is rolled to the next day. The GWClient will show AssignedDate the start of the task. The GWClient uses the StartDate to determine that the task is over due.
NOTE: The TimeBlock.From field follows the administratively defined ConsoleOne setting for name format (LastName, FirstName or FirstName, LastName). Hence, this field in a busy search may be invalid if the user has the GW client address book display format set to the opposite format from ConsoleOne (see Address Book/ View/Name Format).
NOTE: The trash folder is not a query folder.
NOTE: The AllMessages collection includes all messages that are in the box EXCEPT the trash. If any third party wishes to search the Trash, the party can retrieve the TrashEntries collection, then use the Find method inside there.
Delete: Defect #401896: Problem with a semaphore deadlock. Encountered while accessing a NewFolder and trying to delete an item from the Trash. Fixed in GW 7.0, Feb, 2005. Fixed also submitted for inclusion in GW 6.5.4.
--gmonson
© 2009 Novell, Inc. All Rights Reserved.
