Some free VBA-stuff

small collection of FREE stuff for SolidWorks:

www.markkulehtola.net/sw

 

Your swProp2 seems to be nice and neat. Will try that for sure.

Can I help with revisions and drawing properties?

Johnny Geling

 

If you read the page carefully, you will notice that it's made by Vinodh
Kumar M, not me. So you should contact him. Same goes with the other stuff
as well, it's just a collection of something that I have found useful.

 

sorry I just was to quick.

 

That swProp2 macro is VERY NEAT! Ive seen another VB macro like this
called "Parameter Input", but it didnt incorporate into the SW
interface as well as this program, plus it isnt as easy to modify.

Does anyone know a better Properties manager than this? We havent
been taking advantage of custom properties, but would like to soon.
So im looking for the best way to go about it.

In the PDF file, the author states he is working on a INI editor. Is
this out yet? There isnt a link to a website, just his email (at
indiatimes.com).

One last thing, im looking for a better way to show revisions in a
drawing. Im not using SW2004 yet, but I heard this is a new feature.
Is this correct?

 

I think editor is the next goal for him. And let's see how long the ui
stays in property manager that is not working with this stuff at all
(..yes it's integrated but _not_ good). But this is only my opinion.
Anyway, our friend is doing excellent work, it's easy to see that he is
actually working with SW as well. Many times even commercial CP-softwares
really don't do the work because they are made to look nice or they have
all kind of funny sql etc. stuff in them when the purpose of these
softwares is to be fast and reliable

 

What do you mean its "not good" that its intergrated? Please explain

 

Because PropertyManager is very narrow it makes ui designing very limited
which gets you slow result.

Example: in my own CP-software I can use listbox
to get all the configuration names visible at the same time. If you put (i
guess it's possible?) listbox to PM it takes really much space
vertically and the whole thing gets too high to use fast, like if you have
design something really difficult and have 100 features in FeatureManager

 

Guys! you were talking about me. (I did not check into Google Groups for a
few days...)

To clarify:

1) In retrospect, putting the CP editor in the Properties Manager turned
out to be a very bad thing and like Mr. Lehtola has mentioned, it's
too narrow and there are only limited things you can do with the kind
of features SW API provides... (for one, just try capitalising input text!)

2) Yes, the plan now is to move the UI out of SW and also to make a
INI file editor. (When I get the time, but basically I am getting bored
with doing the same thing over and over again...). The current UI may be
appropriate/ adequate for some applications, so I let it be.

3) A request (if someone has the time). Can someone debug swBatchPrint?
There seems to be some mistake in the stuff that actually prints out
SW drgs because of which the output turns out 1/4 size... (it was
working fine initially and suddenly things went wrong.)

To answer SW Monkey's question, the work on the editor has not even started
and I am not too sure about 2004 and revisions as I use 2003.

Now, I must thank Markku Lehtola for donating space at his website some of
my programs.

Regards,

Vinodh Kumar M

 

w.r.t. SW Custom Properties... there are two interesting problems worth
breaking our heads about:

- An efficient way of storing (in models) and displaying (in drgs)
revision history.

- Getting the *next* drawing number (remember there are infinite
drawing numbering schemes) (Note to Markku Lehtola: I am not too happy
about reading from a file, it's not a "universal" solution)

If someone comes up any good schemes for doing this, it will be nice to
incorporate it into swProp3 (when it comes out!)

Regards,

Vinodh Kumar M

 

revision history.
Why not XML ?
Why not in a separate (synchronized) file, which would enable external tools
to do nice things without requiring SW ?
This is part of the idea of our CadML project (www.cadml.com)

Why not a simple VBA function, which could even be evaluated by a
ScriptControl ?
Users could write their own very easily...

 

This XML-thing pops out every now and then, so I really would like to know
what are the advantages against txt?

 

2004 revision table is good enough for me, if we want to store all changes
into the model do we have any other possibility than use configurations?
It would be really nice to have all these possibilities built into free
software, but is it just too big "piece of cake" ;-)

You have to store it somewhere in any case. Xml/txt or something like
that are easy to read and handle. For me the most important things are
that the software (in this case) is fast and the UI is good...and I can
modify it myself easily. I don't want any real databases or anything more
complicated because if I really need them then I should buy PDM-software
instead. Or are we developing first free PDM-package for SW here?!

 

well, XML is text + structure information, and more and more programs can
now read XML, and even process it while a custom text format would require
specific translators.
I just added a quick macro that writes SW files as XML and some example
files on www.cadml.com
Anyone wanting to help is warmly welcome.

 

On revision history...

That's the problem. I would like the revision history information to be
embedded into the model file itself. What you have suggested will surely
work if it's a PDM like elaborate software where the user is "protected"
from the underlying complexity.

It should be easy to "place" the history into the drg like a BOM table...
(and just as easily updated. (Don't know if 2004 does this... already)

I gotta figure this one out... (can't make out what you are saying, I am *not*
a programmer)

Regards,

mvk

 

Oh!, so 2004 already does this... Is it like the BOM?

That is (was!) the plan...

Regards,

mvk

 

So the processing is one advantage against txt/whatever. I can understand
it now when we are talking more like PDM-software than just simple
CP-software.

 

The idea is the same, you can basicly modify table template like
Excel-BOM-template now. To show revision data in a drawing is not a
problem, but saving that to the part/assy is more comlicated, you can use
configurations or like most of the PDM-softwares I guess, save a new copy
of files when you create new revision (you need a big harddrive ;-))

Great! I've been trying to keep things simple because I thought that we
are just going to have a nice CP-software, but this is totally different..

 

I looked at the site and the examples. Do I understand it right that you
are proposing a general file format for CAD models? And what about the
drawings? The SVG format? I looked at the SVG format (using sodipodi on
linux) Look promising. Maybe better then pdf.

About the xml files for cad. For me there are 2 main parts to
distinguise 1. The geometical description; 2. The administrative
description. Therefor 2 different clients working on the file. An
adminstrative and a geometrical like Solidworks. They should be able to
access the file indepently and at the same time. Changes in fileformat
for the geometrical part should not influence the administrative part.
Then you could have even very complex design software and simple design
software and an administrative client all working on the same file and
even backwards compatible.

Well Phillipe what do you think?

Johnny

 

a format for the STRUCTURE of (feature-based, parametric) CAD models.
There are already too many formats for the 3D geometry itself, which may be
referenced in the XML format if needed.

SVG is great for drawing (maybe even sketch..) GEOMETRY (See
http://www.dynabits.com/services/vector/index.htm ). But SVG does not say
anything about the structure of the documents (which parts are referenced,
view characteristics properties, tables etc.). I'll do a CadML of a SW
drawing very soon as an example.

Right, but I make a distinction between the geometry description (sketches,
features, dimensions) and the resulting 3D (B-REP) representation (edges,
faces...) which takes a lot of space but can be rebuilt from the
description.
However, If you keep everything in a properietary file format, admin tools
will be CAD-specific (they all are...)
My idea with cadML is to export admin+geometry structure as XML, which can
either be stored in a separate file or in the cad file in a zone that can be
read by an external tool.

Yup. I'd like to be able, one day, to re-build a part completely from its
cadML description, allowing backward compatibility and interoperability
between CADs...