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

Hmmm, where do I put this info?

7 REPLIES 7
Reply
Message 1 of 8
jeffrey.ries
450 Views, 7 Replies

Hmmm, where do I put this info?

Please be gentle, I am new to .NET Man Embarassed

 

I have been writing lisp + openDCL for years, but I understand it's limitations.  Recently I drew a line in the sand and told myself that I would no longer write new commands in lisp.  I am forcing myself to adapt.

 

My project is a simple dialog filled with checkboxes and a few buttons.  Basically it is an options dialog.

 

I have designed the dialog and written many functions which handle the actions of selecting and unselecting groups of checkboxes.  Really the only thing I have not done is the 'OK' button.  Once I started I quickly realized I am planning my actions as if I am writing in lisp.

 

In lisp I would save the results of the users choices into a single symbol as a list.  An alternative is to write out to a txt file, but I would rather avoid it.  This was ideal because I have many other lisp functions which would then access that symbol's info to guide their execution.

 

I would write (setq nameOfSymbol blah, blah, blah).  I don't see a reasonable alternative in VB.NET where the info would still be accessable after the command finished executing.

 

Am I approaching this from the wrong angle?

 

How would a seasoned veteran to VB.NET leave a message in a bottle for other functions to access?

 

Thank you,

Jeff

Detroit, MI

7 REPLIES 7
Message 2 of 8


@jeffrey.ries wrote:

 

Am I approaching this from the wrong angle?

 


Yes.

 

In .NET, the simplest way is to build a class that contains properties representing the values that a user can see and edit in your UI. Then, you can use data binding to connect the UI controls to an instance of the class and everything else happens automatically. When the user clicks OK, the values in the instance of your class are the values they specified or changed.

 

If you're just starting out with .NET, then you have quite a bit of a learning curve ahead, and you should focus first on the basics of using the programming langauge and the framework, before attempting more complicated stuff, or you will be finding yourself spending a lot of time building things only to end up throwing them out and starting over again, after having learned what was wrong with the previous attempt(s).

 

Message 3 of 8

I understand the road ahead of me and I look forward to it.  I have already done quite a bit of research and education into VB, and I am at a place where I need to dive in and create some functioning commands if I am to fully grasp how it all works.  I have no issue with writing and then re-writing, that is an important part of learning.

 

I do have a basic understanding of classes and instances, but I do not understand how the interact with the AutoCAD drawing itself.  If I store the outcome of the users choices in an instance of a class then is that information accessable by other existing lisp commands or only by VB?

 

Jeff

Detroit, MI

Message 4 of 8
arcticad
in reply to: jeffrey.ries

As I also came from a LISP background... oh the pain.
You can store variables in a number of locations.
Dictionaries, XData/XRecords, System Registry, Text File, USERS1-S5 user Variables
But you can't use a setq and just have the variable floating in space for use
by other programs.

---------------------------



(defun botsbuildbots() (botsbuildbots))
Message 5 of 8


@jeffrey.ries wrote:

 

I do have a basic understanding of classes and instances, but I do not understand how the interact with the AutoCAD drawing itself.  If I store the outcome of the users choices in an instance of a class then is that information accessable by other existing lisp commands or only by VB?

 

Jeff

Detroit, MI


Well, understanding classes means you understand that they are things that exist only in the domain of the .NET framework, which LISP has no access to.

 

If you need to communicate data with LISP, you have to write code that can be called from LISP and can return the values to the user in a form that can be consumed from LISP. Lisp cannot use .NET classes directly, so you have to translate the data into a form that can be transferred to LISP. You  can write .NET functions in VB that can be called from LISP, and can return values back to LISP callers. The LispFunction attribute is how to do that (see the docs).

Message 6 of 8


@arcticad wrote:

As I also came from a LISP background... oh the pain.
You can store variables in a number of locations.
Dictionaries, XData/XRecords, System Registry, Text File, USERS1-S5 user Variables
But you can't use a setq and just have the variable floating in space for use
by other programs.


Putting data into a drawing (that is subject to UNDO) isn't really necessary in order to transfer it between LISP and .NET.   apps. There is VL.Application, which can be used from .NET code, and there is the LispFunction attribute that allows .NET methods to be called from LISP.

 

 

Message 7 of 8
jeffrey.ries
in reply to: arcticad


@arcticad wrote:


But you can't use a setq and just have the variable floating in space for use
by other programs.


As it turns out I can.  I figured out a clumsy way to make most of this work.

 

In VB.NET I am gathering the user's choices and concatenating them into a single string.  Then I'm using SendStringToExecute to create the symbol.

 

Each response has a unique text string, so all I have to do in lisp is to wcmatch it.

 

The only part I have not figured out so far is that when I re-run the command I then need VB.NET to read the symbol so that it can re-populate the results.  That way the user is not starting over from scratch.

 

Even if I cannot get this part to work it will be good enough for the needs of this project.

 

I understand this is not an ideal solution, but I need to start somewhere in .NET.  This particular project must communicate with lisp, and if I just give in and resort back to writing in lisp I may never make the change over.

 

Jeff

Detroit, MI

Message 8 of 8


@jeffrey.ries wrote:

@arcticad wrote:


But you can't use a setq and just have the variable floating in space for use
by other programs.


As it turns out I can.  I figured out a clumsy way to make most of this work.

 

......

 

I understand this is not an ideal solution, but I need to start somewhere in .NET.  This particular project must communicate with lisp, and if I just give in and resort back to writing in lisp I may never make the change over.

 


Usually, these sorts of kludges don't really work in actual use. They're only misperceived as working because the person that chose to use them didn't consider every possible scenario where the kludge fails and/or properly test it to identify those scenarios, and so they don't learn that it doesn't work until they actually try to implement and deploy it.

 

I woudln't call what you refer to as 'not an ideal solution' a solution at all. It's not terribly difficult to communicate data between LISP and managed code, provided you understand a few basic concepts. At the point where your code falls apart under real-world use, then you might understand that better.

 

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