.NET
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

With new 2007 API, can .net be used as dialog engine for lisp?

10 REPLIES 10
Reply
Message 1 of 11
Anonymous
343 Views, 10 Replies

With new 2007 API, can .net be used as dialog engine for lisp?

As I transition large apps I have from lisp and ObjectDCL to .net, I am wondering if I can essentially use.net like
ODCL. In other words, my lisps would have access to dialog box (form) properties and events, and the dialog would be
able to run lisp code. I want to be able to have some callbacks be in .net and some be lisp functions.
It would be the ultimate mix.

Here are the things it would have to do:
1) Callback functions of .net dialog would fire lisp functions, then get focus back
ODCL handles this by giving the callbacks c: function names

2) Props of dialog controls would be accessible from lisp, so I could say, change a button color from lisp.
ODCL handles this with a function provided by its arx "resource" file that has to be loaded.
It allows you to specify the dialog name, control name, property and new value.

3) Callbacks of .net dialog could be fired from lisp.
Now this would only apply to modeless dialogs. I want to be able to run the same code that a button pick might fire.
You need this for refreshing controls at various times.

Feel free to point me to the sdk help file if thats where I should look. I am still getting the hang of investigation
the various .net assemblies provided for acad.
James Maeding
Civil Engineer and Programmer
jmaeding - athunsaker - com
10 REPLIES 10
Message 2 of 11
Anonymous
in reply to: Anonymous

No, No, and No.

To use .NET you need to use a .NET language, not LISP.

The managed wrappers for .NET provide the same level of
extensibility and interoperability that native C++ based
ObjectARX offers to LISP, namely the ability to call .NET
code from LISP (externally defined functions), and for
those functions to return results from .NET to calling LISP
code. IOW, nothing related to user interface development.

Many aspects of .NET user interface code are encapsulated
as .NET objects, which LISP has no concept of, so there is
no easy way to weave them together.

While its possible to use .NET to develop 'front ends' for
LISP based applications, there would need to be a clean
separation between the two, with the LISP side having no
role or interaction with the .NET user interface side.

So, you would need to develop the user interface in .NET,
using a .NET langauge; call that from LISP; and it can
return data to the calling LISP, which it would use to do
the work.


--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006/2007
http://www.acadxtabs.com

"James Maeding" wrote in message news:5148081@discussion.autodesk.com...
As I transition large apps I have from lisp and ObjectDCL to .net, I am wondering if I can essentially use.net like
ODCL. In other words, my lisps would have access to dialog box (form) properties and events, and the dialog would be
able to run lisp code. I want to be able to have some callbacks be in .net and some be lisp functions.
It would be the ultimate mix.

Here are the things it would have to do:
1) Callback functions of .net dialog would fire lisp functions, then get focus back
ODCL handles this by giving the callbacks c: function names

2) Props of dialog controls would be accessible from lisp, so I could say, change a button color from lisp.
ODCL handles this with a function provided by its arx "resource" file that has to be loaded.
It allows you to specify the dialog name, control name, property and new value.

3) Callbacks of .net dialog could be fired from lisp.
Now this would only apply to modeless dialogs. I want to be able to run the same code that a button pick might fire.
You need this for refreshing controls at various times.

Feel free to point me to the sdk help file if thats where I should look. I am still getting the hang of investigation
the various .net assemblies provided for acad.
James Maeding
Civil Engineer and Programmer
jmaeding - athunsaker - com
Message 3 of 11
Anonymous
in reply to: Anonymous

This isn't likely to be of much help: it does appear that there are a few
LISP implementations in .NET: http://www.google.com/search?hl=en&q=LISP+.NET

As far as AutoCAD is concerned, using a .NET implementation of LISP is
completely and entirely unrelated to AutoLISP. I suspect there would be a
fair amount of confusion resulting from just using two different LISP
enviroments at the same time.

Dan

"Tony Tanzillo" wrote in message
news:5148154@discussion.autodesk.com...
No, No, and No.

To use .NET you need to use a .NET language, not LISP.

The managed wrappers for .NET provide the same level of
extensibility and interoperability that native C++ based
ObjectARX offers to LISP, namely the ability to call .NET
code from LISP (externally defined functions), and for
those functions to return results from .NET to calling LISP
code. IOW, nothing related to user interface development.

Many aspects of .NET user interface code are encapsulated
as .NET objects, which LISP has no concept of, so there is
no easy way to weave them together.

While its possible to use .NET to develop 'front ends' for
LISP based applications, there would need to be a clean
separation between the two, with the LISP side having no
role or interaction with the .NET user interface side.

So, you would need to develop the user interface in .NET,
using a .NET langauge; call that from LISP; and it can
return data to the calling LISP, which it would use to do
the work.


--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006/2007
http://www.acadxtabs.com

"James Maeding" wrote in message
news:5148081@discussion.autodesk.com...
As I transition large apps I have from lisp and ObjectDCL to .net, I am
wondering if I can essentially use.net like
ODCL. In other words, my lisps would have access to dialog box (form)
properties and events, and the dialog would be
able to run lisp code. I want to be able to have some callbacks be in .net
and some be lisp functions.
It would be the ultimate mix.

Here are the things it would have to do:
1) Callback functions of .net dialog would fire lisp functions, then get
focus back
ODCL handles this by giving the callbacks c: function names

2) Props of dialog controls would be accessible from lisp, so I could say,
change a button color from lisp.
ODCL handles this with a function provided by its arx "resource" file that
has to be loaded.
It allows you to specify the dialog name, control name, property and new
value.

3) Callbacks of .net dialog could be fired from lisp.
Now this would only apply to modeless dialogs. I want to be able to run the
same code that a button pick might fire.
You need this for refreshing controls at various times.

Feel free to point me to the sdk help file if thats where I should look. I
am still getting the hang of investigation
the various .net assemblies provided for acad.
James Maeding
Civil Engineer and Programmer
jmaeding - athunsaker - com
Message 4 of 11
Anonymous
in reply to: Anonymous

Tony, thanks for the comments.
I had seen the comments in:
http://www.jtbworld.com/autocad2007.htm

and it mentioned
"Lisp-callable functions in .NET - Pass data to / from Auto LISP® application. Define functions which can be accessed
from AutoLISP."
for the 2007 .net API.

Essentially, if C++ can't do it, .net will not because its a "canned" version of .net for us that want managed memory
programming languages (me).

I am guessing I could use .net like old VB6 to make activex dll's, but thats not what I want.
Have you ever thought of writing something like ODCL, Tony?
I know you like to stick to the more cutting edge stuff, but look how popular it made Chad.

Don't worry, one of these days I will post a truly interesting question that does not involve lisp 🙂
Just not yet.

Tony Tanzillo
|>No, No, and No.
|>
|>To use .NET you need to use a .NET language, not LISP.
|>
|>The managed wrappers for .NET provide the same level of
|>extensibility and interoperability that native C++ based
|>ObjectARX offers to LISP, namely the ability to call .NET
|>code from LISP (externally defined functions), and for
|>those functions to return results from .NET to calling LISP
|>code. IOW, nothing related to user interface development.
|>
|>Many aspects of .NET user interface code are encapsulated
|>as .NET objects, which LISP has no concept of, so there is
|>no easy way to weave them together.
|>
|>While its possible to use .NET to develop 'front ends' for
|>LISP based applications, there would need to be a clean
|>separation between the two, with the LISP side having no
|>role or interaction with the .NET user interface side.
|>
|>So, you would need to develop the user interface in .NET,
|>using a .NET langauge; call that from LISP; and it can
|>return data to the calling LISP, which it would use to do
|>the work.
James Maeding
Civil Engineer and Programmer
jmaeding - athunsaker - com
Message 5 of 11
Anonymous
in reply to: Anonymous

Hey wait, Chad wrote ODCL in C++ (I am guessing), so it sounds like you could make it work.
Any comments on how he made the dialogs run lisp functions, then get focus back?

In other words, is there a huge difference in c++ verses .net abilities?
Do you think the .ent will ever be able to do something like ODCL?

Tony Tanzillo
|>No, No, and No.
|>
|>To use .NET you need to use a .NET language, not LISP.
|>
|>The managed wrappers for .NET provide the same level of
|>extensibility and interoperability that native C++ based
|>ObjectARX offers to LISP, namely the ability to call .NET
|>code from LISP (externally defined functions), and for
|>those functions to return results from .NET to calling LISP
|>code. IOW, nothing related to user interface development.
|>
|>Many aspects of .NET user interface code are encapsulated
|>as .NET objects, which LISP has no concept of, so there is
|>no easy way to weave them together.
|>
|>While its possible to use .NET to develop 'front ends' for
|>LISP based applications, there would need to be a clean
|>separation between the two, with the LISP side having no
|>role or interaction with the .NET user interface side.
|>
|>So, you would need to develop the user interface in .NET,
|>using a .NET langauge; call that from LISP; and it can
|>return data to the calling LISP, which it would use to do
|>the work.
James Maeding
Civil Engineer and Programmer
jmaeding - athunsaker - com
Message 6 of 11
Anonymous
in reply to: Anonymous

In general, there is not a huge difference between ObjectARX and the .NET
wrapper classes; the most obvious exception is that custom objects must be
created with native C++.

Note that with C++/CLI in Visual Studio 2005, you can easily do .NET stuff
from C++; there is no "C++ vs. .NET".

Dan

"James Maeding" wrote in message
news:5149382@discussion.autodesk.com...
Hey wait, Chad wrote ODCL in C++ (I am guessing), so it sounds like you
could make it work.
Any comments on how he made the dialogs run lisp functions, then get focus
back?

In other words, is there a huge difference in c++ verses .net abilities?
Do you think the .ent will ever be able to do something like ODCL?

Tony Tanzillo
|>No, No, and No.
|>
|>To use .NET you need to use a .NET language, not LISP.
|>
|>The managed wrappers for .NET provide the same level of
|>extensibility and interoperability that native C++ based
|>ObjectARX offers to LISP, namely the ability to call .NET
|>code from LISP (externally defined functions), and for
|>those functions to return results from .NET to calling LISP
|>code. IOW, nothing related to user interface development.
|>
|>Many aspects of .NET user interface code are encapsulated
|>as .NET objects, which LISP has no concept of, so there is
|>no easy way to weave them together.
|>
|>While its possible to use .NET to develop 'front ends' for
|>LISP based applications, there would need to be a clean
|>separation between the two, with the LISP side having no
|>role or interaction with the .NET user interface side.
|>
|>So, you would need to develop the user interface in .NET,
|>using a .NET langauge; call that from LISP; and it can
|>return data to the calling LISP, which it would use to do
|>the work.
James Maeding
Civil Engineer and Programmer
jmaeding - athunsaker - com
Message 7 of 11
Anonymous
in reply to: Anonymous

Dan,

Would you happen to have a sample class using C++/CLI? Been using
C# but like C++ better; glutton for punishment I guess, or I want to
justify the 70 bucks I spent on "Pro Visual C++/CLI" ...:)

Thank you,
Paul

--
gl - Paul
"J. Daniel Smith" wrote in message
news:5149527@discussion.autodesk.com...
In general, there is not a huge difference between ObjectARX and the .NET
wrapper classes; the most obvious exception is that custom objects must be
created with native C++.

Note that with C++/CLI in Visual Studio 2005, you can easily do .NET stuff
from C++; there is no "C++ vs. .NET".

Dan

"James Maeding" wrote in message
news:5149382@discussion.autodesk.com...
Hey wait, Chad wrote ODCL in C++ (I am guessing), so it sounds like you
could make it work.
Any comments on how he made the dialogs run lisp functions, then get focus
back?

In other words, is there a huge difference in c++ verses .net abilities?
Do you think the .ent will ever be able to do something like ODCL?

Tony Tanzillo
|>No, No, and No.
|>
|>To use .NET you need to use a .NET language, not LISP.
|>
|>The managed wrappers for .NET provide the same level of
|>extensibility and interoperability that native C++ based
|>ObjectARX offers to LISP, namely the ability to call .NET
|>code from LISP (externally defined functions), and for
|>those functions to return results from .NET to calling LISP
|>code. IOW, nothing related to user interface development.
|>
|>Many aspects of .NET user interface code are encapsulated
|>as .NET objects, which LISP has no concept of, so there is
|>no easy way to weave them together.
|>
|>While its possible to use .NET to develop 'front ends' for
|>LISP based applications, there would need to be a clean
|>separation between the two, with the LISP side having no
|>role or interaction with the .NET user interface side.
|>
|>So, you would need to develop the user interface in .NET,
|>using a .NET langauge; call that from LISP; and it can
|>return data to the calling LISP, which it would use to do
|>the work.
James Maeding
Civil Engineer and Programmer
jmaeding - athunsaker - com
Message 8 of 11
Anonymous
in reply to: Anonymous

As long as you're starting out, you might as well get your information
straight from the horse's mouth, so to speak. There's a lot of information
scattered around on MSDN and various Microsoft blogs; one place to start
might be Herb Sutter's blog and his "A Design Rationale for C++/CLI" at
http://pluralsight.com/blogs/hsutter/archive/2006/02/27/19271.aspx

One of the goals for C++/CLI is to make it a first-class .NET language; the
Managed Extensions for C++ never felt right when compared to C#. With
C++/CLI, one primary motivation for using C# over C++ is that you get a
simpler and "cleaner" language: both C++ and VB.NET have some legacy
constructs.

Dan

"Paul Richardson" wrote in message
news:5149794@discussion.autodesk.com...
Dan,

Would you happen to have a sample class using C++/CLI? Been using
C# but like C++ better; glutton for punishment I guess, or I want to
justify the 70 bucks I spent on "Pro Visual C++/CLI" ...:)

Thank you,
Paul

--
gl - Paul
"J. Daniel Smith" wrote in message
news:5149527@discussion.autodesk.com...
In general, there is not a huge difference between ObjectARX and the .NET
wrapper classes; the most obvious exception is that custom objects must be
created with native C++.

Note that with C++/CLI in Visual Studio 2005, you can easily do .NET stuff
from C++; there is no "C++ vs. .NET".

Dan

"James Maeding" wrote in message
news:5149382@discussion.autodesk.com...
Hey wait, Chad wrote ODCL in C++ (I am guessing), so it sounds like you
could make it work.
Any comments on how he made the dialogs run lisp functions, then get focus
back?

In other words, is there a huge difference in c++ verses .net abilities?
Do you think the .ent will ever be able to do something like ODCL?

Tony Tanzillo
|>No, No, and No.
|>
|>To use .NET you need to use a .NET language, not LISP.
|>
|>The managed wrappers for .NET provide the same level of
|>extensibility and interoperability that native C++ based
|>ObjectARX offers to LISP, namely the ability to call .NET
|>code from LISP (externally defined functions), and for
|>those functions to return results from .NET to calling LISP
|>code. IOW, nothing related to user interface development.
|>
|>Many aspects of .NET user interface code are encapsulated
|>as .NET objects, which LISP has no concept of, so there is
|>no easy way to weave them together.
|>
|>While its possible to use .NET to develop 'front ends' for
|>LISP based applications, there would need to be a clean
|>separation between the two, with the LISP side having no
|>role or interaction with the .NET user interface side.
|>
|>So, you would need to develop the user interface in .NET,
|>using a .NET langauge; call that from LISP; and it can
|>return data to the calling LISP, which it would use to do
|>the work.
James Maeding
Civil Engineer and Programmer
jmaeding - athunsaker - com
Message 9 of 11
HermanMayfarth
in reply to: Anonymous

James -

It does not make sense to me that you would wish to do what you have suggested, and particularly for modeless dialogs.

AutoLISP is now, & most likely always will be, a single document oriented language, whereas the *.net languages are inherently mdi, AFAIK.

The available Windows Forms controls should look very familiar to you if you use ODCL. Using this interface, you won't have to jump through hoops to change document context, nor worry about all those global LISP variables with (necessarily) very long variable names with which ODCL burdens your code.

No offense to Chad Wanless, because I think he is a clever guy, but using AutoLISP to write mdi applications seems to me like rowing upstream in a square-ended rowboat, given tha available alternatives.
Message 10 of 11
Anonymous
in reply to: Anonymous

It makes sense if it means I don't have to rewrite 50k lines of lisp code.
I have a huge library of subroutines and converting over to .net will take a while.
I will admit I have not gotten any lisp progs (with ODCL dialogs) to work accross documents, even though ODCL has things
to make it work.
I only need MDI capability for one prog I did, and its for LDT which requires SDI to be not zero.

I have always liked the structure of VB and now vb.net better than lisp, but its all about how slick you can make an
interface. Note that this includes command line interaction which lisp does very well. I am slowly learning how .net
covers my needs, but vb6/vba does not do it.

I don't care though, these new languages are fun.

I have done a lot of vb6 programming, and .net does seem pretty easy to pick up on, but takes time to soak in all the
different things. Its just a matter of time, sure glad these NG's are here.

I will have to look at how variables are handled in .net as far as across documents. I'm still very green at .net.
thx


Herman Mayfarth <>
|>James -
|>
|>It does not make sense to me that you would wish to do what you have suggested, and particularly for modeless dialogs.
|>
|>AutoLISP is now, & most likely always will be, a single document oriented language, whereas the *.net languages are inherently mdi, AFAIK.
|>
|>The available Windows Forms controls should look very familiar to you if you use ODCL. Using this interface, you won't have to jump through hoops to change document context, nor worry about all those global LISP variables with (necessarily) very long variable names with which ODCL burdens your code.
|>
|>No offense to Chad Wanless, because I think he is a clever guy, but using AutoLISP to write mdi applications seems to me like rowing upstream in a square-ended rowboat, given tha available alternatives.
James Maeding
Civil Engineer and Programmer
jmaeding - athunsaker - com
Message 11 of 11
Anonymous
in reply to: Anonymous

. . . so, there is NO HOPE for an ObjectDCL2007.arx ?

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk DevCon in Munich May 28-29th


Autodesk Design & Make Report

”Boost