Did you ever find more information on this?

Unfortunately not. There is a work around but it requires you to install third-party software (actually just the library file from the software) on each client. You do not need the registered version (trial will work).

Tip: If you were to copy this dll file to a shared file server, a script or .bat/.cmd file could be written to perform the following steps automatically to register on remaining clients.

So the software you will need to install on at least one machine (so you can extract it's dll file) is VBSEdit from https://vbsedit.adersoft.com/vo.asp (this is what I use to edit my VBScripts - no affiliation). This program has a dll file that can be referenced from a VBScript by using CreateObject(). Once installed on one machine you can go to "%LocalAppData%\Vbsedit\x64" and copy the vbsedit64.dll file for any additional workstation.

It's my preference to copy to the workstation's System32 folder where other libraries of this type are stored and where it is shared between all users of that workstation as well as it cannot be easily manipulated without proper file permissions, but you can copy wherever you'd like. Then you will need to run a Command Prompt as admin, and the following command:

RegSvr32 vbsedit64.dll

or if you didn't copy the file to the System32 folder:

RegSvr32 "<PathToDLL>\vbsedit64.dll"

Any machine that has this library registered will be able to use this command:

and here's the dialog box as a result:

Note: Even when "Multi Select" is false, the file path is still stored in an array with base 0

That's what I was figuring. I am still learning how scripting integrates with sage, but have a lot of Windows and programming experience.

This script is running on the client side, right?

When do you trigger this script? For example, with a Sales Order Entry, instead of a user linking a file under memo, are you able to just put a custom button on the form?

Correct - the script will have to run on client side for two reasons:

• You registered the dll on the client (so the server won't be able to create the object)
• From the server's perspective, it won't be able to "see" the client's local files. You would be navigating the server's files in the dialog box (if it even shows up for the client to begin with - similar thought as to why we can't use the VBS MsgBox when running code from server).

As for the trigger - it's triggered off of a custom button script when a user clicks a button when they want to process a file - but I suppose depending on the situation it could also be triggered on a particular event script (when user enters data into a particular field for example or when the user is about to save a new sales order).

Once the user clicks the button, the dialog box appears with the code in example usage. User selects a file. Then it's up to you what happens to that file. Here's an example of what you could possibly do: 

Okay perfect. So basically, you are not using the default memo button and panel (possibly even hiding it) and using two custom buttons to create a custom attachments.

I'm looking to do something very similar to what you are doing, as there are less tech-savy people who will absolutely link files from their C: drive eventually (we're all human and distractions happen), but also not having to manually move files will save the user time.

It would be nice to be able to embed .NET objects, such as a ListBox, onto a panel, which could be useful for displaying a list, such as that second button which would display a list of the attachments. It seemed the panel customizer is pretty basic.

I was thinking about this the other day. You could potentially create a .net class library yourself, register for COM interop + make assembly com-visible.

then

Set MyCOMObj = CreateObject("MyLibrary.Class")
so_invoice_bus_udf_somefieldname = MyCOMObj.DisplayFilePicker()

This would have to run client-side, but you can return the value back to a field if this was ran from a button script that had the field selected from the script variable selection dialog and the checkbox in the return column checked.

You would have to distribute and register the COM/Class Library on each workstation that would require it since it's client-side, but it could potentially allow for much greater customization that you have control over.

There are VBScript commands to open a file (not requiring any special workstation installs)... which I found many years ago through Google.  This actually opens a text file, and returns the contents, but can probably be adapted to just return the name.