Making model and paper space modes more obvious

Joe Dunfee

This is really an enhancement request that is is not anchored in a specific solution. So, I thought I would throw it out to the community, in case anyone has a good way to do this.

In spite of many years of working with model and paper space, I now find myself constantly getting confused about which space I am in. I assume it is just my current project has made it an issue. I normally work in model space, with the paper space work being mostly limited to the title block and viewports. But, the current drawing has me working in the layout tabs a lot more.

I know there are several indicators that show which space you are in. One is that the border of the viewport highlights when you are in that viewport. But, for me this is not working well, because I am often zoomed in far enough that I do not see the border. Other indicators are that the UCS icon changes, and the toggle button on the lower right changes. But, I am now wondering if there may be some other way to make it more in-your-face about which space you are in. I also know this is a constant source of confusion for people new to CAD drawing.

But, I can't think of any setting that might make it more obvious to the user. First I thought of if there may be a way to toggle between black and white backgrounds. But, that is a poor choice, because you choose colors for layers based on the background, so that an important layer is bold. So, you might choose a dark blue if the background is white, but would choose yellow if the background were black. Then, I thought that if I was in a viewport, that the surrounding area would change color. But, the paperspace background color setting changes the color inside the viewports as well.

Any other ideas?

-Joe

martin@enco.us

I'd use a black background for model space and pick something like color 18 or 178 for the paper space background.

Joe Dunfee

I just tried that that, but the only setting I could find for changing the model space background affects only the model tab. In the situation I am talking about, I am on a layout tab, and sometimes work inside a viewport.

-Joe

Hans De Backer

A wild guess... is the color of the paper you print on white?
If so, I would use white (index color 7) for the paper space background (BKGCOLORPS), and some grayish tint for model space (BKGCOLOR), not a dark gray, but dark enough to easily spot the difference with white.

To ensure that entities can be distinguished against the current background, the BricsCAD (and AutoCAD) display engine will tweak colors of entities. An obvious example of this tweaking is index color 7 (white): from the moment the background color gets closer to white than to black, entities using index color 7 will automagically be displayed black instead of white.

Similar behavior is applied for other colors: depending on some threshold value, their 'native' color will be overruled.

Hence, to avoid surprises, it is helpful for paper space and model space background color to keep the 'lightness' of their tint in the same range, both light or both dark. This way, colors of entities will remain the same in both spaces.

Joe Dunfee

My BKGCOLORPS was already set to 7. I just tried what you suggested and set BKGCOLOR to 253. But, when I change into a viewport, the background stays white. BKGCOLOR seems to only affect the background when I am on the Model tab.

-Joe

Anthony Apostolaros

Use BKGCOLORPS for paperspace and viewports background color. Or search for "background color" in the Settings window and you can use the palette to select a color.

Joe Dunfee

Please explain how the BKGCOLORPS should help my situation, as I seem to be missing something. For example, when I change the BKGCOLORPS to be Red, and I am on a layout tab, the entire area of the paper is now red. This is true whether or not I am in paperspace, or have double-clicked into a view port, so that I am in model space. In both instances, the entire paper area is red.

When these settings were suggested, I was anticipating that once I clicked inside a viewport, that the area of the viewport would then take on the BKGCOLOR setting. But, it does not. The BKGCOLOR seems to only affect my model tab.

-Joe

martin@enco.us

I guess it shows that I don't use paper space or viewports. I was expecting the same change you did.

It would probably be possible to write a reactor which would detect the current mode and change either the crosshairs colors or BKGCOLORPS accordingly.

martin@enco.us

Maybe something like the following. I'm not an expert with reactors so there may be better ways to code this.

(defun monitorSysVar (rObject vName / error) ; vName is the list returned by the reactor
; First parameter is a string identifying the system variable name.
; Second parameter is symbol indicating whether or not the change
; was successful (T if successful, nil if not).
(defun error (msg)
(princ (strcat "\nError: " msg))
)

(if (or (= (car vName) "CVPORT")
(= (car vNane) "TILEMODE")
)
(if (and (= (getvar "TILEMODE") 0)
(> (getvar "CVPORT") 1)
)
(progn
(setvar "COLORX" 30)
(setvar "COLORY" 30)
(setvar "COLORZ" 30)
)
(progn
(setvar "COLORX" 7)
(setvar "COLORY" 7)
(setvar "COLORZ" 7)
)
)
)
)

(defun c:activateMonitor ()
(setq rObj (vlr-sysvar-reactor
"Monitor System Variable changes"
'((:VLR-sysVarChanged . monitorSysVar))
)
)
)

(defun c:deActivateMonitor ()
(vlr-remove rObj)
)

(setq MyReactor (vlr-dwg-reactor
"Reactor Document"
'((:vlr-beginDwgOpen . DwgBeginOpen))
)
)

;;; activate monitor by default
(c:activateMonitor)

Joe Dunfee

Wow, I had seen examples of reactors in action, but was not aware that doing something with a reactor was viable in LISP. Thank you.

I don't actually understand what all of the code is doing, but I am now motivated to read up a bit on reactors with LISP. We should also warn users that these programs will over-wright any existing values. I know the original XYZ axes were shades of Red Green and Blue, but I think they were a bit of a lighter shade.

I made a minor change to your LISP. Instead of changing the UCS colors, I changed the background color of paper space BKGCOLORPS from white [7] to grey [color 254]. There is one side-effect to my version. When you are inside a locked viewport and then zoom in or out, the screen flashes. I think this is because BricsCAD will temporarily change you to paper space for the zoom and then toggle back to model space.

The other thing I tried was to change the color of the command line background. But, I have not been able to figure out the color system in LISP. I have tried both the BricsCAD and Autodesk's reference on LISP, but could not find any explanation. Even the standard index color numbers don't seem to work for this variable.

When I use the setting dialog box, and change the color to a yellow, I see the decimal RGB values shown like this,
(255,255,128)

When I try to change it on the command line, I see the color in hexadecimal,
New value for CmdLineListBgColor, or . for none/<"#FFFF80">:

My lisp efforts have all failed. I tried
(setvar "CmdLineListBgColor" (255,255,128))
but this generates the following error
; error : no function definition <255,255,128> ; expected FUNCTION at [EVAL]

I also tried
(setvar "CmdLineListBgColor" "255,255,128")
and
(setvar "CmdLineListBgColor" "#FFFF80")
and
(setvar "CmdLineListBgColor" ffff80)

So, the random trial-and-error approach to learning LISP is not proving productive in this case.

Anyway, here is the version that changes the paper space background color, for those who are interested.

(defun monitorSysVar (rObject vName / error) ; vName is the list returned by the reactor
; First parameter is a string identifying the system variable name.
; Second parameter is symbol indicating whether or not the change
; was successful (T if successful, nil if not).
; Original program by H Martin Shoemaker  and modified by Joe Dunfee
; This version will set the background color of paper space to a light 
; grey when you enter a viewport and then to white when you exit.
; Note that any previous color settings are overwritten.

(defun error (msg)
(princ (strcat "\nError: " msg))
)

(if (or (= (car vName) "CVPORT")
(= (car vNane) "TILEMODE")
)
(if (and (= (getvar "TILEMODE") 0)
(> (getvar "CVPORT") 1)
)
(progn
(setvar "BKGCOLORPS" 254)

)
(progn
(setvar "BKGCOLORPS" 7)
)
)
)
)

(defun c:activateMonitor ()
(setq rObj (vlr-sysvar-reactor
"Monitor System Variable changes"
'((:VLR-sysVarChanged . monitorSysVar))
)
)
)

(defun c:deActivateMonitor ()
(vlr-remove rObj)
)

(setq MyReactor (vlr-dwg-reactor
"Reactor Document"
'((:vlr-beginDwgOpen . DwgBeginOpen))
)
)

;;; activate monitor by default
(c:activateMonitor)

-Joe Dunfee

martin@enco.us

The problem with (setvar "CmdLineListBgColor" ...) looks like a bug. Changing the setting in the settings > settings dialog works immediately, but the lisp command changes the color only when Briscad is restarted. "CmdLineEditBGColor" is the same. (setvar "CmdLineListBgColor" "#FFFF80") should be the correct syntax.

I don't think the screen flash is related to changes of space because if I change your code to change both BKGCOLOR and BKGCOLORPS the screen still flashes. My guess is that there are layers that are faded due to being locked and the locks are taken off (removing the fade) then reapplied.

Roy Klein Gebbinck

@Joe Dunfee: you have a typo ('vNane') in your code.

Joe's analysis of the screen flashing is correct. If an active VP is locked BricsCAD will temporarily switch to PS when zooming or panning. This means the CVPORT variable changes and the reactor callback responds to that change.

Roy Klein Gebbinck

... Doing a quick test I notice that when changing from PS layout to PS layout, a change to the CVPORT variable does not trigger the sysvar reactor. So it is wise to also monitor changes to the CTAB variable.

Joe Dunfee

I thought I posted the following message on the 15th, but for some reason it did not take. When I came back to the discussion, it was apparently saved as a draft, and that made it obvious that it did not post, and I didn't even have to re-type it. Nice feature.

I will pass your info on this possible bug to support.

They have already responded that it is now fixed. Though, I am not clear when that fix will be released.

-Joe

Joe Dunfee

Wow, giant font for some reason on that last reply.

Anyway, thank you Roy for your expert effort.

-Joe