Options
  • State Verified Answer
  • Locked Locked
  • Replies 4 replies
  • Subscribers 14 subscribers
  • Views 1947 views
  • Users 0 members are here
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Can you make the Choose List UI component support more than 100 characters?

jmondanaro

For my Users, we have objects representing legal entities that wind up with very long names: Entity A with Nominee Entity B for the benefit of Entity C. Where Entity A and B will be repeated for many Entity C's. The problem is "Entity A with Nominee Entity B for the benefit of" is generally more than 100 characters long. We use a MultiLine Text Field as the Name/Title for these objects to get us the characters we need. However, now when trying to associate a Document metadata "Choose List" field with these objects, you cannot identify which entity you want because the first 100 characters that are shown are not unique. Further, you can only "search" via the drop-down against the first 100 characters which are all that's loaded into the control.

Is there a way to work around this or some registry or other configuration value that can effect this, or is the Client UI fundamentally loading everything into a MFilesText property and therefore always truncating the content. 

I find the 100 Character Limit of "Text" to be an extremely small limit that seems an odd and arbitrary choice.

-Jason

Parents
  • +1

    I think behind the scenes M-Files is always using the built-in "Name or title" property as the name of the object, even if you mark some other property as the name property for the class. So if the user enters a longer name to the multiline text field, the first 100 characters are copied to the "Name or title" field and this is what you are seeing in the dropdown.

    What this means in practice is that you will have to live with the 100 character limitation and decide how those objects would be best identified within that limitation. For instance, you could have an automatic property as the name property of the class and this property would take what the user has entered in the multiline text field and somehow modify it to fit in 100 characters. It could drop away fluff words such as "for the benefit of", use some abbreviations or otherwise generate a name that makes sense to the users so they can select the correct object.

    If these legal entities have some ID number or similar that could be used to identify them, you could also add this ID as the first element of the automatic object name so users could search by the ID in the dropdown. So the name would be something like "123456 - Entity A / Nominee Entity B / Entity C"

    You may need to do this automatic naming with a custom script or you may be able to use the Managed Properties module for it, depending on what properties you have on the objects and the naming convention you want.

  • 0 in reply to Joonas Linkola

    We use the strategies you describe, however, not all users have access to the information used to create the shortcut. For example, we do in fact modify the name to be like "1234 - TruncatedName" except that some users do not have access to the system where 1234 comes from so this doesn't help them because they wouldn't know, they only have the LongName from the legacy system.

    Still it seems that the 100 character limit on Text fields is unnecessarily parsimonious for current systems and could be  expanded without too much difficulty since it would be an increase and not a decrease.

  • 0 in reply to jmondanaro

    Using long names can cause problems in Multifile documents because the path might end up being extremely long. The document name will be seen as a folder name in the file system. If you add that to a long file name and the original path in M-Files you may end up with something like:

    file:///M:/<vault name>/ID2/DDECBEEA-B2A2-4FB4-ABC4-3C7DBD4275CB/0/122000-122999/122192/L/L/<verylongdocumentname-verylongdocumentname-verylongdocumentname-verylongdocumentname-verylongdocumentname>/verylongdocumentname-verylongdocumentname-verylongdocumentname-verylongdocumentname-verylongdocumentname.pdf

    Even with long file names enabled on server and all clients you may encounter situations where this would not work.

Reply
  • 0 in reply to jmondanaro

    Using long names can cause problems in Multifile documents because the path might end up being extremely long. The document name will be seen as a folder name in the file system. If you add that to a long file name and the original path in M-Files you may end up with something like:

    file:///M:/<vault name>/ID2/DDECBEEA-B2A2-4FB4-ABC4-3C7DBD4275CB/0/122000-122999/122192/L/L/<verylongdocumentname-verylongdocumentname-verylongdocumentname-verylongdocumentname-verylongdocumentname>/verylongdocumentname-verylongdocumentname-verylongdocumentname-verylongdocumentname-verylongdocumentname.pdf

    Even with long file names enabled on server and all clients you may encounter situations where this would not work.

Children
  • 0 in reply to bright-ideas.dk

    The Users in question are ALREADY using these horrible long names for files and folders and encountering problems on their network drive that I am trying to get them off of and into M-Files with as little resistance as possible.

    I suppose the other alternative would be to allow a more complex Lookup control behavior. If you could leverage other fields during the lookup, then it wouldn't matter what the Name or Title limitation was.

    It all comes down to how to help users lookup the right object.

M-Files
M-Files Support


© 2025 M-Files, All Rights Reserved.