Discussions
Categories
Groups
Community Home
Categories
INTERNAL ENABLEMENT
POPULAR
PUBLIC CLOUD
PRIVATE CLOUD
Quick Links
MY LINKS
HELPFUL TIPS
Back to website
Home
Web CMS (TeamSite)
New Document Profile - Call Dialog
bwalker13
Hello Everyone,
I have a background in web programming, and have customized WorkSite Web extensively. However, I have essentially no win32/COM experience.
I have been tasked with creating a custom dialog that will be invoked with a button on the New Document Profile dialog in DeskSite. This custom dialog will enable the user to add a new matter (Custom2 table) on the fly while profiling a document.
I have reviewed the COM SDK documentation before posting, but I am still unclear on how some very general (and to most of you, elementary) pieces fit together:
1) Where do I create a new custom dialog? The Dialog Editor only appears to be able to modify existing dialogs. If I use VB6 to create a custom dialog, how do I integrate it into DeskSite?
2) If I use the Dialog Editor tool to add a button to the New Profile Dialog, I can access that button through the NewProfile.nrs script. Can I call my custom dialog (created as per question 1 above) from NewProfile.nrs?
Any general guidance with the above would be greatly appreciated. Thanks for taking the time to read this.
Regards,
B. Walker
Find more posts tagged with
Comments
jny
You cannot enter dynamic values into the lookup tables of any validated custom fields. This is not supported programmatically in any versions prior to 8.0.
In the 8.0, the IManAdmin.dll has new implementation that exposes new methods off of the NRTDatabase Object for adding new values to these validated fields. The new API calls are InsertChildCustomField and InsertParentCustomField.
bwalker13
Hello jny,
Thanks for your response.
My project manager floated the idea of entering dynamic values into a non-validated field, and then using triggers to manage and maintain the integrity of the data.
Assuming that a workaround of this nature is feasible (and out of curiosity, even if it isn't), would you be able to provide some general responses to the two questions that I had in my original post? Thanks!
Regards,
B. Walker
Migrateduser
You definitely should not use the Dialog Editor. However, you need to create
a custom command
, which in turn will put your custom dialog up on the screen. The dialog should be created in Visual Studio (you're using VB; or if you choose C++). For an explanation on how to integrate your command (not just your custom dialog), refer to the "Custom Commands" pdf document you should have in your SDK. It tells you all about creating custom commands (has VB and C++ examples). You might want to pay special attention to places where the document talks about Lookup Buttons and tells you how to replace the default custom lookup commands that bring up iManExt Lookup Dialog.
bwalker13
Hello LanaK,
Thanks for your response, and for pointing me in the right direction. I will review the Custom Commands PDF and take it from there.
Regards,
B. Walker
jny
If you're attempting to validate a non-validated custom field value (on the WorkSite New Profile Dialog) you may simply catch the OnChange event to implement your validation logic. This can be done by using the NewProf.nrs script. See VB Scripting for WorkSite Dialogs.pdf for further clarification. A sample NewProf.nrs is also available in "<install path>\WorkSite\iToolKit\iScripts."
bwalker13
Hello,
Thanks for the additional direction jny, I will certainly look into hooking the .nrs script files for field-level validation logic.
The project is almost complete: I have called my custom VB form from the New Profile Dialog, validated and then written values from the custom VB form into the database, and passed these values back to the calling ActiveX class.
The one piece of the puzzle currently outstanding is how to take these latter values (stored in string variables ClientID and MatterID) and use them to populate the edit fields for Custom1 and Custom2. I have reviewed the appropriate sections of the SDK docs and sample projects, but can't quite isolate what I need from the Context object (I am assuming that this is the appropriate mechanism). Does anyone have any experience and/or ideas regarding this particular issue? Thanks.
Regards,
B. Walker
jny
How are you calling your VB form from the New Profile dailog -- is your ActiveX class implementing the ICommand Interface? And also, how are you writing values collected from your custom VB form to the database?
If you have a handle to the dialog object, IMANEXTLIB.NewProfileDlg, you should be able to set the values -- that are stored in ClientID and MatterID -- on Custom1 and Custom2 fields by calling SetAttributeValueByID. Document profile fields are represented by AttributeID Enum. For further clarification on the SetAttributeValueByID method and the AttributeID Enum, see VB Scripting for WorkSite Dialogs.pdf.
bwalker13
Hello jny,
Thanks again for your helpful response.
I am using an ActiveX class that implements the ICommand interface. Here is the code (stripped-down) for the ICommand_Execute sub:
Private Sub ICommand_Execute()
' create custom VB form
Dim frm As Form1
Set frm = New Form1
' values that will be read from the form
Dim ClientID As String
Dim MatterID As String
Dim MatterName As String
ClientID = ""
MatterID = ""
MatterName = ""
' show form and return to Profile Dialog only when form closed by user
frm.Show vbModal
' fill variables with input from custom VB form
ClientID = frm.lstClientID.Text
MatterID = frm.txtMatterID.Text
MatterName = frm.txtMatterName.Text
' ***here is where I am stuck - writing the values retreived from the custom VB form to the active Profile Dialog***
' variable for Profile Dialog
Dim myDlg As IMANEXTLib.NewProfileDlg
' ***how do I create a handle for the existing profile dialog??***
' ***if handle can be created as per above, should this work!?***
myDlg.SetAttributeValueByID nrCustom1, ClientID, False
myDlg.SetAtrributeValueByID nrCustom2, MatterID, False
End Sub
Hopefully the above code helps clarify exactly where I am stuck. Any help with this issue would be greatly appreciated.
Regards,
B. Walker
jny
The ContextItem, IManExt.CallingObject, returns the calling dialog object, which is the NewProfileDlg object in this case. Through which, you may call the SetAttributeValueByID to set your values to the specified profile fields. Like so:
=============================================================
Dim objCallingDialog As Object
' Set a pointer to your current profile dialog by using the IManExt.CallingObject
Set objCallingDialog = mContext("IManExt.CallingObject")
' Now you may call SetAttributeValueByID off of objCallingDialog to set your profile.
...
=============================================================
Hope this helps
Migrateduser
You can get the handle to your existing NewProfileDlg through the context item "ParentWindow".
FYI: setting "ManExt.SelectedString" context item to some string value along with setting "IManExt.Refresh" to true in your custom command will set the edit control associated with the lookup button that called your custom command to the string stored in "ManExt.SelectedString". ouch...
That's going to trigger the OnChange event in NewProfileDlg, at which point you're free to make any changes to the profile using SetAtrributeValueByID.
bwalker13
Hello,
Thanks to both jny and LanaK for their most recent suggestions. The method suggested by jny works perfectly, and I will also investigate using the ParentWindow as per LanaK.
I now appear to have all the building blocks that I need in order to complete this project.
My project leader remarked yesterday on what a valuable resource this forum is, and obviously I concur. Thanks again for all of your assistance.
Regards,
B. Walker
bwalker13
Hello,
Well, just when I thought the coast was clear an issue with my approach has cropped up.
I grabbed Custom12 lookup and made it into my Add Matter button for the New Profile Dialog. This button calls up the custom VB form from my ActiveX dll, and everything works well. I had to add Custom12 edit to my New Profile Dialog as well or it couldn't be saved, and this is the root of the problem. In an ugly workaround the dialog is 1x1 pixels so it is tucked away, but in the screenshot I enlarged it for debugging.
An amusing (and in hindsight obvious) ramification of my approach is shown in the attached screenshot. If a field (e.g. Class) is selected before my Add Matter button is invoked, the Custom12 edit field gets filled with the last entry (in this case "TEXT" from the Class field) and validation fails.
I looked at using the Duplicate button from the Dialog Editor, but there is no matching entry in the registry to overwrite with my custom command (AddMatter.AddMatterCmd).
Is there a way to create a generic button on the New Profile Dialog, and wire it to my custom command?
Thanks.
B. Walker
Migrateduser
Setting context item "ManExt.SelectedString" to an empty string inside you custom command should cure your Custom12-"TEXT"-validation problem.
As for creating a generic button to hook up your custom command: sorry, there's no way, you have to use one of the lookup buttons. Otherwise you can hook up your command to a menu item in the app, but once again not inside the profile form or any of the other customizable dialogs.
It would have been more convenient if you did Custom2 lookup and "Add Matter" functionality on Custom2 lookup button, but then again I don't know what your UI requirements are.
jny
You have mentioned that your intended implementation objective has changed from filling in dynamic metadata to a validated field, specifically custom2, to "My project manager floated the idea of entering dynamic values into a non-validated field, and then using triggers to manage and maintain the integrity of the data." I'm not sure what this really means; that is, is this a work-around to adding new data (which is not preexisted in the database) to the custom2 table. I hope not.
Please keep in mind that there isn't a mechanism to enter new values to any validated fields. This includes custom12. If you're intending to hijack custom12 lookup button to use a custom command on the profile dialog to process some internal logic, such as populating another field, it's legitimate. This type of customization is usually used to work-around auto-populating one field when another field is filled with a value that satisfies a condition.
If you're hijacking Custom12 (which is a validated field) lookup button to use as a command button to internally populate another validated field, the value that is added to the target field must be a preexisted value -- one that is already stored in the lookup table in the database; other wise, it won't work as there isn't a way to programmatically, via the COM API that is distributed with the SDK v3.1 and backwards to feed new values to any validated lookup fields in the database. It must be added through DBAdmin program.
If, however, you're hijacking Custom12 lookup button to internally set the custom2 field, and that the value is one of those that are already stored in the database, then it should work; although, if that's the case, why not just hijack Custom1 (as I presume you would be checking on the parent field first for its childlist) lookup button instead?
I guess I'm still a bit puzzled about your client-side logic -- what are you trying to accomplish?