Workspace Fields, the better way?

As already discussed in an article here, the lack of a Field Addin type for workspaces is a bit of a miss. WIth that in mind I dug around a little bit to see if I could get some existing RN classes / Interfaces called in my Workspace addin to get the automatic resizing behavior of the label and the field. After determining which controls were available in all RN dll's, by simpy adding all dll's in the RN folder using the Choose Toolbox items command. After inspecting which controls were returned there were 2 namespaces of interest;

RightNow.Applications.Components.Layout
RightNow.UI.Forms

After a bit of weeding through the different classes and interfaces I created the following class, which does exactly what the other controls do and resizes nicely.

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

using System;
using RightNow.Applications.Components.Layout;
using RightNow.UI.Forms;

namespace RNControlsTest
{
public partial class UserControl1 : FieldPlaceholder
{
String Label;
DatePicker DateP;

private bool _ReadOnly;
public bool ReadOnly {
get {
return _ReadOnly;
}
set {
_ReadOnly = value;
DateP.ReadOnly = value;
}
}

public UserControl1()
{
Label = "This is Custom!";
DateP = new DatePicker();

this.ContentControl = DateP;
this.LabelText = Label;
this.Dock = System.Windows.Forms.DockStyle.Top;
}
}
}

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Quite exiting when I discovered this! Using a standard RN date field, that re-sizes!
All other controls like hierarchy etc are all available. There are more classes like FieldControl, which give you all the possibilities, but that one generated an Instance=null error in the editor. Did not go much deeper into why, since I only need the functionality that the PlaceHolder class gave me and it is much simpler.

There is only the downfall that RN does not guarantee these classes to remain in upcoming versions like they do with any normal exposed interface. Let me know what you think and if you have a feeling on how likely the changes are that these classes will change in the future?

Bastiaan

Comments

Fantastic work. From a technical perspective this is perfect and should be encouraged by Oracle. I'm worried this will not work in recent/future versions.

In the latest AddIn Documentation, Oracle claims they are checking for inclusion of internal assemblies and blocking the AddIn if they find any:

Per http://documentation.custhelp.com/euf/assets/devdocs/february2015/Connect_AddIn_Framework/Default.htm
Under "Design Considerations and Best Practices" / "Referencing Internal Assemblies"

"Add-ins reference assemblies in Oracle Service Cloud via a runtime check that occurs immediately after each add-in is activated and the console is launched. After an add-in is activated, Oracle Service Cloud inspects its type and iterates through the dependent assemblies it is using. The list of dependent assemblies is then compared to a list of qualified assembly names. If a match is detected, the add-in is disabled and a message is added to the Add-In portions of Oracle Service Cloud options window indicating that the add-in is 'Inactive' and referencing an unsupported internal assembly. Refer to Viewing Active and Inactive Add-Ins."

Unfortunately that was to be expected. I can see their reasoning though, if many addins were build using internal assemblies, updating would mean that many addins would fail. So we probably have to wait until the field interface is there and live with config settings for label text and label offset for now... :(

Zircon - This is a contributing Drupal Theme
Design by WeebPal.