ThinkGeo.com    |     Documentation    |     Premium Support

Error when querying both CustomOverlay and StaticOverlay !?

#1

I've been away from Map Suite for a while, but is now back in force :-)


I've of course downloaded the newest build, and immidiatedly ran into a new error in my sample app that previously worked :


 



If you use the CustomOverlays collection you may not at the same time use the following properties:  BackgroundOverlay, StaticOverlay, DynamicOverlay or MarkerOverlay.  CustomOverlays was designed to replace these so that you can implement as many overlays as you need in any order.  Trying to use CustomerOverlays and one of the properties above is not allowed as there is not a definitive logical order we could draw them in.  Please reference to the documentation of CustomOverlays property for more information.



 


I'm actually just trying to query for content in the collections. I do understand that this error will fire in case I'm trying to alter any information in both collections, but I'm not altering anything


So this error seems a little harsh to me, since it makes it virtually difficult to build applications that handles both cases, e.g. in the case when some external routine loads the map (either as customoverlay or as static/dynamic), and the application should be able to handle both without knowing which was used in advance.


My setups will almost always include some sort of backdrop, usually WMS, but I can't count on that always being the case.


Please advise.


 



#2

Lars, 
  
   Sorry if you thought the message was harsh, we didn’t intend it to be bad.  What wanted to express was that when we first designed the system we had Static and Dynamic overlays and we also has custom overlays.  We had a Refresh and a RefreshDynamic and the idea was you put the static stuff in the static etc…  The problem we ran into was that people disagreed in what order the custom overlays would draw.  They didn’t like the fact they had to refresh all of their dynamic overlays at once.  It seemed to cause allot of confusion.  The static and dynamic stuff was meant to be an easy way for people to use the system but we found very few people we talked to were doing something easy.  They also didn’t like the multiple refresh APIs and we ran into issues in some scenarios.  Actually much of this affected the desktop edition as well. 
  
   What we wanted to do is to draw a line between using the Markers, Static & Dynamic etc and the the CustomOverlays.   
 If you want total control use just the CustomOverlays, if the buckets we created work well then use this but don’t mix and match.  I hope this makes sense and sorry if the error came off harsh. 
  
 One thing we could do is to re-word this and make it a warning instead of an error so it won’t stop you.  We would also need to determine where the CustomOverlays draw.  I would guess after the static but before the dynamic but some people don’t like that either. 
  
 David

#3

I’m afraid you’ve misunderstood my point. The harshness I’m talking about is not the wording of the error, but the rigid distinction enforcement. 
  
 To throw a fatal error just because you’re accessing the “other” objects, for querying, not changing anything, is what’s harsh in my eyes. I totally agree, that there must be a distinction between the two sets (if technically necessary), but it ought only be enforced this rigidly when you’re changing things. A “read-only” access should be allowed across the board, is what I ask for. 


#4

Lars, 
  
   I see.  I agree with you there.  What we will do is to reword the error and make it a warning instead.  This way you get the warning but you can implement your code any way you want.   
  
 It is not really possible for us to make a distinction between read and write into the collection using the obsolete markup in Visual Studio.  When you add to a collection that is exposed as a property it is a read of the collection property and then the write is to the collection itself and we don’t want to put anything in there. 
  
 I think just making it a warning and allowing it with a better warning message is the way to go. 
  
 David

#5

Hi David, 
  
 Thanks. I assume that this will allow me to suppress the proposed warning in case I need to query into both sets of collections ? 


#6

Hi,


This morning I got a auto-notification mail, saying that Yale answered this topic - an answer I can't seem to find here - saying that this topic's error had been resolved in build 299.


Today I downloaded and installed build 299, but the error remains. I've even now wrapped the calls to both collections in separate Try-Catch constructs, but to no avail.


Please advise.


 



#7

Lars I, 
  
 Yesterday I thought you were using the Destkop Edition, so I tested against desktop with version 3.1.299 and verified that this problem has gone in this release.  
  
 Later, I relized that I was making a mistake you are using the Web, so I delete my message. Sorry for making you confusing. 
  
 Thanks. 
  
 Yale 


#8

Lars, 
  
 The exception message leads users to the right direction to fix the real problem. If we change it to a warning, it may hide the real error so that more users may encounter the same issue but cannot figure out why. I don’t think anyone will publish the online application with a suppressed error. I hope you understand. 
  
 Please let me know how do you think so that we can have a plan to modify our strategy. 
  
 Thanks, 
 Howard

#9

 If we change it to a warning, it may hide the real error so that more users may encounter the same issue but cannot figure out why. I don’t think anyone will publish the online application with a suppressed error. I hope you understand. 



Please let me know how do you think so that we can have a plan to modify our strategy. 




I’m afraid I don’t understand, Howard. Barring programmers from using certain parts of the object model is not good practice imho. Programmers always bear the full responsibility of the code they’re building regardless, but this absolutely requires that the tools they use (which is what MapSuite is) shouldn’t trip them unexpectedly or in an undue fashion, as this is really considered unstable behaviour.


There are a multitude of ways to help the programmers keep a tight development, e.g. by simply having them set appropriate switches. “Option Strict” in VB is a fine example, the point being, that such settings are optional, not hardcoded. In the case of MapSuite, why don’t you similarly just add some sort of switch to control this ? E.g. “Map.OverlayMethod” = -1,0,1,2, where -1=no warnings nor rendering, 0=as now (default), 1=allow only staticoverlay/…, 2=allow only customoverlay; and use this setting (when changed or when rendering) to throw errors/warnings and to determine rendering choice.


I’m trying to facilitate building a file based “workspace loader”, and the strategy you’ve chosen on this issue effectively bars this development. The user application can’t know in advance what sort of setup is included in the workspace file it loads, and it must also be able to clear “the other” overlay settings (e.g. as a result of a previously loaded workspace) to allow for entering another setup. In the current build this is impossible in MapSuite WebEdition.


Yale mentions that this rogue fatal error has been removed in the desktop edition, but it’s not really professional to require end-users to have to purchase one edition to circumvent the shortcomings of another, is it ?


I’m sorry if all this sounds a little rough, but this issue represents a major irritation and stumbling block to us, one that do force us to rethink whether MapSuite is indeed the right choice for our needs.


 



#10

Lars, 
  
 I see. Technically, I totally agree with your idea. But StaticOverlay and CustomOverlays is one of the patterns in our products. Users can write one line of code to add a Layer (use StaticOverlay which I called DefaultOverlay below); also they can write several code to add a Layer as well (use CustomOverlay). The advantage of the DefaultOverlay is that the code is quite simple but has some limits that the map maintains only one StaticOverlay. While using the CustomOverlays need more code, but maintains as many static overlays as you want. You idea is such a good suggestion and I agree with your pattern; we need to discuss it with our manager very carefully whether we need to change the strategy. 
  
 On the other hand, could you tell us more detail about your “workspace loader”? Maybe, we can have a workaround for your application. 
  
 Thanks for your patient and ideas and looking forward your feedback. 
  
 Thanks, 
 Howard 


#11

Hi,


It's basically just something along these lines:



Public Function SaveAsWorkspace(ByRef CurrentMap As Map, ByVal pthnam As String) As Boolean
    'Dim dom As New XmlDocument()
    dom = New XmlDocument()

    Dim root As XmlNode = dom.CreateElement("MapSuiteWorkspace")
    AddNodeAttribute(root, "Name", "my workspace")
    AddNodeAttribute(root, "CreatedAt", Now.ToString())

    dom.AppendChild(root)

    '-  Configuration

    Dim config As XmlNode = dom.CreateElement("Configuration")
    root.AppendChild(config)
    
    '... insert configuration details

    '-

    Dim statix As XmlNode = dom.CreateElement("StaticOverlay")
    root.AppendChild(statix)

    For Each lyr In CurrentMap.StaticOverlay.Layers
        Dim xlyr As XmlNode = dom.CreateElement("Layer")

        AddNodeAttribute(xlyr, "Name", lyr.Name)
        AddNodeAttribute(xlyr, "Type", lyr.GetType().ToString())

        '... insert layer details

        statix.AppendChild(xlyr)
    Next

    '-

    Dim dynamix As XmlNode = dom.CreateElement("DynamicOverlay")
    root.AppendChild(dynamix)

    For Each lyr In CurrentMap.DynamicOverlay.Layers
        'Dim xlyr As XmlNode = CreateLayerXml(lyr)
        Dim xlyr As XmlNode = dom.CreateElement("Layer")

        AddNodeAttribute(xlyr, "Name", lyr.Name)
        AddNodeAttribute(xlyr, "Type", lyr.GetType().ToString())

        '... insert layer details

        dynamix.AppendChild(xlyr)
    Next

    '-  Overlays

    Dim customx As XmlNode = dom.CreateElement("CustomOverlays")
    root.AppendChild(customx)

    'Dim ovl As Overlay
    For Each ovl In CurrentMap.CustomOverlays
        Dim xovl As XmlNode = dom.CreateElement("Overlay")
        AddNodeAttribute(xovl, "Type", ovl.GetType.ToString())

        For Each lyr In ovl.Layers
            Dim xlyr As XmlNode = dom.CreateElement("Layer")
            AddNodeAttribute(xlyr, "Name", lyr.Name)
            AddNodeAttribute(xlyr, "Type", lyr.GetType.ToString())

            '... insert layer details

            xovl.AppendChild(xlyr)
        Next

        customx.AppendChild(xovl)
    Next

    Try
        dom.Save(pthnam)
    Catch ex As Exception
        Return False
    End Try

    Return True

End Function

 



#12

Hi,


I think there is a work around for this problem in the current version of WebEdition, which is checking the DynamicOverlay and StaticOverlay first. If both of the dynamic and static overlays are null, then access the customer overlays collection. The code could be like this:

If Map1.StaticOverlay IsNot Nothing OrElse Map1.DynamicOverlay IsNot Nothing OrElse Map1.BackgroundOverlay IsNot Nothing OrElse Map1.MarkerOverlay IsNot Nothing Then
    ' process static and dynamic overlays.
Else
    For Each overlay As Overlay In Map1.CustomOverlays
        Dim layerOverlay As LayerOverlay = TryCast(overlay, LayerOverlay)
        For Each layer As Layer In layerOverlay.Layers
            'process the customer overlays collcetion.
        Next
    Next
End If

Sorry for the inconvenience and any more questions please let me know.
Thanks,
Sun

#13

Hi Sun,


Ok, I can test the collections for existence without triggering the fatal error ?


That sounds great, and is actually what I need to know in my current timeframe.


However, I still would like to submit my previous suggestion about a developer managed switch as a feature request.


 



#14

Lars,


I think I made a mistake in my last reply, even checking the static and dynamic overlays can not work around this problem, sorry about that. And about your suggestion, we are discussing this feature with our director, and we need more time to make a decision.
Sorry for the inconvenience. Any more questions please let us know.
Thanks,
Sun