Hi Eric
When I encountered these two problems it seemed
that they behaved "quad state" with MapInfo Professional.
For example the zoom layer issue seems to be able
to be:
Display off and without zoom
layer set
Display on and without zoom
layer set
Display off and zoom layer set
Display on and zoom layer
set
One possible solution for a future MapInfo that
would be backward compatible would be to use a comment line. For example if the
user wanted to save zoom layering set but display off a line could be
written out:
! OFF ZOOM ( 0, 500 ) Units
"m"
Older versions of MapInfo would ignore this
particular comment, allowing backward compatibility. Newer versions could
interpret it however you design it. The above example would open up with
visibility off but if the user turned on visibility it would be with zoom layer
set.
A comment line starting "!" that isn't a newly
defined command could still be ignored allowing "forward backward
compatibility".
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
|
