Author Topic: Wrapping command actions  (Read 8785 times)

0 Members and 1 Guest are viewing this topic.

TheMaster

  • Guest
Re: Wrapping command actions
« Reply #15 on: May 09, 2012, 02:58:30 PM »
side node: Why is code=csarp really dumb about coloring key words?

FWIW -

That is the result of many, many users asking for this forum enhancement, in addition to a lot of dedication and hard work by Se7en & others (but mostly thanks to Se7en):

http://www.theswamp.org/index.php?topic=39358.0


If, however, you'd rather not use the formatted code altogether, consider this post.

HTH

Not to denigrate anyone's work, it's just that the code is hard to read using the predefined colors and font.  Most don't use the Courier font (I think I saw a survey once, and Lucida Sans Typewriter, which is what I've used for many years, is the #1 choice).

And, the background color in my Visual Studio editor is Indigo   :laugh:

BlackBox

  • King Gator
  • Posts: 3770
Re: Wrapping command actions
« Reply #16 on: May 09, 2012, 03:40:39 PM »
Not to denigrate anyone's work, it's just that the code is hard to read using the predefined colors and font.  Most don't use the Courier font (I think I saw a survey once, and Lucida Sans Typewriter, which is what I've used for many years, is the #1 choice).

Not at all, Tony, and I appreciate your saying that... I don't believe anyone was intentionally (or otherwise) denigrating others' work. I know Zoltan outside of the TheSwamp, so I was just trying to share what I knew, in a quick post while at my day job.  :wink:

Admittedly, there are things I dislike about the new code tags (i.e., the lack of scroll bar, forcing the code to post in full length, etc.). I only meant to point out that the current state of all things code tags is the result of a long experiment in feature enhancement.... more importantly, that the legacy [code ] tags are still available (manually).

And, the background color in my Visual Studio editor is Indigo   :laugh:

I'm considering changing my theme over to the Dark Side (from default).   :mrgreen:

/offtopic

Cheers! :beer:
"How we think determines what we do, and what we do determines what we get."

TheMaster

  • Guest
Re: Wrapping command actions
« Reply #17 on: May 09, 2012, 03:52:11 PM »

The purpose of the wrapper functions is not to reduce the number of lines of code.  It is to make to code more granular and to abstract out what is common, encapsulating that common logic in it's own class and allowing it to change at run time.


Sorry to disagree, but in the case of your abstractions of try/catch, transactions, and document locking, to me it looks more like a case of abstraction only for abstraction's sake, and without any higher-order purpose or goal to doing it.

In the example I showed, the abstraction can be justified because it promotes and supports the separation of code based on whether it is dependent on the application layer, or only dependent on the database layer.

That's a good a example of where abstraction has a higher purpose, but I see no higher-order purpose or objective to your abstraction of document locking and transactions separately, and going back to the example in your first post, where you use all three of those abstractions, the only purpose it serves other than to avoid repetition of common error handling code, is to obfuscate the purpose and function of the application-level code.

Can you demonstrate a good reason for/purpose to abstracting transactions and document locking (separately, rather than all-inclusively as my example does) ?

In addition, abstracting try/catch (as opposed to just exposing a shared API that has common error handling code that can be called explicitly from a catch{} block), is a problem, because it does not allow the exception handling code in the catch block to access objects in the local scope of the called action.

I have plenty of code here that uses try/catch, where the code in the catch{} block must access local variables or member variables of the class containing the method that contains the try/catch block, and if I were to abstract out the try/catch as you do, that would not be possible.


TheMaster

  • Guest
Re: Wrapping command actions
« Reply #18 on: May 09, 2012, 04:03:45 PM »

I'm considering changing my theme over to the Dark Side (from default).   :mrgreen:

/offtopic

Cheers! :beer:

I just looked at that, and don't see how medium-dark blue text on a black background is any better than yellow or lime on a white background :laugh:.

My eyesight is far from perfect and for me, higher-contrasting colors is necessary (and is one reason why I think Autodesk's website with medium-gray text on black background is one of the most poorly-designed websites on the internet, especially for its blatant disregard for the visually-impaired).

I use a dark background in VS for the same reason I use a black background in AutoCAD - because it makes it easier to resolve different shades of the same color, and therefore allows me to use more colors.


Jeff H

  • Needs a day job
  • Posts: 6144
Re: Wrapping command actions
« Reply #19 on: May 09, 2012, 04:07:27 PM »
I like my colors to resemble my code so I set my VS background to doodoo brown.
 
 
 

BlackBox

  • King Gator
  • Posts: 3770
Re: Wrapping command actions
« Reply #20 on: May 09, 2012, 04:08:09 PM »

I'm considering changing my theme over to the Dark Side (from default).   :mrgreen:

/offtopic

Cheers! :beer:

I just looked at that, and don't see how medium-dark blue text on a black background is any better than yellow or lime on a white background :laugh:.

Laughably, I am very comfortable with the VLIDE colors, and this (the Dark Side theme) is the best that I've found thus far... Not that it's perfect, I'd still want to make some personalized changes. Just saying.

My eyesight is far from perfect and for me, higher-contrasting colors is necessary (and is one reason why I think Autodesk's website with medium-gray text on black background is one of the most poorly-designed websites on the internet, especially for its blatant disregard for the visually-impaired).

I use a dark background in VS for the same reason I use a black background in AutoCAD - because it makes it easier to resolve different shades of the same color, and therefore allows me to use more colors.

My third and final time posting this (today), but so applicable it cannot be avoided :lol:....


"How we think determines what we do, and what we do determines what we get."

Jeff H

  • Needs a day job
  • Posts: 6144
Re: Wrapping command actions
« Reply #21 on: May 09, 2012, 05:33:28 PM »
It maybe would have been nice if AutoDesk added property to CommandAttribute that told it to add and start a transaction before calling you method and commiting it when control was returned and maybe exposed CancelCommit or you would have access to it with TopTransaction property.
 
 
Maybe for 5.0 if possible with Roslyn project to call dispose on all newly created Dbobjects that are not added to the Database when they fall out of scope.

TheMaster

  • Guest
Re: Wrapping command actions
« Reply #22 on: May 10, 2012, 07:08:57 PM »
It maybe would have been nice if AutoDesk added property to CommandAttribute that told it to add and start a transaction before calling you method and commiting it when control was returned and maybe exposed CancelCommit or you would have access to it with TopTransaction property.


The problem there is that I have very few commands implemented in .NET
that unconditionally start and commit a transaction. Most of those that do,
only do after all user interaction is done, and the user hasn't decided to
bail out.  Ditto for document locking.

I think one would be hard-pressed to find very many cases where either or
both a transaction and a document lock wrap the entire implementation
of a .command method.

One problem with the OP's wrapper for try/catch is that it doesn't rethrow the
exception, which means that it could only be useful when it wraps the entire
command implementation. If it were used in any other context, and there was
more code following the call to execute the action, that code would run as if no
error had occurred.

The .NET  Application object has an event that fires when an exception is raised
and is not handled, which is how most do exception logging, but that event does
not get fired in AutoCAD and I think that's a notable deficiency, because if there
was an event that could be used to intercept unhandled exceptions, it would be
a far better way to solve the problem which the OP's wrapper tries to solve.

Quote
Maybe for 5.0 if possible with Roslyn project to call dispose on all newly created Dbobjects that are not added to the Database when they fall out of scope.

It's not when a DBObject wrapper goes out of scope, it's when it becomes
unreachable through code (and becomes eligible for garbage collection) that
would be the trigger.  If there's only one variable on the stack referencing a
DBObject, then it is simple, but the problem is there's no easy way to find out
when an object has become unreachable, and compiler extensions you speak
of (Rosyln) that allow you to hook into the compilation process won't really
help with that problem. The garbage collector itself doesn't even know when
an object becomes unreachable, it must scan the heap and stack each time it
does a sweep to find out.