Latest Contributions by RobertMaddox

No problem. I didn't really notice the PrintAndExport part until after you posted your previous reply, and I'm just not that familiar with that area of ArcObjects to recognize it as such. And my comment about the "paper" variable was just that I found it very comical that you explained what "strPrinterName" was, even though it would be fairly obvious to a programmer based on commonly used naming conventions, but that the "paper" variable, which doesn't have an obvious naming convention, was not explained. Though if I knew more about that area of ArcObjects, naming a variable "paper" and using that variable to define what printer you want to use, might not seem so weird. ... View more

My apologies. I didn't see anything in your question that sounded like you were talking about code, so I just assumed you must have been talking about just printing from ArcMap - which is admittedly confusing as well, since you would normally expect to be able to select the printer straight from the Print dialog. LOL I'm glad you were able to find the answer, but I have no idea what "paper" is in your code snippet. ... View more

Are you talking about causing a map to print from code, or are you talking about just printing from within ArcMap? Assuming that you meant the latter, you click "Print..." to open the Print dialog. At the top of that dialog, it will show you the currently selected printer, which is likely your default printer. There's also a "Setup..." button in the top right. Click that and it'll bring up the "Page and Print Setup" dialog. At the top of that dialog is a drop down list that has all your installed printers listed. Use that to choose a different printer. You can then access the printer properties with the "Properties..." button, change the orientation, paper source, etc. I'm using ArcMap 10.1, if that makes any difference, but I'm guessing it would be about the same for most any recent version. ... View more

I'm not sure about this particular usage, but XSL is the XML Stylesheet Language, which is written in XML and used to process / transform XML. See more about it here: XSL Languages‌ Now how ESRI is using XSL in this particular case, I do not know. Is this "WMS response" you mentioned using XML? If so, then you might be able to just use XSL (XSLT or XSL-FO) to manipulate the XML response in whatever way you wish. Otherwise, it might be something else entirely. Hope that helps some. ... View more

Leo, my man. I was just trying to help out tomalley23 on his question and found out he's using Java ArcObjects. That led me to go to the docs and now I understand why you were so insistent to begin with that the OP create a new object! LOL Apparently you can't get an actual Workspace from an IWorkspaceFactory and you have to do something like this example from the docs: IWorkspaceFactory rasWkspFactory = new RasterWorkspaceFactory(); IWorkspace wksp = new RasterWorkspace(rasWkspFactory.openFromFile(aPath, 0)); That is so unbelievable! LMAO Seriously glad I don't have to do stupid stuff like that. You deserve some serious props, man. I thought to begin with that it was just a philosophical dislike for working with interfaces all the time in ArcObjects and you just hadn't gotten into the whole mentality of how ArcObjects is designed. But now I see that the Java ArcObjects is this crazy stupid thing where you'll get an exception if you just use `IWorkspace wksp = rasWskpFactory.openFromFile(aPath, 0);` even though the docs say that openFromFile returns an IWorkspace! WTF! It seriously blows my mind! LMAO My coworkers must think I'm losing my mind right now cause I've been laughing so hard. Anyways. Would you mind taking a look at tomalley23's question? I know I can't help him out with that at this point. And I'm going to make sure to state on my resume next time I'm looking for a job that even though I know Java and I know ArcObjects, I do NOT know Java ArcObjects! 😉 Good times, buddy. :cool: ... View more

Oh, so you're using Java... *Looks at the docs for the Java version of Workspace* *facepalm* OMG. I am so glad I don't do anything with ArcObjects for Java. I thought they were equivalent, but they apparently aren't. Sorry man. I can't help you any further on this one. I don't want to touch anything that looks like this statement that I just read in the docs. public Workspace(Object obj)           throws IOException Construct a Workspace using a reference to such an object returned from ArcGIS Engine or Server. This is semantically equivalent to casting obj to Workspace. Casting to this class from the return value of a method will not work, as this class represents an abstract class in ArcObjects. * Workspace o = (Workspace)obj; // will not work Workspace o = new Workspace(obj); // Use this constructor instead * @param obj an object returned from ArcGIS Engine or Server Throws: IOException - if there are interop problems Workspace theWorkspace = (Workspace) obj; So you can't cast the object to an IWorkspace, you have to construct a new object to cast it? No thank you. C# FTW! LOL I hope someone else could help you. Maybe ldonahue will come give you a hand, since he apparently understands Java ArcObjects better than I do. Good luck with that. 😉 ... View more

Every once in a while I get into conversations like these.  It usually starts and ends the same way every time where someone wants to get in a word battle with me over what did you call it - academic meanings?  I'm just using the standard language that is out there and I always run into people who what to use a different language (not programming language) in which to communicate.  If you have a better word for my use of the word "implement" for classes that need to provide the guts to the method signatures in Interfaces, let me hear it.  I'd be glad to consider to start using it. I must admit that I'm not sure what exactly this is in response to in my last message. It would fit much better as a response to previous messages, though as I recall, I made a similar statement about having a "silly academic debate about the meaning of the word 'implement'". I don't really think that's what's happening though as I've already conclusively proven that the cast to IBoundsProperties was successful and thus both the ILegend2 and IBoundsProperties interfaces (and thus all of their members) were in fact implemented by the OP's object. So I think we are in agreement over the meaning of the word in this context. The only possible point where we could disagree about this at this point would be if you argued that a class that implements a property by causing it to throw a NotImplementedException (which is what Visual Studio does when it stubs them out) is not actually implementing the property or interface. While true that it is not a useful implementation and should never happen in production code, it isn't true from the perspective of the programming language itself. Nor is it something that can ever be tested for, like you can test whether or not an object implements an interface. It could only be discovered by attempting to use that property and catching the exception. Documentation could also help, but I haven't found anything in the docs that mention anything about this property being unsupported for legends like what I found for ILabelEngineLayerProperties in another thread (http://forums.arcgis.com/threads/114312-how-to-obtain-ILabelEngineLayerProperties2-and-error-calling-it-s-method) - which should have been handled with a NotSupportedException, not a NotImplementedException. Now, I tried to reproduce the issue that the OP was having, but I couldn't get it to throw an exception. I also couldn't get it to work either though, FixedAspectRatio remained true even after setting it to false. I am running on 10.1 though, so perhaps they changed the implementation between 10.0 and 10.1. *shrugs* I think if people "want" to add default methods to Interfaces, then maybe they should be looking at extending an Abstract Class for that instead.  Abstract Classes can have "implementation" code in their methods.  And, since you can re-declare and re-define the default methods in Interfaces, what would be the point?  You would be breaking the intent of having a default method in Interfaces in the first place. One thing about abstract classes though is that sometimes you don't have the option of choosing what you inherit from. For example, if I wanted to add a function BlinkingText to certain controls, like TextBoxes and Labels which would cause their text to blink for 3 seconds and then I also wanted it to work on my Form so that the title of the form would blink, there's no where in the inheritance hierarchy that I could put an abstract class that all three of those could inherit from. If however I could define an interface that says that it has a Text property (which all three classes have already) and then defines my function with a default implementation that causes the Text to blink for 3 seconds, then all I would have to do is add that interface to my classes that inherit from those three classes and everything works. Now, I can already achieve this simple functionality in C# using extension methods, but this was just a simple example to illustrate the inheritance hierarchy problem, which can't always be handled as easily. Regardless, I've enjoyed our discussion (despite a couple rocky points) and I hope you have too. 😉 ... View more

Why are you calling `new Workspace()`? That shouldn't even compile as Workspace doesn't have any public constructors (hence the reason for IWorkspaceFactory). I'm guessing maybe you have some kind of wrapper class that you've named Workspace. If that's the case, I strongly recommend renaming it. It's just too confusing and causes namespace collisions. You'd be better off naming it something more appropriate to what it actually does, like WorkspaceWrapper or WorkspaceHelper. (Edit: There's actually a class called WorkspaceHelper too, so scratch that one...lol) The other thing I would check for is to make sure that you can actually open the workspace from within ArcMap so that you can see if it just isn't a valid workspace. One other thing I would suggest is leaving out the wrapper classes and just use ArcObjects code and see if you get different results. ... View more

Try replacing your code with the following: IGeographicCoordinateSystem m_geographicCoordinateSystem = new SpatialReferenceEnvironment().CreateGeographicCoordinateSystem(esriSRGeoCSType.esriSRGeoCS_WGS1984); IWorkspaceFactory m_workspaceFactory = new FileGDBWorkspaceFactory(); IName workspaceName = m_workspaceFactory.create(workspacePath, gdbfileName, null, 0) as IName; IFeatureWorkspace m_workspace = workspaceName.Open() as IFeatureWorkspace; IFeatureDataset featureDataset = m_workspace.createFeatureDataset(name, m_geographicCoordinateSystem); See if that changes anything. 😉 ... View more

Your auto-properties example works on classes, not Interfaces.  Interfaces are abstract and only define method signatures.  You can't instantiate an Interface, so if there was some kind of functionality provided by an auto-property inside an Interface, you would be breaking the nature of an Interface. I was merely talking about the "nothing between the curly braces" comment because auto-properties have nothing between the curly braces and look exactly like a property definition on an interface: `public bool FixedAspectRation { get; set; };` That's it. A complete no-code implementation. Because the forums shouldn't be vending machines for code samples.  Why can't I answer the question the way I want to? Not saying they should be or that you can't do whatever you want. Just saying that code samples are more helpful than abstract comments about programming. "A code sample is worth 1024 words!" -Me 😉 But at the end, he got a NotImplementedException because he assigned an Interface type (ILegend) which does not implement or even define FixedAspectRatio to a reference variable type of IBoundsProperties which does.  The compiler is going to check the actual type of the reference and tell you: "hey, FixedAspectRatio is not implemented on the object type you have currently". Actually, you're wrong. First off, it wouldn't be the compiler because it's happening at Runtime and because the compiler by definition could never know whether or not two interfaces could be implemented by the same class or not. (Now who's quibbling, right? LOL ;)) The other reasons get to the point of why I said I didn't really expect a non-C# programmer to understand it. First of all, the NotImplementedException is never thrown by the CLR. It is in fact a lazy man's implementation. (See this topic on SO: http://stackoverflow.com/questions/410719/why-does-notimplementedexception-exist) Also, with the code `IBoundsProperties bounds = legend as IBoundsProperties;`, bounds will either be an object of a type that implements IBoundsProperties, or it will be null. If the code was written as `IBoundsProperties bounds = (IBoundsProperties) legend;` then you would get an InvalidCastException if the cast failed. The `as` operator is the conditional cast operator in C# and it will first check to ensure that the cast is valid before doing it and if it isn't valid, then it will return null. That's why I said that that it would have been a NullReferenceException if the object in question did not implement either ILegend2 or IBoundsProperties. I will also say though that, even though the casting from IMapSurround to ILegend2 was not a safe cast and should have been tested for null to make sure that the casting worked, the casting from ILegend2 to IBoundsProperties was completely safe since we know from the docs that the only class that implements ILegend2 is LegendClass_2 (http://help.arcgis.com/en/sdk/10.0/vba_desktop/componenthelp/index.html#/LegendClass_Class/000t00000s06000000/) and that class also implements (though poorly, as this case has shown) IBoundsProperties. Therefore, it would not be necessary to test for null after this cast. And even though that could change in a later version, you'll still have to deal with issues when moving to a new version no matter what. I disagree with you on the IGeometryInterface.  Why couldn't it be possible for someone to create their own special geometry class that wants to provide implementation for the methods defined in the IGeometryInterface?  Just because you don't do it, doesn't mean someone else might not want to. Well, you're free to do whatever you want... But when dealing with real world ArcGIS programming, why would you ever want to? You couldn't assign any of your MySpecialGeometry objects to a feature, nor could they be drawn on the map. So what's the point? You can define constants in Java Interfaces now and people abuse them. You can do that too, but I was talking about the default method implementations where you can write out the code for methods that are defined in the interface. Thus your class wouldn't have to provide an implementation for that method when it implements the interface. Would you consider that to be "breaking the nature of an interface" as you stated auto-properties in an interface would be? I know it's a hotly debated issue in some circles, but I personally think it's a pretty cool idea that gets rid of a lot of boilerplate code and annoying tedium in Java. Next they just need to add true properties instead of having getters and setters everywhere. 😉 ... View more

CoClasses "implement" the behavior defined by the Interface.  Interfaces only define a contract, there is nothing between the curly braces, i.e. no implementation. :rolleyes: I am not going to get into some silly academic debate about the word "implement". I am a programmer by trade, not a GIS person, so I understand completely how interfaces work and don't need the idiots guide link to MSDN, Thank you very much. The point was that there was a property on the interface which means that the property must exist on any class that implements the interface. Whether there's anything "between the curly braces" in the source code or not is completely irrelevant because for all we know, they could be auto-properties. (Here's a link to MSDN for you: http://msdn.microsoft.com/en-us/library/bb384054.aspx) It is correct to use Interface types as reference variables, but what I was trying to tell the original poster is that you cannot expect to assign Interface types to Interface types and expect to call a method that is only implemented on one of the CoClasses.  I was hoping that by reading this he would know how to fix his problem. He needs to instantiate an instance of whatever CoClass he wants and assign it to an Interface.  He was trying to get a Legend by calling some method that returns an Interface and then assign that Interface to his IBoundsProperty Interface and then he didn't know why he couldn't call FixedAspectRatio. Well, I don't know how much success you had with the OP in that, but that point was clearly lost on me. Why couldn't you have written some sample code to illustrate the proper way of doing it? Ironically though, you want to know what the concrete class for ILegend is actually named? LegendClass_2. Because there's an ILegendClass interface with a LegendClass pseudo-class (with its concrete class being LegendClassClass), so they had to append a "_2". The other thing about this is that many times when working with ArcObjects, you don't want to create new objects, you want to get the things that are already on the map. So if the OP's legend is already loaded on the Map, what good is it going to do to call new LegendClass_2()? Also, many classes can not be created and others have no public constructors. In those cases when you need to create a new one of those, you typically have to use a factory of some kind, and the signatures on those factories frequently just specify a return type of object, IObject, or some other useless type that has to be cast to a usable interface type before you can do anything with it. What do you expect to happen here? The interface is not designed to be implemented outside of ArcObjects. For example, there's no reason a developer would have production code that would implement the IGeometry interfaces. The only case I can imagine when anyone would ever want to implement those interfaces would be when doing headless unit tests, but that would obviously not be production code. The new functionality is going to be added to all of the classes that implement the previous interface. If both of those are true, then I expect them to just add the functionality to the existing interface. I don't know about "half the time".  Do you have a specific example of on which Interface that happens? Sure. ICalculatorUI2 (http://help.arcgis.com/en/sdk/10.0/vba_desktop/componenthelp/0022/002200000013000000.htm), the reason I joined this forum two weeks ago, which is still a problem for me. It doesn't inherit from ICalculatorUI, even they are only different in one property that was added to ICalculatorUI2. And they are both implemented only by CalculatorUIClass, and there's no reason anyone would have a custom implementation. Bottom line to all this, I'm glad the OP was able to figure it out on his own. It clearly wasn't a type casting problem as he would have gotten a NullReferenceException, not a NotImplementedException, though I don't really expect someone who doesn't know C# to know that. But I don't really see how quibbling over whether an interface implements a property or simply defines it is really helping anyone. Any object that can successfully be cast to an interface typed variable MUST have all of the members of that interface implemented, regardless of whether the implementation happened in the object's class or in a base class three levels up. It doesn't matter, so it isn't worth talking about. BTW Java programmer, did you not know that in the latest version of Java, interfaces CAN implement methods? (http://www.techempower.com/blog/2013/03/26/everything-about-java-8/) One of the reasons for this change was to make it easier to add members to interfaces that are already in production. Pretty cool, huh? 😉 ... View more

Your original post wanted to call: FixedAspectRatio That method is not implemented in the ILegend, IBoundsProperties or the other Interfaces you have used to create an instance of a legend using IMapSurroundFrame.CreateSurroundFrame and passing the uid of a Legend. Actually, IBoundsProperties does have a FixedAspectRatio property: http://help.arcgis.com/en/sdk/10.0/vba_desktop/componenthelp/000t/000t000002mz000000.htm I see a lot of people on this forum, especially in the .NET user group, assign interface types to other interface variables.  I honestly don't know how that works or why more people don't run into problems doing that. That is because that of how ESRI has designed ArcObjects and what they consider to be best practices, as shown in all of their examples. I used to think like you though about wanting to get away from interfaces and deal with concrete types. However, if you did get into .Net ArcObjects, you would see how ugly the classes are and that it's a complete waste of time to ever deal with them in any way other than creating a new object and assigning it to an interface. If for example, I define a variable of type PolygonClass (Polygon is not the concrete class, PolygonClass is), my variable has, in addition to IsEmpty (from IGeometry), IGeometry2_IsEmpty, IGeometry3_IsEmpty, IGeometry4_IsEmpty, IGeometry5_IsEmpty, IPolygon_IsEmpty, IPolygon2_IsEmpty, IPolygon3_IsEmpty, IPolygon4_IsEmpty, ICurve_IsEmpty, IPolycurve_IsEmpty, and IPolycurve2_IsEmpty. That's 12 different IsEmpty properties! And there are many other examples just like that on this one class alone, not to mention all the other classes! Now in this case, each of those IsEmpty properties would probably all behave exactly the same, but I know there are other cases where properties on different interfaces have the exact same name, but have completely different meanings. If those two interfaces are implemented by a single class, then you really have to be careful about how you call it if your variable is of the class type and not an interface type. I'm certainly not trying to beat you over the head with the "Program to the interface!" dogma. (I for one only define interfaces in my code when I need to have multiple classes implement some shared functionality that can't be done using a base class.) I also hate the way any time they need to add a new member to an interface, they just create a whole new interface ("IGeometry needs a new XYZ property? Say hello to IGeometry16!" :eek:), which half the time doesn't even inherit from the previous interface! :mad: But I digress... Basically, in the (.net) ArcObjects world, it's just always best to only use interface typed variables. As for why it works and doesn't break. Sometimes it does break. You always need to check when you are casting types that aren't always compatible (IE: IPolygon and IPolygon4 are always compatible both ways and an IPolygon can always be cast to an IGeometryCollection, but not the other way around) and that you aren't directly in control of. Hope that helps! 😉 ... View more

Glad I could help. 😉 ... View more