TheSwamp
Code Red => VB(A) => Topic started by: ML on December 20, 2007, 11:01:43 AM
-
Hi
I created a Selection Set in VBA called "Im" but my question is once in ACAD, can I still refer to that Sset name?
In other words, In ACAD, if I type Select, I realize that I can type P for Previous but is there anyway to type
Select then Im and have that selection set be recognized in ACAD?
Thanks!
Mark
-
I don't believe so.
I've written a hack (and it was ugly) to be able to use a selection set from a routine as 'previous' after the routine finished writing. I don't have it off had, it may be at the swap somewheres. It involved writing bogus xdata to the objects.
-
Yikes! Sounds scary :)
This is one of those things in ACAD that make absolutely no sense.
We can create all these Selection Sets and filters etc. in VBA however, once we get to ACAD, we can not refer to them by name anymore? That is silly.
I wonder about the group method? I haven't looked at it closely yet.
Also, in ACAD, we can create filters and refer to them by name but I am not sure that we can create one in VBA and then be able to refer to it in ACAD.
There is something I "may" be able to do, but should not have to.
I can possibly send (using a function I have) The ACAD Variable Sset to LISP, then "may be" it (the selection set)will then be recognized at least by using !Sset in ACAD, hummmm.
There must be a way to refer to the named sset in ACAD
Mark
-
I can possibly send (using a function I have) The ACAD Variable Sset to LISP, then "may be" it (the selection set)will then be recognized at least by using !Sset in ACAD, hummmm.
I meant to say The VBA Variable Sset to LISP
OMG! :lol:
Mark
-
Hi
I created a Selection Set in VBA called "Im" but my question is once in ACAD, can I still refer to that Sset name?
In other words, In ACAD, if I type Select, I realize that I can type P for Previous but is there anyway to type
Select then Im and have that selection set be recognized in ACAD?
Thanks!
Mark
As I and others said in this (http://www.theswamp.org/index.php?topic=20519.0) thread, for all intents and purposes, no.
-
Although with a wee bit of lisp it can be done.....
Command: select
Select objects: (getvbss "Im")
<Selection set: 18>
7 found
Select objects:
Command:
Here's the lisp:
(defun getVBss (name / ss ssnew)
(if (not (vl-catch-all-error-p
(vl-catch-all-apply
'(lambda ()
(setq ss (vla-item
(vla-get-selectionsets
(vla-get-activedocument
(vlax-get-acad-object)
)
)
name
)
)
)
)
)
)
(progn
(setq ssnew (ssadd))
(vlax-for ent ss
(ssadd (vlax-vla-object->ename ent) ssnew)
)
)
)
ssnew
)
Remember that named SS's are case-sensitive.
-
Jeff
Thanks for the code!
I need to look at it still
Do I have to put that into VLISP and save it to a specific file type?
Hey, do you think it is possible to put that code right into VBA?
With a reference to VLISP
Set VL = CreateObject(VL.Application.16)
I'm going to say, yes we can.
Actually this may even work well as a function in VBA
What do you think?
Mark
-
First, your welcome.
However, I think mixing lisp and VBA is borderline nutzoid..... the VLAX.CLS sortof exemplifies that.
Yes, I showed a way of converting an ActiveX SS to an ename based SS, but it also means that Glenn was right. "For all intents and purposes, no." You cannot get it in Acad as you asked, you need some lisp-trickery to do so.
I would just save it as "getVBss.lsp" and load it via your VBA macro or the Toolbar button you start the macro with, or any number of things before I'd add the lisp code into the DVB.
Dare I ask what the net result of all this is? IOW, why not keep your code in VBA? (Which, btw, is what Glenn has tried to guide you towards.)
-
First, your welcome.
However, I think mixing lisp and VBA is borderline nutzoid..... the VLAX.CLS sortof exemplifies that.
Yes, I showed a way of converting an ActiveX SS to an ename based SS, but it also means that Glenn was right. "For all intents and purposes, no." You cannot get it in Acad as you asked, you need some lisp-trickery to do so.
I would just save it as "getVBss.lsp" and load it via your VBA macro or the Toolbar button you start the macro with, or any number of things before I'd add the lisp code into the DVB.
Dare I ask what the net result of all this is? IOW, why not keep your code in VBA? (Which, btw, is what Glenn has tried to guide you towards.)
Hi Jeff,
Thanks again! Of course you can ask me; you can ask anything.
If someone just says don't do it, it's crazy without giving some examples, then it will not always deter them.
As to that VLAX Class, I did not use it, nor would I
However, the 2 narrowed down functions that I posted have worked very well for me.
I was able to use the getfiled and setq method with LISP along with my VBA code and I have encountered absolutely 0 problems.
Yes! I do have a version using The Open FIle Dialog method but that is a lot of code for such little return such as prompting the user with a dialog box to pick one file. Of course, I'd rather do it all in VBA when possible and it makes sense. I also use VBScripting code a lot for other reasons but "may be" that is OK; it seems to work fine.
Thank you again for the code; I will do as you suggested; I will make a seperate routine and load it with THe VBA project.
I was planning on coming in this morning and trying it, then all this. OMG!
Jeff, I not the most experienced programmer and I simply asked if it could be incorporated and I do ppreciatte your answer that it would be too difficult and not make sense. I simply though because we can connect to THe VLISP Type Library, that it may be possible; I did not realize I was being nutzoid by asking that, so I apologize. Therefore, I will not try it and I will go try you .lsp routine.
Thank you
Mark
-
Jeff
I just tried the lisp routine; it is working great!
Thank you again!
Mark
-
Mark,
While it had nothing to do with selection sets, it had everything to do with the fact you are trying to pass lisp and VBA variables back & forth between the 2. Again, he was trying to steer you away from the inevitable head banging that will occur (is occurring?).
In that thread that Glenn mentioned, you say you don't like the FileOpenDialog code because it's so long. Thing is, it's already written so it's not like you have to rewrite it every time it's used. The same, exact, thing holds true when you use the VL.Application. THAT code is probably much larger than the one you are trying not to use. No, you don't see it, but it's there just the same. So instead of adding one small bit of code to your macro, you reference one which is much larger.
Does that make sense? Please note I'm not trying to lambast you for doing it the way you have. I'm just trying to explain why others have tried steering you in other directions. Many of them, myself included, have been down the road you are on.
The following should have been placed in that other thread, but I'm typing now so here it is. :-)
And, FWIW, I DO use the VLAX.CLS in all of it's ugliness, in association with another one Frank O put together, the CURVE.CLS, which exposes the (vlax-curve-*) lisp functions to VBA. Sure they are ugly, but they are tools that worked to get the job done without having to reinvent the wheel. However, if there was a VBA specific way to get Curve data without the VLAX.CLS & CURVE.CLS, I sure would've jumped at the chance to use it.
-
Yes, that's cool Jeff! And it makes total sense.
So, at the end of the function, I did set
VL Sym to Nothing and
VL to Nothing.
Even with that, you would say it is still a very bad idea?
I just simply grabbed a string variable set in the getfiled maco and used it in VBA; it seemed harmeless; it was a lousy string of text, no objects involved.
I do realize that we do have to seperate what is cool from what is realistic.
Do these same sort of problems occur from referencing other Type libraries such as Excel or WSH?
I have not encountered any problems, but then again, they are both VB Enabled; may be that is the difference?
I bascially copy and pasted a very long version of THe OpenFile Dialog and made it work
I suppose if I muffled through it, I could shorten it to just what I need?
Thanks Jeff!
Mark
-
Thanks Mark!
I do appreciate that
I have worked very hard to get good at VBA (as others have, I'm sure) and I feel like I am finally starting to get.
This forum and many members of it have been a real blessing to me.
I totally appreciate and respect everyone's knowledge.
I am a very big proponent of not what we are trying to explain but how we explain it.
If anyone has seen my posts; every single post I leave and reply to, I say
Thanks
Mark
That is because I do appreciate (despite whta other's may believe) the fact that people do stop their busy day to try to help me.
I say that we take the original psot question and Jeff's nice piece of code (for other users) to take advantage of; then delete this whole post.
Can we do that?
Thanks Mark!
-
I bascially copy and pasted a very long version of THe OpenFile Dialog and made it work
I suppose if I muffled through it, I could shorten it to just what I need?
You're welcome Mark.
Why worry about shortening it up? Just use the parts you need and forget the rest is there. If you save (export)the OpenFileDialog (I don't know what version you found of the many that are available out there) to a BAS or CLS file (again, depending on what you found) then you can import it to any future DVB and use it without having to fiddle with "does it do this or that". Just import it, use it and move on.
As for referencing other API's. IMHO, and I am far from an expert on this, you should only reference other API's when you MUST access those objects available in that API. If working with an Excel spreadsheet, use the Excel library. If needing to use the Windows Scripting Host, use it. But I notice you didn't even comment about my suggestion of using Excel's FileOpen method. Why? Probably because you realize that that would add overhead to the macro that is really not necessary. The same holds for the use of (getfiled) in VBA......you are accessing the VL.Application, which access the result of (getfiled) which accesses the Win32 API (this last is a guess....I have no inside knowledge of how Acad actually does this). With VBA you can access the Win32 API directly so why add the 2 intermediate layers to that. Sure it more code, for you, sure it's more difficult to understad (I still don't follow a lot of it), but it will run quicker, not be succeptable to Autodesk changes in their code, and you'll learn something that may benefit you for something bigger down the road.
Now, back to why you need the VBA selection set in Acad. :-) Maybe we can work around that, too, without resorting to lisp.
-
I say that we take the original psot question and Jeff's nice piece of code (for other users) to take advantage of; then delete this whole post.
I did some "house cleaning", how' that?
-
Hi Jeff
Thank you again!
That was a very good explanation.
This whole thing started as a result of the email notifications not working for a day or so, if you recall?
I did not see many of those posts until after I had already sifted through that cumbersome VLAX Module and took what I needed.
I did see your post about accessing Excel and you are right, I thought it was a great idea in theory and was ready to post and tell you so; then I saw that Glenn said it would be a scary thing to do. I also realized that what you said in your aforementioned comment; that it does not really make sense to connect to Excel, just to do that. Would it be harmful; I'm not so sure.
I've seen a VB Script, that you double click on it and it closes all programs in one shot.
It is a useful little utility, however, the person that developed it said, you must have Word installed.
At first, I was like WTF? I must admit, I have used it a few times and there has been no problem.
Actually, here is the other unique situation I am facing; that I never felt that I needed to explain.
My boss is a fantastic AutoLisp programmer, he has done some great things.
He is a pretty good VBA programmer; he picks up on it very quickly as he has been programming for years.
For the last 4 or so years, I have been in trenched in VBA; help screens, examples, forums etc.
I am not saying by any stretch that I am a better programmer then anyone but I happen to understand and know my way around the syntax and environment a bit more then he does, I'm sure.
OK, so of course he still does a lot in LISP because he is really fast at it and LISP is still alive and well; so if VBA is not explicitly needed, then LISP is fine. Well, there are things that he has done in LISP that frankly may not be worth out time to try to re create in VBA, so I simply said, OK, if we need to expand on it via VBA, then maybe we can do something. That is what started this whole VLAX ordeal LOL
OK, finally, to your question :)
I created an sset in VBA and did not delete it at the end because I (or the user) may want to use it for further things in ACAD, as they are not programmers. So, I thought that it would be nice to keep it available for this sort of thing.
May be I could use Filter in ACAD, I don't know?
I'm not sure how The Filter command in ACAD would grab the last created object.
If it could, then I could use that named sset in ACAD.
I was trying to reuse the (named) selection set in ACAD to do somethings yesterday and just got frustrated because I could not access it by name; which really amazes me.
May be there is a way; if so, please let me know.
Otherwise, your routine is excellent!
Thank you,
Mark
-
In general, it is considered bad practice to create selection sets that hang around.
The system is limited to a rather small (255?) number of them, so if you create selection sets without destroying them, you may lock up Autocad and force your user to shut it down and restart.
And even if you do not create enough selection sets to hit the limit, imagine if other programmers also created "just a few" selection sets and left them hanging around... Eventually, Autocad might grind to a halt, and it would be difficult to figure out why...
A better choice is to use an Extension Dictionary, or the Named Object Dictionary, or an external file, or something along those lines.
-
OK, we now know the reasoning behing the madness :-)
And this is precisely why I asked, it pretty much follows what I ran into. Sometimes it does make sense to bend/break the rules, SO LONG AS we don't get in the habit of doing so.
[speculation]
You must remember that SS's were around long before ActiveX. Then (and now, in the lisp/ename world) they were known as <Selectionset: d4ca>. IOW, they were sequentially named in HEX. When ActiveX came around, the programmers thought "Wouldn't it be cool to have SS's with names we can pronounce?" And so it was done. The problem is, there was no way to introduce that back to the old SS method/naming without breaking every routine/function/program written using the old method. So we must live with the 2 different & incompatable versions.
[/specultion]
So....... No, I know of no other way to get the ActiveX SS into a command-usable SS.
For future questions, it may be a good idea to put in the initial posting, what is the purpose and the reasoning behind the question. That way if it's a convoluted thing you are attempting to achieve, everyone will know that this may require a different train of thought. The initial post here was close, but a few more sentences describing it (as you just did) may have staved off some comments.
And yeah, what Sinc said whilst I was typing this......I hadn't even thought of that aspect yet.
-
Yes, that is good to know; thank you for the explanation.
Interestingly enough, ACAD allows you (the user) to create named filters, named layer filters etc.
So, I would imagine that there is limits on it all; therefore ACAD should allow us to access named ssets; that's why prior to me doing VBA, they were like a great mystery to me. Now, I can create them in VBA but I can't use them in CAD? It is still a bit bizarre Jeff, don't you think?
That is great that Sinc filled us in on that.
I realize that it is is good practice to delete ssets when we are done in VBA but this is a rare case where I would like to keep it alive.
Again, the weird thing is, no one knows it is alive because there is no name still in ACAD LOL
Hummm, also, is this limitation limited to a drawing? If so, I could not see a need for too many ssets in one drawing.
I understand what you are saying Jeff about giving more info upfront. On the same token; if I don't understand the posters intents, then I simply ask him/her for my info or I just leave it alone. I use to get told that my posts (questions) were too long and too convoluted, so I really do my best now to try to keep it short and concise. :)
I know it seems like I ask some far out things sometimes but "please" understand, it is out of necessity.
We did a project here; that ended up having like 120 or so controls in all of the forms.
Then my boss decided (for a very good reason) that we needed to rename them all.
So, in one of my posts, I asked if we can loop through all controls in a project and globally rename them.
While that may sound like a weird request, guess what, it works :)
I can use wild cards and all.
Once the control (obj) is renamed, then the sub name is renamed (dynamically) respectfully.
So, it was a definite good tool to have as we will likely run into that again.
So, back to Sinc's post;
I am not sure how to use
Extension Dictionary, or the Named Object Dictionary, or an external file to acheive this. :(
Thanks!
Mark
-
Jeff, is there any way that the code could be modified slightly so that the user only needs to type in the sset name after the routine is loaded?
Thanks
Mark
-
Another thought occurred to me...
That limit on selection sets is actually 128, but it's possible that the limitation is due to the way Autolisp is implemented, and the limitation only exists if you are using Lisp... Someone else may know the details of it. But it's possible that the selection-set limit may not affect you in VBA.
Here's the relative quote I found in the developer help, which seems to indicate it is only an Autolisp issue:
Selection sets consume AutoCAD temporary file slots, so AutoLISP is not permitted to have more than 128 open at one time. If this limit is reached, AutoCAD cannot create any more selection sets and returns nil to all ssget calls. To close an unnecessary selection set variable, set it to nil.
Can you get to the NOD in VBA? I've been using .NET lately, so I've gotten used to having the NOD there, but I never used it before I started doing .NET programming.
-
Hey Sinc,
That is interesting and it makes sense.
I think AutoLISP Selection Sets are created right in ACAD whereas it doesn't look like VBA tosses them off to the App. So, this could very well be true and perhaps why it was developed not to.
So, are you telling me that I can still access the Sset via Named Object Dictionary in VBA?
Thank you,
Mark
-
Just ran a quick test....I could only create 124 SS's in VBA before it errors out.
Jeff, is there any way that the code could be modified slightly so that the user only needs to type in the sset name after the routine is loaded?
Not off the top of my head.....how would you distinguish the SS name vs a command or alias?
-
The NOD is something else, and has nothing to do with selection sets.
It's basically just a dictionary that you can stuff things into. That includes other dictionaries. So, your app could create a dictionary in the NOD, then store application-specific stuff inside it. The NOD is stored in the drawing database, so this is one way of storing any sort of generic data inside an Autocad drawing in a way that you can get to it later, even if Autocad is shut down and restarted. And each drawing has its own NOD, so its drawing-specific.
I *think* you can get to the NOD in VBA. In .NET, the Database has a method for getting the NamedObjectDictionarID, then you can just retrieve it using a transaction. But to tell you the truth, I've gotten so far into .NET that I have a hard time remembering what things are like in VBA and Lisp. Since I switched, I've found very little reason to look back.
-
WOW!
Why would someone need to create so many Ssets? I guess I should never say never.
We could always clear and re use Ssets as well if necessary as opposed to just deleting them.
I have never used more then one per Sub, but that is me, I am sure the need to do more will come up in the future, but 128, WOW!
As fas as The VLISP routine, I am not a LISP Programmer unfortunately, however, I would like to have something like:
Totally Pseudo here:
(getvbss & "Please Enter Ssetname", (Ssetname))
-
Sinc,
I will need to look into that, thank you!
-
Jeff
Another one of my weird ideas but it can absolutely be done.
Using The FileSystemObject
Set FSO = CreateObject("Scripting.FileSystemObject")
We can use the WriteLine Method and simply place the name of the Selection Set into The LISP routine.
If you tell me where the name needs to go and on what line in The LISP routine, I can probably get The Sub to write the line in. That would be pretty cool and dynamic
Mark
-
That way, once we run the VLISP routine; the selection set name will already be in there; then accessible in CAD
Yeah, that would be cool
Mark
-
Jeff
I wrote this little sub in VBA that (I think) will work well with the GetVbSS.lsp routine
Right after the lisp routine is ran, we could run this sub; then the user only has to type in The Selection Set name into the inputbox.
This was what I was getting at with The LISP routine.
I just wanted to have the type the name; only I don't know enough LISP to even make that happen.
Mark
Sub GetVbSS()
Dim Ssetname As String
Ssetname = InputBox("Type Selection Set name")
ThisDrawing.SendCommand "(GetVbSS " & Chr(34) & (Ssetname) & Chr(34) & ")" & vbCr
End Sub
-
Jeff,
I scrapped the above idea; that wasn't very good, it threw me out of my command; however, I am still very interested in this topic, I have just been really busy lately
I did find that if I load the LISP routine prior to The VBA routine.
Then, you have a separate button or pull down (whatever) with something like (ss "Img") only in it, then I can retrieve the named Sset transparently; I thought that was great!
So, I was in the copy command; prompted to select objects, I clicked the button with (ss "Img") in it and sure enough, it worked. That is super!
Still, I do want to re visit this again
Mark
-
Still, I do want to re visit this again
Have fun with it, Mark. However, I can see no practical use for it in my daily work so don't expect much more participation by me.
The biggest drawback I see for this thought process is that the button is useless unless your macro has run. So unless you have it running on every drawing you open, and updating accordingly, you will never know if you are even going to have the SS available, much less it contain the object you think you want.
I'm not saying it won't work for you, I'm just saying I'm pretty sure I wouldn't have any use for it. And that's what usually gets me interested in working on something with someone....I must see SOME benefit for myself by helping out.
-
Sure, I completely understand; that is why I haven't been too gun ho with it either.
I may use it once or twice to be honest; however when we first started the topic, I did have a good, valid use for it; it just fell to the back burner for now.
Still, I am not sure that I fully agree (or understand) what you are saying.
I (or the user) would run the VBA Module which then would create the sset; in which case the sset would be in every drawing that the user uses that VBA routine on. So, the button would work just fine on each drawing.
Thanks Jeff!
Mark
-
Yes, please understand; this is a ONCE in a LONG while need :)
I guess some weeks, I just have too much time on my hands :)
Mark
-
On the flip side,
This macro gets ran on startup
Sub AcadStartup
RunMacro ("WsCurrent")
End Sub
Sub WsCurrent()
Dim Username As Variant
Dim WshNetwork As Variant
Dim Preferences As AcadPreferences
Dim ActProfile As String
Dim CurrMenuPath As String
Dim CurrMenuFile As String
Set WshNetwork = CreateObject("WScript.Network")
Set Preferences = ThisDrawing.Application.Preferences
Username = WshNetwork.Username
ActProfile = Preferences.Profiles.ActiveProfile
CurrMenuPath = "C:\Documents and Settings\" & Username & "\Application Data\Autodesk\Autodesk Land Desktop 2006\R16.2\enu\Support\"
CurrMenuFile = Preferences.Files.MenuFile
If ActProfile = "Land Desktop" Then
CurrMenuFile = CurrMenuPath & "land"
ThisDrawing.SetVariable "wscurrent", "Land Destop Complete"
Else
If ActProfile = "MapLandDevelopmentDesktop" Then
CurrMenuFile = CurrMenuPath & "acmap"
ThisDrawing.SetVariable "wscurrent", "Map Classic"
End If
End If
End Sub