none
Strange square brackets behaviour on custom forms

    Question

  • Hi there,

    I was wondering if you guys have a similar issue with square brackets on custom created forms?

    Background: I've created a new inherited (parentclass is the service request class) class for our own Service Requests where we save certain information required for the service request fulfillment (properties and relationships). For these custom classes I've then created custom forms by using the Service Request form as the base. In each new console form I've added a new Tab Item where the text boxes, list-, date- and user-pickers for the newly created class properties and relationships are placed. So far so good!

    Now, we I import the sealed MP in our Test environment I get this when displaying the new form:

    In this example I've named the Tab Item without leading or trailing square brackets. It seems that SCSM is for some reasons not able to parse the default square brackets anymore so that they disappear. Also the fact that the default square brackets are not used consistently (see Urgency, Priority and Area for example), doesn't make the whole thing prettier...

    Adding square brackets to my custom Tab Item name doesn't help here either.  Has anyone ever experienced the same issue and knows a fix for it?

    We're using the 2012 RTM build (with CU2) in our test environment btw.

    Any help is very appreciated. Thanks in advance!

    Cheers

    Alex

    Monday, September 24, 2012 2:36 PM

Answers

  • Interesting, I never tried that before. Thanks for the insight :) So, having learned that, this should solve your square bracket problem:

    Quick overview: Most labels in the out-of-the-box formed are bound to values within the management pack itself. So, in the XML, in your <form> node, you want to define some FormStrings, then in the <Presentation> node, you'll define some StringResources that match those form strings..then you'll create some display strings to actually supply the text that you want to display in each label.

    Here's a blog post detailing form strings and string resources:

    http://blogs.technet.com/b/servicemanager/archive/2010/02/25/localizing-forms-service-request-example.aspx

    And, basically, you can just copy the form strings, string resources, and display strings for the original service request form from it's management pack (ServiceManager.ServiceRequest.Library). That way, you're sure that the form string IDs will match the expected binding paths in the form itself.

    Let me know how it works for you..I just tried it myself and it worked fine.

    Edit: In fact, instead of copying them, you might be able to simply reference them in your MP..that way any changes made to the original form's display strings will be reflected in your custom form's display strings.



    Tuesday, September 25, 2012 3:40 PM

All replies

  • I have not tried this myself, but could you try adding your own FormStrings and StringResources to your form definitions?

    How did you create these custom forms based on the out-of-the-box service request form?

    Tuesday, September 25, 2012 1:41 PM
  • I have not tried this myself, but could you try adding your own FormStrings and StringResources to your form definitions?

    Sorry, I don't understand exactly the question here. Can you please elaborate? As I have used the standard form libraries from SCSM I don't exactly know where I could add my own definitions?

    How did you create these custom forms based on the out-of-the-box service request form?

    I've used the Authoring Tool to create them. When you add a custom form you have to specify a DLL library with the form definitions, then you have to select the relevant console form and your new custom form will get created. Now you can add all the content you want to see on this new form and save that MP afterwards. Next you have to add the Typeprojections used by the standard form to your own form (I've done this by raw XML file modification), otherwise you get an errormessage when SCSM opens the form in the console (see also this blogpost from Anton http://blog.scsmsolutions.com/2012/05/propertyname-error-on-form-targeted-to-custom-class/).

    Next you have to seal the MP, make a Management Pack Bundle with the DLL libraries you've used in this MP and import the MPB file in SCSM. That's how I've created our custom forms.

    Cheers

    Alex

    Tuesday, September 25, 2012 2:29 PM
  • Interesting, I never tried that before. Thanks for the insight :) So, having learned that, this should solve your square bracket problem:

    Quick overview: Most labels in the out-of-the-box formed are bound to values within the management pack itself. So, in the XML, in your <form> node, you want to define some FormStrings, then in the <Presentation> node, you'll define some StringResources that match those form strings..then you'll create some display strings to actually supply the text that you want to display in each label.

    Here's a blog post detailing form strings and string resources:

    http://blogs.technet.com/b/servicemanager/archive/2010/02/25/localizing-forms-service-request-example.aspx

    And, basically, you can just copy the form strings, string resources, and display strings for the original service request form from it's management pack (ServiceManager.ServiceRequest.Library). That way, you're sure that the form string IDs will match the expected binding paths in the form itself.

    Let me know how it works for you..I just tried it myself and it worked fine.

    Edit: In fact, instead of copying them, you might be able to simply reference them in your MP..that way any changes made to the original form's display strings will be reflected in your custom form's display strings.



    Tuesday, September 25, 2012 3:40 PM
  • Cheers Aaron!

    Thanks for this. I think I understand now the concept with FormStrings / StringResources / DisplayStrings. I'll implement this in our MPs for the affected forms to sort this out. Still funny though that MSFT has not used the square brackets consistently for the fallback values (see Priority and some other marked labels in the screenshot above), but yeah, we're alljust human! :)

    Thursday, September 27, 2012 6:17 AM
  • How would you reference the form strings, resources, and display strings specifically? 

    I am trying to extend the knowledge form with a new tab and property using the authoring tool.  The knowledge class is in a different MP from the form itself by default.  When I extend this class I end up with [] around the properties that belong to this class however just adding the tab control itself does not result in [] around each property. I'm not sure why extending the class would affect this.  I am not sure whats going on here...

    I'll be doing some more research!


    Allen Anderson Systems Analyst Arizona State University - OKED Knowledge Informatics




    Tuesday, May 21, 2013 10:46 PM
  • Hi Aaron
    quick question, when you say: 'In fact, instead of copying them, you might be able to simply reference them in your MP..'
    Do you simply mean to add the relevant ManagementPack reference up the top?
    For instance if I'm doing a Custom Incident Form - I'd reference the 'ServiceManager.IncidentManagement.Library' like so:

    <Reference Alias="Alias_xxxxxxxxxxxxx">
      <ID>ServiceManager.IncidentManagement.Library</ID>
      <Version>7.5.2905.0</Version>
      <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
    </Reference>
    And that's it?
    Tuesday, August 5, 2014 7:50 AM
  • That's what I was referring to, yes. I didn't try it myself, though, so I don't know if referencing external string resources will work or not.

    So, in your formstring, you could try referencing the string resource located in another MP..something like this (using your Alias_xxxxxxxxxx reference)

    <FormString ID="Label_SomeLabel">$MPElement[Name="Alias_xxxxxxxxxx!Some.StringResource"]$</FormString>

    It's worth a try at least :)
    Wednesday, August 6, 2014 6:49 PM
  • I'm going to cross reference This Thread, which deals with similar problems related to the custom controls and form strings.

    it also should be noted that the XML snippet that Aaron threw out mirrors exactly the usage in the default forms, This is how the default forms are localized the <FormString> contains an MP Reference ("$MPELEMENT[name="blah"]$") to reference a <StringResource>, and that StringResource has a <DisplayString> in various languages, (remember, display strings work by matching the ID of the DisplayString with the ID of the element, the String Resource, in this case) which is then returned as a FormString property when the form DLL is called.

    so either Aaron is just that good, or he peeked...




    • Edited by Thomas Bianco Wednesday, August 6, 2014 8:08 PM OMG why can't I type words good?
    Wednesday, August 6, 2014 8:04 PM
  • Tested and confirmed
    Added the mp reference for ServiceManager.IncidentManagement.Library

    <Reference Alias="Alias_xxxxxxxxxxxxx">
      <ID>ServiceManager.IncidentManagement.Library</ID>
      <Version>7.5.2905.0</Version>
      <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
    </Reference>

    Then added the relevant <FormStrings> for the label/item - amended w/ my reference.

    <FormString ID="TabItem_General">$MPElement[Name="Alias_xxxxxxxxxxxxx!Microsoft.EnterpriseManagement.ServiceManager.Incident.Forms.IncidentFormControl.TabItem_General"]$</FormString>
    
    and it works!
    Thursday, August 7, 2014 7:44 AM