Hi Eric
Following my earlier email on this I have done
some testing with MapInfo version 6.5 and version 8.0.
When I first encoutered these problems about
eight years ago I am 99% sure that a MapInfo workspace could not remember the
setting for display off and a zoom layering setting. In other words a user
could NOT open up a workspace with display off and then when turning on the
display immediately get zoom layering from a saved setting in the
workspace.
Testing this on both 6.5 and 8.0 this morning this
is now possible! In other words you are remembering quad state for zoom layering
and I believe this is what users want with zoom layering - AND with style
override.
The reason it works with zoom layering is that as
well as the display setting of ON, GRAPHIC and GLOBAL. The Zoom layer line can
be:
Zoom (1,1000) Units "km" Off
or
Zoom (1,1000) Units "km"
The absence of the word Off is interpreted as on
and therefore you are holding the four possible values for
Display on Zoom Layering On
Display off Zoom Layering On
Display on Zoom Layering off
Display off Zoom Layering Off
Therefore could the solution to the style override
be dealt with in a consistent manner by adding the word Off to the end of the
style override line ie
Global Pen(1,2,0) Line (1,2,0) OFF
If I am correct that earlier versions ( 8 years
ago) did not have the quad state for Zoom Layering then you have at some time
added the OFF option to the Zoom Keyword and this did not cause problems to the
interpreter in older versions?? ( Unfortunately I have not got version 4.5 or
similar loaded to test this ).
I think it would be good that the zoom layering and
the style override work in a consistent way and personally I think quad state
like the current zoom layering would be the best for users.
Regards
Bob
MapsByDesign
----- Original Message -----
Sent: Saturday, October 21, 2006 8:40
PM
Subject: Re: [MI-L] MI: Style Override
Bug
Lars and all,
This bug has nothing to do with the fact
that a workspace is a script/macro. And the decision of whether to write out
unused properties is always a judgment call and again has nothing to do with
the structure of a workspace. In this particular case, the unused style
properties are written out! So, the issue is not the properties of the style
overrides but rather that the knowledge of the style override flag is not
written out. Here's a snippet of the MapBasic in the workspace.
Set Map Layer
1 Display Off Global
Pen (1,2,0) Brush (2,16777215,16777215) Symbol
(51,0,12,"MapInfo
Oil&Gas",0,0) Line (1,2,0) Font ("Arial",0,9,0)
All the styles of all four
types (area/region (brush and pen), line(pen), point(symbol) and text(font)
are written out. Note that this practice is quite old and has
occasionally been called into question. A customer some time ago wanted
to know why their default styles (set in preferences) were not taking effect.
The reason was that they had loaded an old workspace that had these unused
override styles in them. However, I digress.
The problem in this case is that the MapBasic for
handling visibility and style override do not match the capabilities of the
user interface! The possible options after Display are Off (invisible),
Graphic (visible use styles from data) and Global (use style override). This
tri-state model does not support remembering whether a style override was ever
used. When a workspace is read in with the Off state and the user enables the
visibility checkbox, the code essentially takes a guess and turns it back to
Graphic. You can all see this from the MapBasic window.
Therefore, to fix this problem, the
MapBasic would have to be enhanced to allow a new Boolean property
(styleoverride?) that would hold this state and the visibility state would
just be Off and Graphic (or Off and On). We could change MapInfo
Professional to always write out the new syntax which would push up the
workspace version. However, this might happen for other reasons in that
release so that might not matter.
When we do this, we try to handle backward compatibility as best we
can. We would continue to understand the old syntax (Global and even Graphic)
and I suppose could even support the redundant Global and StyleOverride On
states. Using Global and StyleOverride Off would certainly be an error.
This would mean that any existing workspaces are not going to see an
improvement, just new ones. Whenever we change these things, all the possible
states have to be looked at, so there may be a hole in some of this. One thing
we try to avoid, but can do, is check the version of the MapBasic program or
workspace and decide what syntax is appropriate. However, this has a
shortcoming in that folks with large programs who recompile for a newer
version would get an error if they used the old syntax. So, we try and stay
away from this if possible.
Just
to complicate things (I seem to be good at that), there is another layer
property that I think should be a tri-state and is not. Perhaps this is
because Global/Graphic was already there. This is the layer zoom property! It
has always seemed to me that layer visibility is a tri-state logically. The
layer is either always visible, never visible or maybe visible. A perfect
tri-state! So, to make sure that a layer is visible, one must turn Visibility
on (Graphic or Global) and then make sure that zoom is off. You can forget
that last step the layer might be visible or it might not. It would seem that
the thought process to layer visibility is precisely tri-state. We certainly
could always write out the zoom values whether in use or not. In fact, we
could do that today but for whatever legacy reason don't.
Anyway, I hope this helps to explain the style override
issue. If you have any comments... well, you will anyway!
Eric Blasenheim Principal Software Architect MapInfo Corporation
P.S. I
saw the issue about DLL Loading (dependent dlls) and I have a reply almost
ready. Short answer is that this has nothing to do with networks or timing but
is related to a not very user friendly aspect of the Windows API but
nevertheless looks like something that can be fixed on our side. I am totally
shocked that this has not come up before. I mean this has been this way for
many years! Don't go looking for IT network solutions. It is just that when
DLL loading was implemented eons ago, this situation was not taken into
account. So, if a software program has a fault in it that is not
discovered for 10 years, is it really a bug? As soon as I verify all
this I will send the details.
Mail List:mapinfo-l-bounces
From:
| "Lars I. Nielsen (GisPro)"
<[EMAIL PROTECTED]> on 10/21/2006 11:28 AM ZE2
|
To:
| mapinfo-l@lists.directionsmag.com
|
cc:
| mapinfo-l@lists.directionsmag.com
|
Subject:
| LinkRe: [MI-L] MI: Style Override
Bug | Well, it's debatable
whether it's a bug or a wad.
A workspace is a macro to rebuild a
specific setup. Are unused settings part of such a setup ? Yes and no,
imho, it's unclear where the dividing line is.
But it would be nice
to have a workspace remember style override settings, even if unused,
especially since it wouldn't change the end result one bit, and would be
extremely simple to implement (just output them!).
Well, with
MIPro.COM apparently again in the front seat, maybe a feature wish list is
relevant once again ?
Best regards / Med venlig hilsen Lars I.
Nielsen GisPro
Jacques Paris wrote: > It was for sure
part of version 7.0 > > Jacques Paris > >
-----Original Message----- > From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Peter
Horsbøll > Møller > Sent: 20 octobre 2006 05:42 > To:
Jaromir Svasta; mapinfo-l@lists.directionsmag.com > Subject: RE: [MI-L]
MI: Style Override Bug > > Jaromir, > > I know for
sure that this bug has already been reported and registered. I reported it
last week - and also some years ago... > > Peter Horsbøll
Møller > GIS Developer, MTM > Geographical Information &
IT > > COWI A/S > Odensevej 95 > DK-5260 Odense
S. > Denmark > > Tel
+45 6311 4900 > Direct
+45 6311 4908 > Mob
+45 5156 1045 > Fax
+45 6311 4949 > E-mail
[EMAIL PROTECTED] >
http://www.cowi.dk/gis > > -----Original Message----- >
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jaromir
Svasta > Sent: Friday, October 20, 2006 10:43 AM > To:
mapinfo-l@lists.directionsmag.com > Subject: [MI-L] MI: Style Override
Bug > > Hi listers, > > I would like to report a bug
in MI (v7.8): > The checking of the style override for a map layer is
not preserved in workspaces for layers made temporarily invisible. To >
reproduce this behaviour, check the style override checkbox for a map layer,
then make the layer invisible by switching the > visibility checkbox
off, save the workspace, close all and reopen the workspace. After switching
the visibility of the layer on > again, look at the style override
checkbox in the display options - you will find it unchecked. The problem may
seem petty, but in > my work I often come into situations that requires
me to switch this checkbox back on hundred times a day. Quite
painful! > > -- > Jaromir SVASTA >
Hydrogeologist > Geological Survey of Slovak Republic > Mlynska
dolina 1 > 817 04 Bratislava > Slovak Republic > >
Tel: +421 2 59375326 > Mobile: +421 908783589 > Fax:
+421 2 54771940 >
_______________________________________________ > MapInfo-L mailing
list > MapInfo-L@lists.directionsmag.com >
http://www.directionsmag.com/mailman/listinfo/mapinfo-l > > > > >
_______________________________________________ > MapInfo-L mailing
list > MapInfo-L@lists.directionsmag.com >
http://www.directionsmag.com/mailman/listinfo/mapinfo-l > > > > >
_______________________________________________ > MapInfo-L mailing
list > MapInfo-L@lists.directionsmag.com >
http://www.directionsmag.com/mailman/listinfo/mapinfo-l > >
_______________________________________________ MapInfo-L
mailing
list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
_______________________________________________ MapInfo-L mailing
list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
|