Author Topic: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013  (Read 21241 times)

0 Members and 1 Guest are viewing this topic.

Patriiick

  • Mosquito
  • Posts: 11
"Yes Master"... reminds me of a hilarious and famous movie  :-)

Serge

  • Guest
TheMaster

I can see from your answer that there is a relaxation in the tone and we are hopefully on the way to turn the page. I'm not particularly proud of how the discussion turned and the way I answered you (and I'm sure you do as well) but it is up to us to put good will. I do not think we were introduced to our advantage, and especially not to the benefit of visitors to this site.

We have a saying: when we point the finger at someone, three others are pointing the opposite direction. After being criticized for reasons we now understand better, having been accused of having given help to someone who asked it, after being called a coward and after being accused of a pathological ego, I am ready to shake hand move on. Are you? I think it is better to polarize our efforts in the same direction for the benefit of every one.

owenwengerd

  • Bull Frog
  • Posts: 441
I am a novice .NET programmer, and I was hoping to see you and TheMaster debate the questions and points that were raised. Instead, I am disappointed to see that both of you are unwilling to debate. Indeed, Serge, it seems like you are more worried about your pride and hurt feelings than the furtherance of knowledge through critical peer review.

I would like to know whether TheMaster is correct in his claims that conditional compilation is not necessary to share source code that calls new extension methods. Can someone answer that definitively?
« Last Edit: June 03, 2012, 11:17:32 AM by owenwengerd »

Jeff H

  • Needs a day job
  • Posts: 6075
Hey Serge, you probably did not notice or might be translation but, you have a typo
 

 
 
 
 
 
 
Namespace is one word not two.
 
So you meant to say that DocumentCollection.Open() was moved to another Namespace.
So if want to use the Open method you must call it from a different namespace?
What is the namespace the open method was moved to?

 
 
As far differences with VB and C# extensions I think mainly is bringing the module in scope.
In VB extension methods must be in a module and if that module is not created in the same namespace as the type it 'extends' you have to bring it into scope.
Stephen covers how you have import Document CollectionExtension
 
 
 

 
 
 
 
« Last Edit: June 03, 2012, 02:19:01 PM by Jeff H »

TheMaster

  • Guest
I am a novice .NET programmer, and I was hoping to see you and TheMaster debate the questions and points that were raised. Instead, I am disappointed to see that both of you are unwilling to debate. Indeed, Serge, it seems like you are more worried about your pride and hurt feelings than the furtherance of knowledge through critical peer review.


Owen, there's not much to debate other than that the Author really hasn't simply acknowledged that the workaround he highlights in yellow in the screenshot I posted in my first post in this thread, is unnecessary, and that the reason he cites for why the compiler error occurs, is not the case. :laugh:  There really is no debating something that's entirely self-evident, given a reasonable understanding of the concepts.

Extension methods exposed by one type, look like methods of another type.

The Open() method was a member of the DocumentCollection class in previous releases. In AutoCAD 2013, Open() is a member of another class, but is an extension method that target's the DocumentCollection class, which means the method can be called as if it was still a member of DocumentCollection, and calls to it that worked in AutoCAD 2012 will continue to work in AutoCAD 2013, provided the assembly containing the extension method is referenced.

Quote

I would like to know whether TheMaster is correct in his claims that conditional compilation is not necessary to share source code that calls new extension methods. Can someone answer that definitively?


Conditional compilation is completely unnecessary in cases where the extension methods have the same signature as the methods they replaced in earlier releases. However, some of the new extension methods are actually not replacements for what were methods in AutoCAD 2012.  Some of them are replacements for what were Properties in AutoCAD 2012.  For example:

Code - C#: [Select]
  1.    // AutoCAD 2012:
  2.    Document doc = Application.DocumentManager.MdiActiveDocument;
  3.    object oAcadDocument = doc.AcadDocument;
  4.  
  5.    // AutoCAD 2013:
  6.    Document doc = Application.DocumentManager.MdiActiveDocument;
  7.    object oAcadDocument = doc.GetAcadDocument();
  8.  

In the case of the Document.AcadDocument property, Autodesk replaced it with a method (GetAcadDocument). Because the property was replaced with a method, and because properties and methods have a different syntax, there is no way around having to revise code to work on AutoCAD 2013 in those cases, and in the process make it incompatible with AutoCAD 2012. So, in the case where new extension methods are replacing what were properties in AutoCAD 2012, there must be some release-dependent code. Conditional compilation is one way to implement release-dependent code, but not the only way.

If you look at this post you'll see a workaround that allows you to avoid conditional compilation. The workaround is, quite simply, to provide the same extension methods that Autodesk added to AutoCAD 2013 (to replace properties) to your AutoCAD 2012 project, making those same extension methods available on both releases, and allowing the same consuming code to use them on both releases.

So, with those extension methods from that post added to a project targeting AutoCAD 2012, this code will compile and run on both AutoCAD 2012 and AutoCAD 2013:

Code - C#: [Select]
  1.    Document doc = Application.DocumentManager.MdiActiveDocument;
  2.    object oAcadDocument = doc.GetAcadDocument();
  3.  

edit: corrected erroneous search/replace 'Document' with 'Application'
« Last Edit: June 04, 2012, 03:17:58 PM by TheMaster »

owenwengerd

  • Bull Frog
  • Posts: 441
Thanks for the clarification. I did see your other post, and it all makes sense the way you've explained it, but I was hoping that Serge would either validate your claim by acknowledging that you are correct or else explain why you are wrong.

Kerry

  • Mesozoic relic
  • Seagull
  • Posts: 11654
  • class keyThumper<T>:ILazy<T>
Tony,
Thanks for the insight.
How do you handle p/Invoke with translations to 2013
... where we have to deal with the new Core dll references as well as different mangled names ?


Regards
kdub.

Perfection is not optional.
Everything will work just as you expect it to, unless your expectations are incorrect.
Discipline: None at all.

--> Donate to theSwamp<--

TheMaster

  • Guest
Tony,
Thanks for the insight.
How do you handle p/Invoke with translations to 2013
... where we have to deal with the new Core dll references as well as different mangled names ?

Regards
kdub.

The same way I've been dealing with the change to each acdbxx.dll filename in each major release (e.g., acdb17.dll, acdb18.dll, etc.).  I use a const string for the DLL name and assign it using conditional compilation:

Code - C#: [Select]
  1.  
  2. #if ACAD_VER_18
  3.    const string ACDBXX_DLL = "acdb18.dll";
  4. #elif ACAD_VER_17
  5.    const string ACDBXX_DLL = "acdb17.dll";
  6. #else     // default is R16
  7.    const string ACDBXX_DLL = "acdb16.dll";
  8. #endif
  9.  
  10.  

And with that I use '[DllImport( ACDBXX_DLL, ...)] rather than hardwiring the dll filename in each [DllImport] attribute.

So, assuming we have the compiler symbol 'ACAD_R19_OR_GREATER' defined for compiling against AutoCAD 2013:

Code - C#: [Select]
  1.  
  2. public static class AcadCoreImports
  3. {
  4.  
  5. #if ACAD_R19_OR_GREATER
  6.    const string ACADLIB = "accore.dll";
  7. #else
  8.    const string ACADLIB = "acad.exe";
  9. #endif
  10.  
  11.    [DllImport( ACADLIB, EntryPoint = "acedCmd", CallingConvention = CallingConvention.Cdecl)]
  12.    extern static PromptStatus acedCmd( IntPtr rb );    
  13. }
  14.  
  15.  
« Last Edit: June 04, 2012, 07:03:17 PM by TheMaster »

Serge

  • Guest
Owen
My very first motivation is to help Patrick (the one who sent the article to this forum) with the very new AUGI French forum by sharing my experience the best I can. The interventions I made here were not only about my feelings and if it's the perception I leave, then I'm sorry and I'll make by best to change it.

Jeff
You are right, it's a mistranslation. Generally, you can leave your cursor over the text and Google will show you the original text as a tooltip. The example that is taken ad nauseum was not focused on the fact that a function is a member of a namespace, a class or whatever. The main objective was to show that you can use conditional declarations so with the same source code, you can manage multiple DotNet solutions. If I mentioned the word namespace, they were many reasons. The first one is the tooltip that you can see in the non-translated picture that is easily understandable even if it's in French. It says that Open (as it was written for VS2008) is not a member of DocumentCollection. If I can make an analogy, for me if you move a file from one disk to another, you can say that it's now a different file and nobody will make a fuss. Then the example continues further by showing the conditional declarations. Second, if this particular example is a very special case, in general you can see in the help files from ObjectArx directory that functions, properties and classes have indeed been moved from one namespace to another (as Kean also mentioned in its blog) and some have been made as extension as TheMaster and Stephen mentioned. Third, even if the word namespace as the very same meaning in different languages, it's more frequent to make "abuse of language" in VB because VB is more permissive. As I mentioned TheMaster, I can now understand that if we are accustomed with a language, the differences become more obvious. 

TheMaster
I do agree with you (why not) that there are always many different ways to solve a problem. For example when you say that "Conditional compilation is completely unnecessary in cases where the extension methods have the same signature", this brings something new.

Kerry,
The article treated also P/Invoke and mangled names so do not hesitate if you have any questions.

owenwengerd

  • Bull Frog
  • Posts: 441
Thank's Serge, this reply is more useful, but it still seems like you dance around my question. You have said here that you agree with TheMaster that "there are always many different ways to solve a problem", and that "this brings something new" in regard to his conditional compilation claim. I simply wanted to know whether TheMaster's claims are true or false, nothing more. I am satisfied by now that I know the answer, I just find it frustrating that I can't get confirmation from an expert.

Jeff H

  • Needs a day job
  • Posts: 6075
First off I am probably the least knowledgeable person who has replied to thread, and probably the most guilty of using incorrect terms and giving bad advice.
 
Serge I am trying to help because I am sure you will publish great articles in the future but some might be reluctant to read them after seeing this thread.
I am not trying to be rude but trying to help for you to see your article from a reader's perspective.
 
Tony pointed a simple mistake in your article.
It was a simple mistake and no big deal I can easily see how someone could make it since the class it was a member of was moved to another namespace and now is placed in another class.
 
Instead of simply going "oops...I edited the article" you have tapped dance all over the place, brought attention about it from other blogs, and replied about thousand things that have absolutely nothing to do with it.
 
And then replies like this
Jeff
You are right, it's a mistranslation.
I was wrong and was joking around because Owen asked about the debate,and pointing back out the simple mistake.
 
The example that is taken ad nauseum was not focused on the fact that a function is a member of a namespace, a class or whatever.
So if you are not focused on a particular subject the correctness does not matter.
 
in general you can see in the help files from ObjectArx directory that functions, properties and classes have indeed been moved from one namespace to another (as Kean also mentioned in its blog) and some have been made as extension as TheMaster and Stephen mentioned.
Just one many replies that does not change the fact it was not moved.
 
Third, even if the word namespace as the very same meaning in different languages, it's more frequent to make "abuse of language" in VB because VB is more permissive. As I mentioned TheMaster, I can now understand that if we are accustomed with a language, the differences become more obvious.
I have to disagree with you completely, and why would you want to make things more confusing and not make your intent clear, especially posting a article online wouldn't you want it to be correct?
 
Again it was a simple little mistake and not a big deal and not a issue and never should of been one. You made it one.
 

After all this dancing around over such a small little thing it makes me reluctant to read the article in depth or any of your future articles, because I am so confused when it is okay to be correct or whatever.
 

 
It is impossible to publish books, articles without mistakes and need help from other eyes to catch them, but after this thread I would think you would disregard them.
 
 
 
 
 
 

TheMaster

  • Guest
edit: corrected erroneous search/replace 'Document' with 'Application'

Oops.  Sorry, a search/replace was inadvertently done across the code in the post before I pasted it - Corrected.

Kerry

  • Mesozoic relic
  • Seagull
  • Posts: 11654
  • class keyThumper<T>:ILazy<T>

<..>

Kerry,
The article treated also P/Invoke and mangled names so do not hesitate if you have any questions.

I don't recall seeing anything related to migrating p/Invoke definitions from 2012 to 2013 ...

Regards
kdub
Perfection is not optional.
Everything will work just as you expect it to, unless your expectations are incorrect.
Discipline: None at all.

--> Donate to theSwamp<--

Serge

  • Guest
Owen,
I can't answer you during the day so please excuse me for the delay.

After reading the article from Stephen Preston as pointed out by SGP2012 (here's the link he supplied so you don't have to search it:  http://adndevblog.typepad.com/autocad/2012/05/extension-methods-in-autocad-2013.html), I have stopped arguing about the subject. I was unlucky enough with a ratio of one to a hundred to choose one of the very few exceptions were indeed the method shown was an extension from another class. As I mentioned concerning the idiosyncrasy of the languages and why words are more important for someone for who itís vital, I do hope that the lights Stephen gave us were made out of entangled photons so we are now polarized even if we are accustomed in our two separated world (Iím only joking because he's a PhD in Laser). Again, the focus was to show how to use conditional declarations.
But for the other 99%, there are a lot of functions that have been moved to different namespaces. Please have a look at the C:\ObjectARX 2013\docs\arxmgd.chm file. You can see the differences.



By the way, you say that you are a novice in DotNet. I donít know if itís true but I do know that you are very good in C++. I think it was during the period of AutoCAD 2002, you show us how to integrate a new button in the status bar. Thank you again. I donít know if I recall correctly but were you also a member of ADGE (AutoCAD Developer Group Europe)?


Jeff,
No problem. I didnít know the expression tapped dance and Iíll add it in my vocabulary. About your suggestion on "oops, I edited the article", I promise you that I will do it (but not now, as soon as I can). I usually do it when it happens. Concerning translation, I know what you mean. I bought a new BBQ made in (Ö I donít want to hurt no one) and the instructions were translated automatically. I didnít plan to bring the article on this forum although Iím very happy Patrick made it. Concerning other articles, there are some already written and others to come. I'll ask Patrick to wait before he published them that I gather not only the original article but also the comments that came after.

Serge

  • Guest
Kerry,
Sorry, I forgot to answer you. Here's an excerpt from the article.