Sergey Brin @ UC Berkeley

Check it out, interesting talk provided by youtube.com:

http://youtube.com/watch?v=Ka9IwHNvkfU

Using a ScaleDependentRenderer in a FeatureGraphicsLayer?

I was looking for a relationship between the classes FeatureGraphicsLayer and ScaleDependentRenderer. I could not find it in the EDN website. This is why I was looking for this: say you have a FeatureGraphicsLayer in which you want to draw features using a ValueMapRenderer. This is all OK since a ValueMapRenderer is "type of" IRenderer which is used by the FeatureGraphicsLayer.

However, what if you want to draw those features with a height/width that changes according to the scale? There is no IScaleDependentRenderer in the WebADF API. Philip Thompson posted a suggestion here:

http://forums.esri.com/Thread.asp?c=158&f=2276&t=245890#751096

Basically, we can extend his code snippet to set the Renderer on-the-fly everytime the ScaleChanged() method of the class Map is triggered. In this case, the Renderer will be set according to the scale. Thanks Philip!

protected void Map1_ScaleChanged(object sender, ESRI.ArcGIS.ADF.Web.UI.WebControls.ScaleEventArgs args)
{
if (args.NewScale > 4000)
{
foreach (MapResourceItem item1 in this.MapResourceManager1.ResourceItems)
{
if (item1.Definition.DataSourceType == "GraphicsLayer")
{
item1.DisplaySettings.Visible = false;
// OR RESET THE RENDERER AS WELL
}
}
}
if (args.NewScale < 4000)
{
foreach (MapResourceItem item1 in this.MapResourceManager1.ResourceItems)
{
if (item1.Definition.DataSourceType == "GraphicsLayer")
{
item1.DisplaySettings.Visible = true;
}
}
}
}

IServiceProvider error: ambiguous symbol message

I have been working on porting code from VS2003 to VS2005. The last error message I received before being able to compile it was:

error C2872: 'IServiceProvider' : ambiguous symbol

Lucky me, this error is well documented. The solution was moving the #include to the top of the file. It works for me and I did not look further on the cause of this error. However, it seems this symbol may be declared in more than one file.

This is one area where Microsoft could follow ESRI's approach. ESRI does not declare repeated names, it adds a number to the end of the class that can be incremented, i.e. ISpatialReference, ISpatialReference2, ISpatialReference3. Note that ESRI is actually extending a class with each increment and Microsoft may not be doing that.

OSG scene viewed inside a .NET control

This is an interesting challenge. This is what I did: I created two threads, one for the main form and one for the OSG loop. This second thread shall run a method that receives a handle as a parameter. This handle can be either a handle to the form or a handle to a control (i.e. Panel) and is assigned as follows:

new osgViewer::GraphicsWindowWin32::WindowData(hwnd);

The method that is run by the second thread contains the usual instructions to render a scene in OSG. Of course, this is done in C++ and called from C#.

I run into a problem while doing this: it is not possible to access a control "from other than the thread it was created on" (Cross-thread operation error). After doing some investigation I found this can be fixed using:

CheckForIllegalCrossThreadCalls = false;

Still, this is a quick fix and I do not think is the solution for a commercial app. Visual Studio 2005 has more checking than Visual Studio 2003, therefore if you are running 2003 you might not receive this error.