TheSwamp

Code Red => .NET => Topic started by: Patriiick on April 28, 2012, 06:35:43 AM

Title: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: Patriiick on April 28, 2012, 06:35:43 AM
An article (http://goo.gl/57XoE) by Serge Camiré, automatic translation from french. (french original  article here (http://augifr.ning.com/profiles/blogs/migration-de-solution-dotnet-pour-autocad-2013), login required)
(Since the article was put in private mode after this thread was started, here is a public screen capture (http://www.augifr.fr/images/migration-de-solution-dotnet-pour-autocad-2013-automatic-translation-screen-capture-256-colors.png) of the english translation)
Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: TheMaster on April 28, 2012, 02:02:16 PM
Quote from: Patriiick on April 28, 2012, 06:35:43 AM
An article (http://goo.gl/57XoE) by Serge Camiré, automatic translation from french.

Regarding this:

(http://www.augifr.fr/images/autocad-2013-migration-dotnet-image015.jpg)

The Open() method is an extension method in 2013, but it is
not in a different namespace. It would seem that the author
has namespaces and classes confused.

If that's so, it should continue to work as it did previously (or at
least, in C# it should, but I'm not sure about VB), and none of
what he shows above should be necessary.

Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: BlackBox on April 28, 2012, 02:34:07 PM
Out of curiosity, is that not necessary because of the ApplicationServices Class for each version (AcMgd), or does Core Console in 2013 present a Reference hurdle given the stated intent for plug-in ambiguity  (where the same plug-in would work for R18* & R19*)?

I'm only now teaching myself to code in .NET, so forgive me if I am oblivious to the fundamentals.

** Edit - iPhone typos fixed. Also, I really like the Rice, Wine, Sake analogy.
Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: TheMaster on April 28, 2012, 03:25:23 PM
Quote from: RenderMan on April 28, 2012, 02:34:07 PM
Out of curiosity, is that not neccesary because of the ApplicationServices Class for each version (AcMgd), or does Core Console in 2013 present a Reference hurdle given the stated intent for plug-in ambiguity  (where the same plug-in would work for R18* & R19*)?

I'm only now teaching myself to code in .NET, so forgive me if I am obvlivious to the fundamentals.

ApplicationServices is a namespace, not a class.

I'm just guessing that there'd need to be code changes for plugins that
are designed specifically to run in the core console, but in those cases,
there are probably many other dependencies that would also require
different code streams.

Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: BlackBox on April 28, 2012, 04:03:18 PM
Sorry for my confusion; I know that AutoCAD.ApplicationServices is being used as a Namespace, be it with "using" (C#), or "Imports" (VB), I just (incorrectly) assumed that ApplicationServices was a Class of AutoCAD.

Again, I am very new to .NET; your clarification is much appreciated.
Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: Serge on April 30, 2012, 06:43:53 AM
Thanks to Patrick for having published on this web site my article about the migration of DotNet solutions to work with AutoCAD 2013. It’s an honor for me to introduce myself in this first thread. I will certainly read other articles.

I also want to thank the ones who read my article. It’s unbelievable how today a text can be translated with so few glitches.  I do hope that you found useful tips. You may find that, unlike articles in a Playboy magazine, the text parts it contains are at least as much important as the images.

There is a thing I can’t close my eyes. I would like TheMaster that he kindly clarifies what he meant by saying "It would seem that the author has namespaces and classes confused." If I don’t react to that statement, this would suggests that anyone can write anything to discredit someone else's work without foundation.

I spent hours to write with the most accurate information possible aiming people to ease their work. The image invoked is about reusing the source code in different versions of Visual Studio. I never mentioned the word Class or Namespace nearby. In fact, there are only 3 occurrences of the word Namespace in the whole article and it is at the very end where I explain how to export Type Libraries for those who want to create skins in a context of managing Cad standards with MEF.

I'm sure TheMaster will now give a fair try by reading the article at least once and come back with something more constructive. For me, an opinion comes with impersonal facts, some solid arguments and a possible way to rectify the situation. There are now 3 possibilities for him: 1) he clarifies what he wrote; 2) he retracts himself or 3) he let things go and loose its own credibility and I’m sure it’s not what he wants.

This was not in my article but yes indeed, there are some changes in the Namespaces. We can read an article by Kean Walmsley in this topic in "Migrating .NET applications to work with AutoCAD 2013": http://augifr.ning.com/profiles/blogs/migration-de-solution-dotnet-pour-autocad-2013?commentId=6456585%3AComment%3A10055&xg_source=msg_com_blogpost or you can read the C:\\ObjectARX 2013\docs\arxmgd.chm help file.
Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: TheMaster on April 30, 2012, 08:22:40 AM
Quote from: Serge on April 30, 2012, 06:43:53 AM
There is a thing I can’t close my eyes. I would like TheMaster that he kindly clarifies what he meant by saying "It would seem that the author has namespaces and classes confused." If I don’t react to that statement, this would suggests that anyone can write anything to discredit someone else's work without foundation.

This is a direct quote from your article:

Quote

    The error is caused by a displacement of the function to another name space.


That is not true.

The function was not moved ("displaced") to another namespace, it was moved to another class, and was made an extension method of the class it was moved out of.

None of the code changes you show are necessary because the Open() method is an extension method, which means that it can continue to be used as if it were still a method of the DocumentCollection, and the same code that used it in 2012 or earlier will work in 2013.

If your 2013 code does not compile and generates the error stating that the Open() method is not a member of the DocumentCollection class, there are two possible reasons for it: One is because you do not reference the namespace containing the extension methods (which in this case, is Autodesk.AutoCAD.ApplicationServices), and the second potential cause (and the likely cause in your particular case), is that you've not added a reference to the assembly containing the extension method.

If you are not familiar with extension methods (as your article clearly suggests), then visit MSDN and read more about them, and how they are used.
Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: TheMaster on April 30, 2012, 09:22:56 AM
Quote from: Serge on April 30, 2012, 06:43:53 AM
This was not in my article but yes indeed, there are some changes in the Namespaces. We can read an article by Kean Walmsley in this topic in "Migrating .NET applications to work with AutoCAD 2013": http://augifr.ning.com/profiles/blogs/migration-de-solution-dotnet-pour-autocad-2013?commentId=6456585%3AComment%3A10055&xg_source=msg_com_blogpost or you can read the C:\\ObjectARX 2013\docs\arxmgd.chm help file.

Perhaps you've been mislead by the somewhat confusing way Kean expressed the changes in AutoCAD 2013 in the above referenced article, or perhaps the translation from English was the problem, but what Kean says is not factually accurate in several ways.

From that article:

Quote

Along with API implementations moving from acad.exe to AcCore.dll (and their public declarations moving from AcMgd.dll to AcCoreMgd.dll), we’ve also added some namespaces to house extension methods for API capabilities that need to be used in full (rather than core) applications: DocumentExtension, DocumentCollectionExtension, EditorExtension, WindowExtension. You will find that certain methods can’t be found when you reference the AutoCAD 2013 DLLs – in most cases it’s a simple matter of adding the right namespace to your project, but in a few cases you’ll find properties/methods have been renamed – mostly to make them more descriptive.

For instance, the existing property to get AutoCAD’s status bar is:

     Autodesk.AutoCAD.ApplicationServices.Document.StatusBar

In AutoCAD 2013, this has been changed to:

     Autodesk.AutoCAD.ApplicationServices.DocumentExtension.GetStatusBar()

So a little different, but hopefully not to find to track down and manage. The ObjectARX SDK contains migration information that will help identify and make these changes.


Specifically, where he says:

Quote
we’ve also added some namespaces to house extension methods for API capabilities that need to be used in full (rather than core) applications: DocumentExtension, DocumentCollectionExtension, EditorExtension, WindowExtension.

They didn't add namespaces, they added classes to house extension methods. The identifiers he cites above are the names of classes, not namespaces.

In addition, he shows GetStatusBar() as being a method of DocumentExtension (which it is) but what is confusing about that is that because GetStatusBar() is an extension method that targets Autodesk.AutoCAD.ApplicationServices.Document, the method can be called as if it were a method of the Document class (e.g., myDocument.GetStatusBar() ), so that is also misleading.

Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: Serge on May 21, 2012, 05:54:08 PM
No one has answered RenderMan yet so I’ll open a parenthesis for him now then continue with TheMaster.

A namespace is an organize way to store information. You may see it as folders. Like folders, they can be organized with a hierarchy (many levels). They may contain objects such as classes, structures, enumerations, delegate function and so on. On the other part, classes are complex objects that contain data, functions, events and so on. You may see them as a file. A structure is a special case of class as they essentially contain only data and they do not support encapsulation. Like a directory, a namespace is a container and could contain all the above objects; they do not have to be in a class (although Autodesk usually organize them in classes).

If you open the arxmgd.chm file from the C:\ObjectARX 2013\docs directory, you’ll find a section called “Moved API”. In there, you will find a list of all the objects that have been moved. The first item is the EventHandler Idle. It is mentioned that it has been moved from Autodesk.AutoCAD.ApplicationServices.Application to Autodesk.AutoCAD.ApplicationServices.Core.Application. The class here is Application and everything before is the namespace.

So, to answer your question, AutoCAD.ApplicationServices is indeed a namespace and Application is the class.

If someone likes to play with words, yes you can always say that if you move a file from a disk to another, it is not the same file anymore and so, if you move a class from one namespace to another, it is not the same class anymore. I don’t think anyone has being confused up to now.
Here is a modified PrintSCreen of the Object Browser that you can open with the F2 key. In the left pane, you’ll find symbol names with their respective icon, on the upper right pane is the content of the symbol and finally, in the lower right pane if the definition. I’ve used Visual Studio 2008 for the example because it is a version I own in English.
 (http://www.cadnovation.com/articles/2012-04-15_migration_dotnet_2013/ojectbrowser.png)
To return to TheMaster, I don’t want to extend this discussion about whether or not I’m confusing classes or namespace because I find this trivial but:
   
Here is a first quote of yours: “The Open() method is an extension method in 2013, but it is
not in a different namespace. It would seem that the author has namespaces and classes confused. » and this other quote: “If you are not familiar with extension methods (as your article clearly suggests), then visit MSDN and read more about them, and how they are used.”. These are 2 misleading affirmations that I’m sure I’ll take time to analyze.

About Extension method, please first, read this link to learn more about them: http://msdn.microsoft.com/en-us/library/bb383977.aspx.
Extension methods have been introduced in C # 3.0 as a solution to allow the mapping syntax to run correctly with LINQ IEnumerable, without having to change the IEnumerable itself (which would cause enormous problems existing code). Unfortunately if they are convenient for this case (and are actually the best solution), 95% of cases, they pose serious problems of versioning, and should be used with extreme caution. Extension methods are also mainly aimed to those who do not currently own the source code. I don’t think that this is the problem at Autodesk.

In my article, I was not talking about extension methods but rather about new things in AutoCAD 2013, and indirectly what’s new in the Framework 4.0, hence the Managed Extensibility Framework (or MEF).

Many of the Microsoft’s technologies overlap. Sometime, it happens when a new paradigm arises. But they are never 100% equal. According to Glenn Block (PM for the MEF in .Net 4.0) MEF is the preferred way for building composable apps.

Again, to avoid confusing technologies, I suggest learning about:
Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: TheMaster on May 21, 2012, 06:54:48 PM
Quote from: Serge on May 21, 2012, 05:54:08 PM

No one has answered RenderMan yet ....


Sorry, your first sentence (quoted above) is incorrect, So I will not waste my time with anything else you've written, other than to reiterate that Your original mistake of calling an extension method directly as a static method, rather than correctly calling it as an extension method is entirely self-evident, and yet you almost completely ignored that in a rambling reply/lecture.

The first lesson you have to learn before any lesson related to programming, is how to find the courage to admit to your own mistakes, rather than trying to trivialize and marginalize them with posts like this, and attacking the one who points them out.

Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: Serge on May 25, 2012, 06:04:57 AM
Again, I feel this is a privilege that all of us being able to participate to this site. This discussion should be focused for those who want to discuss about the article.

I hope you are not blaming me because I gave information to RenderMan. I also hope that it's not too late and that he has seen it. If you read his very last sentence, you'll see that it was "Again, I am very new to .NET; your clarification is much appreciated."

I think we should not confuse courage and humility.

For me, courage was to take the time to write the article. If you copy-paste it into Word, you'll end up having about 35 pages of fully condensed information. I never heard you saying that you liked it or that you've learned something, although you didn't have to. On the contrary, you emitted a negative opinion for which I asked you kindly to elaborate. The rest is known and I've turn the page. If I must admit I made a mistake because I used the exact same words as Kean and the official Autodesk's documentation, then I don't feel so bad.

Humility is something else. You don't know me but if you did, you'll be the first to seen that I'm the first to laugh at myself. I usually try to make my best but since I'm human, it can happen (and it does happen) that I say something that is not clear enough or incomplete. Again, if you'd read me in other newsgroups, you'll see that I am always glad to be criticized because it creates a positive dynamics and everybody win.

Humility implies that I never gave myself any conceited attributes or nicknames. I believe that the other ones should decide if I am good or not.

I think the real problem is that you never thought the author would find your comments because of the language barrier and ask for justifications. Rather than admit yourself that your opinions were exaggerated, you continued to see problems where there were none, pushing further the reasoning by including Kean in your justification. Why wear dark glasses? Worse, you started talking about extensibility, a subject you have not defended yourself yet and for which you made 2 important misleading declarations and for which I gave you references. Instead of explaining yourself on that topic, you've diverted the attention by accusing me of lack of courage, making me the moral and complaining because I wanted to help Renderman. Are you the only one who can intervene on this site?

I feel very sorry the way this thread is evolving because that's spoiling the work I've done writing the article. I'm also sad the way that our first contact begun. Can we raise the white flag?
Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: TheMaster on May 25, 2012, 08:48:11 AM
Quote from: Serge on May 25, 2012, 06:04:57 AM

I hope you are not blaming me because I gave information to RenderMan.


No, Only for ignoring the fact that RenderMan's question was answered, long before you replied.

Quote

I think we should not confuse courage and humility.


I have no problem not confusing the two.  I also know egomania when I see it.

So far, you've only shown that you are incapable of admitting your mistake. 

Quote

Rather than admit yourself that your opinions were exaggerated...


There was no exaggeration. 

You are confusing exaggeration with your inability to admit to mistakes.

Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: Jeff H on May 28, 2012, 03:32:51 PM
I have not tried testing it but I am still a little confused how it would work.
 
Among others DocumentCollection was ripped out and placed in Autodesk.AutoCAD.ApplicationServices from accoremgd.dll
 
How do you tell which dll to load or which dll you would be using?
Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: Kerry on May 28, 2012, 05:12:08 PM

I am confused by your confusion grasshopper ..

Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: Kerry on May 28, 2012, 05:15:55 PM

Has the article been made private, or is my access being affected by public wifi ??

.... decided to read the article and can't :(



Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: BlackBox on May 28, 2012, 06:47:04 PM
The link in the OP takes me to a page to log in; I think that's an AUGIfr site requirement (one that was not needed when I read the article originally).
Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: Jeff H on May 28, 2012, 07:00:39 PM
Yes it has been made private or you have to join but I cannot read whatever language it is in.
 
I looked through it the other day and in the comments were about the reaction at the Swamp.
 
So as that I goes,
 
Serge, I do not think anyone really believes you do not know the difference between a namespace and class.
 
Although in your article and in Kean's those statements do cause some confusion.
 
When I first read Kean's article the first thing I did was look in reflector and looked for the new namespaces that contained the methods, and without looking closely you could come to conclusion that they were moved to a new namespace since the methods were members of classes that were moved to accoremgd, but the methods mentioned were made extension methods in classes in the same namespace(as pointed out by TheMaster).
Knowing that it makes more sense how to fix the errors and how to handle them.
 
 
 
 
Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: Kerry on May 28, 2012, 08:29:41 PM


Jeff, because I can't get to the article ...
Re : the piccy Tony pasted from the article showing the text for < 19
I'm not sure that those hoops need to be jumped through ... I may test it if I can make the time.

Has anyone tried it ??

Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: Jeff H on May 28, 2012, 09:50:46 PM
I could be wrong but I am not seeing how you can create those hoops.
 
 
Unless maybe you do something like
 
#If R19
Imports ...
........
 
 
Again I could be wrong but for it work in 2013 don't you have to build against 4.0 and for early version how do you get it to work for 4.0?
And I do not think it will work in 2013 without a reference to accoremgd.dll?
I could be just confrused or maybe diffrent dll's are being built.
Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: Kerry on May 28, 2012, 10:11:57 PM
Quote from: Jeff H on May 28, 2012, 09:50:46 PM
< ... >  or maybe diffrent dll's are being built.

I believe so ; with different references ; and with the version variable set to suit.
.. perhaps different solutions using the same source files ??

The testing would need to be exemplary.

Regards,
kdub
Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: Serge on May 28, 2012, 10:13:42 PM
Kerry,
The article is still available. I just tried the link. Usually, you needed 2 mandatory dlls: acdbmgd.dll and acmgd.dll. With 2013, you need a third mandatory dll: accoremgd.dll. You may need other dlls upon what you are doing. Don't forget that all these dll have to be declared "Local Copy" to False. To know which one does what is not that important but you can read the documentation in the ObjectArx files.

TheMaster,
I guess this discussion could last forever. Let's the other people make their own opinion.
Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: Kerry on May 28, 2012, 10:20:39 PM
Serge,
Thanks, I know what is required for 2013.


The link directs me to a log-in page in French ... I understood the link directed to the article.

Perhaps it works for you because you are a member there and logged in ??
Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: Kerry on May 28, 2012, 10:31:14 PM
Quote from: Serge on April 30, 2012, 06:43:53 AM
< ....>
This was not in my article but yes indeed, there are some changes in the Namespaces. We can read an article by Kean Walmsley in this topic in "Migrating .NET applications to work with AutoCAD 2013": http://augifr.ning.com/profiles/blogs/migration-de-solution-dotnet-pour-autocad-2013?commentId=6456585%3AComment%3A10055&xg_source=msg_com_blogpost or you can read the C:\\ObjectARX 2013\docs\arxmgd.chm help file.

This link also requires a log in.
Is it a reproduction of Keans blog or the devBlog articles ??

Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: SGP2012 on May 29, 2012, 09:37:24 PM
I used this thread as an excuse for a blog post, so its polite to cross-reference the post here - http://adndevblog.typepad.com/autocad/2012/05/extension-methods-in-autocad-2013.html.

Cheers,

Stephen
Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: Kerry on May 30, 2012, 03:25:07 AM


Thanks Stephen,

I started to put some notes together last night to cover this .. now I don't need to finish and post them  :)

There are quite a few examples of extension method here at theSwamp .. back from the day they were introduced I imagine :-D

Regards
kdub.
Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: Jeff H on May 30, 2012, 09:22:51 AM
Quote from: Serge on May 28, 2012, 10:13:42 PM
Kerry,
The article is still available. I just tried the link. Usually, you needed 2 mandatory dlls: acdbmgd.dll and acmgd.dll. With 2013, you need a third mandatory dll: accoremgd.dll. You may need other dlls upon what you are doing. Don't forget that all these dll have to be declared "Local Copy" to False. To know which one does what is not that important but you can read the documentation in the ObjectArx files.

TheMaster,
I guess this discussion could last forever. Let's the other people make their own opinion.
So in article about using a library for 2007 to 2013 do you have an example of how that works?
Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: Patriiick on May 31, 2012, 07:34:01 AM
Right the article (and the whole site) has been made private since publication. I'll find a solution and will publish the public version here soon, sorry for the inconvenience.
Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: Serge on May 31, 2012, 08:07:42 AM
Here is a link to the original article: http://www.cadnovation.com/articles/2012-04-15_migration_dotnet_2013/migration_de_solution_dotnet_pour_autocad_2013.htm. This URL has the advantage of showing the text and images in its full width.

To automatically translate it, you can also go on http://translate.google.com then translate the URL from French into English, giving this link: http://translate.google.ca/translate?sl=fr&tl=en&js=n&prev=_t&hl=fr&ie=UTF-8&layout=2&eotf=1&u=http%3A%2F%2Fwww.cadnovation.com%2Farticles%2F2012-04-15_migration_dotnet_2013%2Fmigration_de_solution_dotnet_pour_autocad_2013.htm&act=url

Note: Something annoying is that the translation stops after about three quarters of the text length.

Thanks to Stephen Preston for his lights on extensibility (what is more natural from a PhD in laser technology).

Even if, for common use, extensibility, as defined in FrameWork 3, should be used sparingly for the reasons I mentioned earlier. I understand that for reasons of portability between different platforms, Autodesk had virtually no choice.

Nevertheless, I do not treat this subject in the article but Managed Extensibility Framework which is a new feature of FrameWork 4.0. Its goal is really quite different. Here is a link that shows the top 10 reasons to use it: http://www.wintellect.com/cs/blogs/jlikness/archive/2010/04/06/ten-reasons-to-use-the-managed-extensibility-framework.aspx and this: "An Introduction to Managed Extensibility Framework (MEF) - Part I": http://www.codeproject.com/Articles/188054/An-Introduction-to-Managed-Extensibility-Framework. You will gain in discovering. It allows you to create skins to manage your CAD standards so they can adapt to you various customers, without changing the core base.

Something very interesting arises from the article by Stephen: idiosyncrasy or peculiar behavior of the VB and C # statements concerning Imports vs. Using. If TheMaster and I are from those 2 different worlds, this probably explains why certain words are misinterpreted or seem so important for one but not to the other because we are accustomed to different reference systems.

Another significant element: the original article was almost twice longer than the one that was presented before it was translated automatically. By reducing it, it may well be that certain essential passages were lost but it did not jump yet in my eyes because the topics are still too fresh in my memory. But is it really important to hang on small details and not see the rest?
Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: Patriiick on May 31, 2012, 08:10:08 AM
Here is the translated version (http://www.augifr.fr/images/migration-de-solution-dotnet-pour-autocad-2013-automatic-translation-screen-capture-256-colors.png), publicly accessible, as an image. No hyperlinks but you get the full article with pictures.
Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: TheMaster on May 31, 2012, 09:05:17 AM
Quote from: Serge on May 25, 2012, 06:04:57 AM

Humility implies that I never gave myself any conceited attributes or nicknames. I believe that the other ones should decide if I am good or not.


My nickname here was intended as a pun on the ranks that users are given on Autodesk's discussion groups.
Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: Patriiick on May 31, 2012, 09:07:28 AM
"Yes Master"... reminds me of a hilarious and famous movie  :-)
Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: Serge on June 03, 2012, 08:25:27 AM
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.
Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: owenwengerd on June 03, 2012, 11:12:07 AM
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?
Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: Jeff H on June 03, 2012, 02:12:04 PM
Hey Serge, you probably did not notice or might be translation but, you have a typo
 
(http://i1221.photobucket.com/albums/dd473/Jeffrey_H/namespacetypo.png)
 
 
 
 
 
 
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
 
 
 
(http://i1221.photobucket.com/albums/dd473/Jeffrey_H/gif_tapdance.gif)
 
 
 
 
Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: TheMaster on June 03, 2012, 04:32:06 PM
Quote from: owenwengerd on June 03, 2012, 11:12:07 AM
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 (http://www.theswamp.org/index.php?topic=41868.msg470080#msg470080) 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'
Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: owenwengerd on June 03, 2012, 08:15:26 PM
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.
Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: Kerry on June 03, 2012, 10:27:38 PM
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.

Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: TheMaster on June 04, 2012, 12:13:50 AM
Quote from: Kerry on June 03, 2012, 10:27:38 PM
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.  
Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: Serge on June 04, 2012, 08:22:23 AM
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.
Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: owenwengerd on June 04, 2012, 09:06:07 AM
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.
Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: Jeff H on June 04, 2012, 01:54:59 PM
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
Quote from: Serge on June 04, 2012, 08:22:23 AM
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.
 
Quote from: Serge on June 04, 2012, 08:22:23 AM
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.
 
Quote from: Serge on June 04, 2012, 08:22:23 AM
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.
 
Quote from: Serge on June 04, 2012, 08:22:23 AM
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.
 
 
 
 
 
 
Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: TheMaster on June 04, 2012, 03:19:49 PM
Quote from: TheMaster on June 03, 2012, 04:32:06 PM
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.
Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: Kerry on June 04, 2012, 05:29:13 PM
Quote from: Serge on June 04, 2012, 08:22:23 AM

<..>

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
Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: Serge on June 04, 2012, 08:12:32 PM
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.

(http://www.cadnovation.com/articles/2012-04-15_migration_dotnet_2013/moved_namespaces.png)

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.
Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: Serge on June 04, 2012, 08:21:22 PM
Kerry,
Sorry, I forgot to answer you. Here's an excerpt from the article.

(http://www.cadnovation.com/articles/2012-04-15_migration_dotnet_2013/pinvoke.png)
Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: Kerry on June 04, 2012, 08:41:07 PM

Sorry Serge, you may need to do some more research.

The acedGetSym is defined in acCore.dll not in acad.exe for AutoCAD 2013.

Regards
kdub
Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: owenwengerd on June 04, 2012, 09:09:46 PM
Serge, we probably met in Stuttgart at the very last ADGE conference a very long time ago. As you note, my expertise is primarily with C++ and assembly language. I am very much a novice with .NET, but I do use it occasionally. When I eventually am forced to write managed code for targeting multiple AutoCAD versions, I want to be able to do it the most efficient way without reinventing the wheel and without duplicating source code.

Thank you for taking the time to respond here. I hope you do correct the article and incorporate everything discussed here so that future readers of this thread will be less confused than I was.
Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: TheMaster on June 04, 2012, 09:44:28 PM
Quote from: Serge on June 04, 2012, 08:22:23 AM

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

Kerry was referring to dealing with P/Invoke in the context of migration to AutoCAD 2013 and the library whose filename is passed as the first argument to DllImport, which is different in AutoCAD 2013 for many imported APIs ("acad.exe in 2012, and "accore.dll" in 2013). I see nothing in your article that talks about that.

Quote
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.

This discussion was never about other unidentified functions, properties, and classes being moved to another namespace, but everyone here can easily read this thread and see that you have desperately tried to change the subject from what it was from the start (the mistake in your article).  And, I find it disingenuous of you to try to make the topic of this discussion about something else.

This discussion is very specifically about the Open() method featured in the article (as per the screenshot in my first post), and the erroneous statements made therein (the reason why the compiler error occurs, and the code that works around it, highlighted in yellow in the screenshot). 

Most of your relevant comments in this thread are obviously intended to change the subject, and to make this discussion about anything and everything other than that.

Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: Serge on June 05, 2012, 09:28:51 PM
Owen
Leider habe ich nicht die Ehre hatte, Sie in Stuttgart zu treffen. Ich betrachte Sie ja wie einen Fachmann des ObjectARX Software und die Idee eines möglichen Treffens begrüßte mich. Wer weiß? Ich werde sicherlich schreiben, eine Zusammenfassung meiner Notizen, aber erst dem Monat August. Trotz der Diskussionen, die folgten, hoffe ich, dass der Artikel an sich verwirrt nicht Ihnen.
Unfortunately I have not had the honor to meet you in Stuttgart. I consider you as an expert in the ObjectARX software and the idea of a possible reunion enjoys me. Who knows? I will certainly write a summary of my notes, but not before August. Despite the regrettable discussions that followed, I hope that the article in itself did not confuse you.


Kerry
I’m the one who is sorry. By doing a cut and paste from Word when I answered you, I forgot a paragraph (I use Word because English is not my primary langage and it helps me a little bit with my typos). In the article, I was precisely telling people to be aware of the problem. The subject was left open on purpose since it is a way to make people ask and participate. And the solution I would have suggested is exactly the same one as TheMaster gave and it is indeed the very same one I'm using at work.


TheMaster
Alas, alas, alas. I left the door wide open for reconciliation but now that I know your real name, I know it is impossible. You are really a master of your own, although we surely do not agree the reasons one more time.

Einstein himself felt uncomfortable with the attention people paid to him, but not you. A journalist once asked him “what is the difference between genius and madness”. After few seconds, he answered “genius has its limits”. You obviously have no limits and this trivial discussion could continue forever.

I do have some questions that were left unanswered. I know that this fuel for fire and it is lowering to your level but I promise this the very last time I have any form of exchange with you, unless you appear stealthily under a new conceited nickname like GOD-zilla, or in your case, should we be said GOD-zillo. I do that for the respect I have for my peers, for this forum, for myself. This does not mean that if other people have questions about this article or any other that might come or any other subject, I will be glad to answer them.

April 30: you declared
Quote
“If you are not familiar with extension methods (as your article clearly suggests), then visit MSDN and read more about them, and how they are used.”
. As I mentioned, the article never talked about the extension methods. It is the fruit of your imagination. Instead, I talked about MEF which is completely something different.

I already know your answer since you became predictable. You will try to divert the attention to something that should have been considered as a misprint or something unnecessary for the understanding of what was debated: the use of conditional declarations. I bet you will still advocate a thousand and one reasons not to answer the questions above. Prove me I’m wrong.

Hare hare, Shri Shri Mahatma TheMaster Chalisa , Hare hare, Shri Gurda Chalisa (in Hindi, it means forty verse Hindu prayers for the great Lord TheMaster and one of his avatar). Let’s meditate on your righteous and noble qualities.
Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: It's Alive! on June 05, 2012, 09:48:56 PM
Monkeys, typically open bananas from the opposite end as Humans, but the end result is the same, a tasty treat for the opener.  However,  the monkey way is significantly more efficient as it only requires a slight pinch whereas humans insist on breaking the stock end which usually ends up mashing the fruit.
Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: Kerry on June 05, 2012, 10:16:09 PM

Serge, while I appreciate your efforts with the article and wour willingness to share ;
I think you are getting a bit carrried away with the comments that have nothing positive to add to the real issue.

Personally I'd appreciate your co-operation in this regard.

Thanks
kdub.

Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: TheMaster on June 05, 2012, 11:12:03 PM
Quote from: Serge on June 05, 2012, 09:28:51 PM
....The subject was left open on purpose since it is a way to make people ask and participate. And the solution I would have suggested is exactly the same one as TheMaster gave and it is indeed the very same one I'm using at work.

Yes, of course.   :roll:

Quote
TheMaster
Alas, alas, alas. I left the door wide open for reconciliation but now that I know your real name, I know it is impossible.


The only thing here that is "impossible" is your ability to concede to having made a mistake that went into a printed AUGI publication.  That is the one and only impossibility, and is a prerequisite to reconciliation.

Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: MexicanCustard on June 06, 2012, 09:09:19 AM
Quote from: eNotEnoughBeer on June 05, 2012, 09:48:56 PM
Monkeys, typically open bananas from the opposite end as Humans, but the end result is the same, a tasty treat for the opener.  However,  the monkey way is significantly more efficient as it only requires a slight pinch whereas humans insist on breaking the stock end which usually ends up mashing the fruit.

Really? I learn something here everyday.  Now people are going to think I'm weird because I have to try opening bananas backwards.  Thanks a lot Daniel you've made me weird.  :pissed:
Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: Delegate on June 06, 2012, 09:11:30 AM
Quote from: MexicanCustard on June 06, 2012, 09:09:19 AM
Quote from: eNotEnoughBeer on June 05, 2012, 09:48:56 PM
Monkeys, typically open bananas from the opposite end as Humans, but the end result is the same, a tasty treat for the opener.  However,  the monkey way is significantly more efficient as it only requires a slight pinch whereas humans insist on breaking the stock end which usually ends up mashing the fruit.

Really? I learn something here everyday.  Now people are going to think I'm weird because I have to try opening bananas backwards.  Thanks a lot Daniel you've made me weird.  :pissed:

After lunch time trial I can confirm it works!
Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: Jeff_M on June 06, 2012, 09:43:02 AM
Quote from: Delegate on June 06, 2012, 09:11:30 AM
Quote from: MexicanCustard on June 06, 2012, 09:09:19 AM
Quote from: eNotEnoughBeer on June 05, 2012, 09:48:56 PM
Monkeys, typically open bananas from the opposite end as Humans, but the end result is the same, a tasty treat for the opener.  However,  the monkey way is significantly more efficient as it only requires a slight pinch whereas humans insist on breaking the stock end which usually ends up mashing the fruit.

Really? I learn something here everyday.  Now people are going to think I'm weird because I have to try opening bananas backwards.  Thanks a lot Daniel you've made me weird.  :pissed:

After lunch time trial I can confirm it works!
I learned about this a year, or so, ago from the most unlikely of places (almost as unlikely a place  as a .NET forum! ;-) ). My wife was watching Wheel of Fortune whilst I was doing some coding research, at the end of the show Vanna White was telling Pat Sajak how to 'properly' peel a banana. I had to try it the next day and have been peeling 'correctly' ever since.
Title: Re: Rice, wine and sake, or how to migrate your DotNet AutoCAD applications for 2013
Post by: bchapman on February 03, 2013, 09:51:09 AM
Quote from: RenderMan on April 28, 2012, 02:34:07 PM
Out of curiosity, is that not necessary because of the ApplicationServices Class for each version (AcMgd), or does Core Console in 2013 present a Reference hurdle given the stated intent for plug-in ambiguity  (where the same plug-in would work for R18* & R19*)?

I'm only now teaching myself to code in .NET, so forgive me if I am oblivious to the fundamentals.

** Edit - iPhone typos fixed. Also, I really like the Rice, Wine, Sake analogy.

^ sounds like me right now lol