Author Topic: error: null interface pointer ..  (Read 18605 times)

0 Members and 1 Guest are viewing this topic.

LE

  • Guest
Re: error: null interface pointer ..
« Reply #30 on: November 02, 2005, 11:30:15 PM »
As far as release is concerned, is it only when you create an object or also when you do this?
Code: [Select]
(setq obj (vlax-ename->vla-object ename))that you need to release the object.

I gather that this code need no release?

No.

Sdoman

  • Guest
Re: error: null interface pointer ..
« Reply #31 on: November 02, 2005, 11:31:30 PM »
BTW. Thanks for the input guys. This turned into a really interesting thread.


As so to conclude, the answer was...

Sdoman

  • Guest
Re: error: null interface pointer ..
« Reply #32 on: November 02, 2005, 11:34:22 PM »
To use code that validates whether an object is released before reassigning.
To use unique symbol names.
To use a protected namespace.
To do whatever MP suggested (it was over my head)

Kerry

  • Mesozoic relic
  • Seagull
  • Posts: 11654
  • class keyThumper<T>:ILazy<T>
Re: error: null interface pointer ..
« Reply #33 on: November 02, 2005, 11:38:19 PM »
Something else that MAY be interesting

(setq xxDoc (vla-get-activedocument (vlax-get-acad-object)))
;->> #<VLA-OBJECT IAcadDocument 01270930>

(vlax-release-object xxDoc)
;->> 3   <- This is the current reference count on the Active document.


(repeat 100
   (setq xxDoc (vla-get-activedocument (vlax-get-acad-object)))
)

(vlax-release-object xxDoc)
;->> 102 <- This is the current reference count on the Active document.
;;  can be released with Garbage collection .. ? ?  ?
« Last Edit: November 02, 2005, 11:46:50 PM by Kerry Brown »
kdub, kdub_nz in other timelines.
Perfection is not optional.
Everything will work just as you expect it to, unless your expectations are incorrect.
Discipline: None at all.

Sdoman

  • Guest
Re: error: null interface pointer ..
« Reply #34 on: November 02, 2005, 11:42:48 PM »
Quote
hmmmm...... I tried there, but had no luck at-all.... I think it will be better if I just grab some of my PRJ projects and send it via PM.....

Ok Luis if you would rather, please PM me.  But It's getting late in the evening here.  So I may not be able to reply until tommorrow.

Kerry

  • Mesozoic relic
  • Seagull
  • Posts: 11654
  • class keyThumper<T>:ILazy<T>
Re: error: null interface pointer ..
« Reply #35 on: November 02, 2005, 11:43:34 PM »
kdub, kdub_nz in other timelines.
Perfection is not optional.
Everything will work just as you expect it to, unless your expectations are incorrect.
Discipline: None at all.

Sdoman

  • Guest
Re: error: null interface pointer ..
« Reply #36 on: November 03, 2005, 12:15:01 AM »
More Here :- http://www.theswamp.org/forum/index.php?topic=2005.0

A good read Kerry.  So to release or not release continues to puzzle.

MP

  • Seagull
  • Posts: 17750
  • Have thousands of dwgs to process? Contact me.
Re: error: null interface pointer ..
« Reply #37 on: November 03, 2005, 06:47:37 AM »
A good read Kerry. So to release or not release continues to puzzle.

So it seems. That last post was a rather bleak conclusion.

:(
Engineering Technologist • CAD Automation Practitioner
Automation ▸ Design ▸ Drafting ▸ Document Control ▸ Client
cadanalyst@gmail.comhttp://cadanalyst.slack.comhttp://linkedin.com/in/cadanalyst

LE

  • Guest
Re: error: null interface pointer ..
« Reply #38 on: November 03, 2005, 10:03:39 AM »
The following description is still basically the same as it was from Vital Lisp help.....

"No memory is necessarily freed when you issue vlax-release-object, but AutoCAD can reclaim the memory if needed, once all references to the object have been released."

whdjr

  • Guest
Re: error: null interface pointer ..
« Reply #39 on: November 03, 2005, 10:07:19 AM »
Right or wrong here's my take Kerry  --

I dropped the use of wrapped globals for activedocument etc. long ago for a number of reasons, including the testing that the wrappers tend to do.

Instead I tend to write functions so they take the activedocument, modelspace, or layers collection etc. as an argument. The calling function is shouldered with the responsibility to pass a valid argument, and for any subsequent cleanup etc. Any overhead associated with repeated calls to create the object is avoided IF the caller takes care of setting aside a reference to said object before making the functions calls.

In it's simplest form.

Code: [Select]
(defun c:MtProggy ( / foo main )

    (defun foo ( object )
        ;;  foo takes an object, but doesn't
        ;;  care how it comes into existance
        ...
    )

    (defun main ( / object )

        ;;  create the object
   
        (setq object
            (SomeCallThatResultsInObject)
        )

        ;;  use the object ad nauseum
       
        (repeat (SomeCallThatReturnsIterationCount)
            (foo object)
        )

        ;;  dump it
       
        (vl-catch-all-apply
           '(lambda ( )
                (vlax-release-object object)
            )
        )
       
        (princ)
       
    )
   
    (main)

)

No worries of double references, things going out of scope etc. Perhaps I look at this too simplistically, but this works and performs well for me.

/2¢

I didn't realize you could name your defun's as arguments.  How exactly would that help you?  How come you don't get some kind of error?  That is kinda weird to think about. :lol:

MP

  • Seagull
  • Posts: 17750
  • Have thousands of dwgs to process? Contact me.
Re: error: null interface pointer ..
« Reply #40 on: November 03, 2005, 10:15:10 AM »
Eh?

The defuns are locals, not arguments, though you can write functions that take functions as arguments (as demonstrated elsewhere).

:)
Engineering Technologist • CAD Automation Practitioner
Automation ▸ Design ▸ Drafting ▸ Document Control ▸ Client
cadanalyst@gmail.comhttp://cadanalyst.slack.comhttp://linkedin.com/in/cadanalyst

CAB

  • Global Moderator
  • Seagull
  • Posts: 10401
Re: error: null interface pointer ..
« Reply #41 on: November 03, 2005, 11:28:10 AM »
Will,
Code: [Select]
;;=======================
(defun c:test1 ()
  (defun foo ()
    (print "Test1 - foo.")
  )
  (foo)
  (princ)
)
(c:test1)
(print (type foo))
(setq foo nil)


;;=======================
(defun c:test2 (/ foo)
  (defun foo ()
    (print "Test2 - foo.")
  )
  (foo)
  (princ)
)
(c:test2)
(print (type foo))
(print)
;;=======================

"Test1 - foo."
USUBR
"Test2 - foo."
nil
I've reached the age where the happy hour is a nap. (°¿°)
Windows 10 core i7 4790k 4Ghz 32GB GTX 970
Please support this web site.

whdjr

  • Guest
Re: error: null interface pointer ..
« Reply #42 on: November 03, 2005, 11:38:04 AM »
Sorry...I mis-typed earlier...I meant "I didn't realize you could have defun's as local variables?".

And I still don't see the importance in why you would do that.  I see CAB's explanation but I am still asking:
1.  Where would you use that set up?
2.  Why would you use that set up?
3.  How would you even think to use that set up? :|

I know I would not have thought to use defuns and locals.  I know it localizes your defun but what would you gain from doing that?

whdjr

  • Guest
Re: error: null interface pointer ..
« Reply #43 on: November 03, 2005, 11:39:40 AM »
So does that mean any time I have a 'nested' defun I should also name it as a local (as good coding practice)?

Sdoman

  • Guest
Re: error: null interface pointer ..
« Reply #44 on: November 04, 2005, 08:43:04 AM »
So does that mean any time I have a 'nested' defun I should also name it as a local (as good coding practice)?

Yes, that's right.  Let me see if I can explain without muffing it up....

If you have a c:function that requires some subfunctions that are designed to be used only for that c:function, then I personally prefer to embed them inside the c:function and declare them local.

The reasoning is that by embedding these particular dedicated subfunctions inside the c:function and delcaring them local, I know that they are used only for that c:function and I don't have to worry about them over writting, or being overwritten, by some other lisp routine that happens to be lurking out there, and happens to have a function with the same name.

Thus it is a good practice to declare local variables and local subs, so that when the routine ends, it leaves the lisp environment squeaky clean.

One downside however, to embedding local subfunctions inside c:functions is that every time the user invokes the c:function, those subs are reloaded.  That's sort of a waste of time to continually reload the subs, but with the fast PC's we all have now, the time usually isn't perceived by the user.  If on the other hand I had some huge subfunction that took a lot of time to load, then I might locate that fat sub outside of the c:function and just call it just like a toolbox function.

For those subfunctions that might be useable for other routines, then I always put them in a toolbox lisp file which I have setup to load automatically when the drawing is opened. These toolbox subs are not declared local.

Does that help?