[Isaac Harned]

Sorry for the delay, I seem to be creating a mountain of volunteer projects 😬.

Long story short, there is a customizable PDF form that I am creating (discussion is here: https://uchapter2.com/brainery/javascript/forum/topic/isaac-harned-here-for-forms-with-javascript/#post-135307), but not everyone in the office enjoys entering data on the PDF, which is understandable with the loss of keyboard flexibility. Once it’s in the field it is actually much more workable on ipad. As an option for the office, I am basically creating an input form.

[Isaac Harned]

Personally, for none other than comfort and accuracy, I love the Logi ergonomic (K860 keyboard, MX master 3S combo set). Both are Bluetooth capable and can switch between three devices. Mouse has a free spin wheel, so you can scroll through those long construction docs fast. Also has a side scroll wheel for a little more customization, couple extra buttons that can be customized for specific apps through the logi control panel. Keyboard clicks are smooth and quiet, yet have a solid almost mechanical click. Both are the most comfortable I have used yet, especially if you are at the station the entire work day.

[Isaac Harned]

Ah for bluebeam, yes, but unfortunately I am trying Mitch’s suggestion of saving Excel as FDF

[Isaac Harned]

– All field names consistent across templates.

– Form will be blank when importing.

– No reverse necessary, once it’s in the pdf it’s good. These data files will be used year over year and the transfer from PDF to new version of PDF is easy enough

[Isaac Harned]

Maybe I am missing it, or maybe its a type of export that I didn’t see in the data tab, but these are the options I have for Save as file type:

Excel-File-Types.png 29 KB Image File - Click to view

Options

• Copy Download Link

[Isaac Harned]

Thank you Liz, this has been the bane of my last couple of days!

[Isaac Harned]

Mr. Young coming in clutch!

Thank you @mitchyoungs will try this out. I don’t know why I did not try this myself 😅

[Isaac Harned]

I will have to look into this, may be a few days though.

[Isaac Harned]

Workflow could be to only allow those toolsets to be visible in the main working profile, then have a field profile to distribute with those tools not visible. I’m sure that’s already your workaround, but the best idea I had.

[Isaac Harned]

Agreed this is the best option, just comes with one little caveat:

When exporting to a network location, Tool sets will be Locked, meaning that to make any changes to the set, user will basically have to unlock or check out the toolset. This can be annoying if you have a base set of tools that needs to change in minor ways along the process.

In our situation, our markups involve alot of visual properties that might need to be changed as we go through highlighting ductwork (i.e. colors that don’t mesh well together or are harder to see through when ductwork overlaps). Our process was originally to store the toolsets on the network, but I would see little random tools added to my chest, or little properties modified in my base tools. It would be great if we could assign permissions to them, but unfortunately, anyone you give access to will be able to unlock it.

What I do now is an export to local storage with dependencies into a folder. Then I manually move the folder to a shared location (it was not exported to the network location directly, so it will not have the lock). When setting up a new system, my training dashboard will instruct users how to manually copy that folder into their “AppData\Roaming\Bluebeam Software\Revu” \version folder, then they can open revu, import the profile, which will come with the tool chests. If a user wants to replace the toolset with the original, the folder will remain in the app data folder and can be dragged from the imported folder to the main “Revu/(version)” folder, and if there is an update to the Master file on the network, that toolset can be dragged directly to replace the same toolset. This eliminates the multistep re-import as long as they are named exactly the same.

[Isaac Harned]

Liz let me know that since this is not a pre-constructed regex, and the part being built to look for a digit is in quotations, JavaScript sees this as an escape character. In order to keep the expression intact, a second backslash was added to the digit search.

[Isaac Harned]

The solution to this was simply the page size. 11 x 17 does not give the font enough of a lower size range to adjust. I had to tell Bluebeam support why this was happening, and that their text boxes DO adjust vertically AND horizontally. 36 x 24 works just fine.

🙄

[Isaac Harned]

Thank you Liz, super helpful!!!!!!

[Isaac Harned]

Also the line:

let childMask = new RegExp(“^” + tap + “-[\\d]{1,2}$”);

when I plug this into regex101, I get some weird search parameters. Never worked with the RegEx constructor, so please bear with me here =)

So if the previous tap variable only stores the number at the end of the string (Let’s say NumberOfTaps1), then this would be constructed as such:

/^1-[\\d]{1,2}$/

The part that is tripping me up is the double slashes I think, what does this do to the digit search?

[Isaac Harned]

So in the local code, the line:

var tap = dropDownName.match(/\d{1,2}$/)

Does this only store what is matched? I.e. it looks at NumberOfTaps1, and only stores the “1” since it matches the search for 1 or 2 digits at the end of the string?