FDOT SS10 Menu, Unable to set plot scale.

Mitch,

I've seen this before, and it is often caused by Microstation or Power GEOPAK not populating certain system folders in the list of Primary Library Search Paths in the Workspace Configuration. I'm not sure why this happens, but try this:

Go to WORKSPACE > CONFIGURATION and select PRIMARY SEARCH PATHS from the left pane. Then Select LIBRARY PATH from the top right pane and select the EDIT button.

Scroll to the bottom of the top pane. You'll find a list of paths separated by semicolons. Enter the following additional paths, separated by semicolons. You will see them populate in the bottom pane list.

C:\WINDOWS\

C:\WINDOWS\SYSTEM\

C:\WINDOWS\SYSTEM32\

C:\WINDOWS\SYSWOW64\

Click OK, then Click OK again to dismiss the Configuration Dialog. Close FDOTSS4 and re-launch to see if the issue is resolved

Hi Matt

I went and added it to the CustomVars.txt file and restarted PowerGeopak.

Restarted and checked the config to insure that they are there. They Are.

Same Error.

Mitch

Hi, Mitch.

I have had a lot of experience with the problem Matt's solution fixes.

Here is a way that you can tell if you and Matt are on the same page: When you open ustat, immediately on it settling in and before doing anything, an error will show on the error list / bottom status bar saying something about kernel32.sys was not found, and the Plot Scale does not display on the ustat Title Bar as usual.

If so, then Matt's solution *will* fix the problem. Try applying the exact steps he outlined instead of customvars.txt. The problem comes from some particular interaction (as yet not fully understood by me) in setting the custom menus in the Bar Menu. My experience is that all is fine until the first time setting the custom menus, which breaks it permanently. Also, I've seen that it appears that these folders are already on the search path and after Matt's solution, they may even be listed twice. Go figure, but adding it as Matt outlined does fix the problem. Once it is working correctly you will start seeing (again) the Plot Scale displayed on the ustat title bar.

If you are not exhibiting the kernel32.sys error message then it is not the problem Matt thinks it is. (Re-read your message. Sorry for not catching your mention of kernel32.sys at first.)

The odd thing is that I recall this problem as far back as FDOT2004, and after over 15 years of troubleshooting, I'm still not sure what the initial cause of it is.

Thanks for the detailed explanation.

The odd thing is that I recall this problem as far back as FDOT2004, and after over 15 years of troubleshooting, I'm still not sure what the initial cause of it is.

Thanks for the detailed explanation.

Matt:

This should create the problem for you:

1. on a virgin workstation install (I don't do server install and do not know how it behaves in that environment) plot scale works fine.

2. on the bar menu, >Standard >Menu Configuration >All and OK all the way out.

3. (if I recall correctly, it says it will restart ustat, but it only shuts down.)

4. on reopen, can't find kernel32

It is now my SOP to set the system paths as part of the installation. I believe this is when I have seen it listed twice - before it gets clobbered.

Also, to Mitch's circumstance, I suspect his customvars.txt is putting the paths into the same area that is getting clobbered whereas your add-paths is either going into a different area  **OR**  loading at a different time, ie. after the clobber effect has occurred.

BTW, whatever the bar menu configuration is doing appears to be repeatedly and continual, viz. undoing the fixes after the first offense does not restore the plot scale functionality. The puzzling thing to me is why just those system paths and not others. Makes me think it is going to be some cadpilot quirk.

This is really useful!

I bet I know the reason why running the menu configuration undoes the kernel32 fix.

Setting the search paths in the workspace configuration dialog saves the variables to the FDOTSS10.UCF file.  Running the menu configuration copies a fresh copy of the UCF file from the server (or workstation) into the WORKSPACE\USERS\ folder causing any custom variables written into the UCF to be wiped out.

To remedy that, you can run a fresh menu configuration, then add the variables in the configuration dialog (adding them to the UCF) and then copy the UCF back up to the location from which it gets copied.

I'll go try to determine where that comes from.

Great catch!

Hmm...  I think you've got it backwards Matt.

The menu configuration change is not "undoing the kernel 32 fix", that is it is not wiping out the added paths to fix the kernel32 problem. Rather it is wiping out the  *default*  paths already set as part of the virgin install. The added paths of the fix is  *restoring*  what got wiped out in the default configuration by the menu configuration change.

Unless by "added" you are referring to an "add" that is part of the workspace install.

Maybe the UCF copy is not grabbing that set of paths - maybe because of how they are originated in the install process.

You're right. I did a little digging over here and what you're saying makes sense.