Jump to content
  • 0

Real Classes within Plug Ins


mike m oz

Question

20 answers to this question

Recommended Posts

  • 0

Thanks Petri, but in VW11 you can't actually do that easily.

If it were so simple to change the popup lists then why don't NNA do it?

These sorts of issues are just annoying for experienced users - but for new and inexperienced users they are real problem because they just add to the confusion.

Part of the dilemma I think is that whilst programmers are comfortable dealing with text most users are graphic oriented and therefore 'text issues' like this make the program less user friendly and therefore appealing.

[ 02-02-2005, 08:08 AM: Message edited by: mike m oz ]

Link to comment
  • 0

quote:

Originally posted by Petri:

quote:

Originally posted by mike m oz:

Surely it can't be that difficult to have them with real names rather than these generic ones.


You are right - it is not difficult. Just edit the pop-up value lists of the PIOs in question.

yes not to difficult;-)

once you get past three or four dialogue boxes

Mike you might want to bug your retailer to come in and show you hows its done. i was going to try and post a guide, but realised it is not an easy thing to discribe, but if shown to you would only take 1/2 hour.

Much work could indeed be done to improve useablity of the system set up.

May i be so bold to suggest that "workspaces" would be the best place to tie all these parts of the program together.

instead of the crazy maze of "create plug-in" where it is to easy for a novice user to change something important, and to hard to archive result.

Link to comment
  • 0

quote:

Originally posted by iboymatt:

if shown to you would only take 1/2 hour.

Much work could indeed be done to improve useablity of the system set up.


Surely it does not take half an hour! Well, maybe if you include the time you need to think what classes you want to use, but that is another thing. Instructions are eg. in my message http://techboard.nemetschek.net/ubb/ultimatebb.php?ubb=get_topic;f=12;t=003384;p=1#000005

You can even type the list in a word processor and copy & paste it into the value list. After you know what the classes will be, it takes a minute or two.

Link to comment
  • 0

Petri

I have tried the method you so kindly provided and yes it does work.

I still maintain however that it shouldn't be this hard.

If you have used several of the PIO's with the style 1, style 2 ... classes you lose track of what they 'belong' to.

At a least the PIO should give you options that mean something like for example stair tread x, stair stringer x etc. Even better would be the option to create a new class from within the PIO dialog box or the Object Info pallette.

Link to comment
  • 0

quote:

Originally posted by mike m oz:

I still maintain however that it shouldn't be this hard.

Well, ideally not, but when I have gone through the alternative scenarios in my mind, I have generally found them even worse, at least with the current PIO concept & technical structure. Since I write PIOs myself, you can bet I have thought of the matter - I don't enjoy the process any more than you do, but I can't think of a better way.

One alternative would be to have text entry by typing. No thank you!

Creating new classes via PIO interface does not appeal to me either. If you make that too easy, you end up with too many too easily.

This stance rules, in my mind, out the seemingly appealing feature of FileMaker Pro: the author of the system may enable the end user to edit value lists on the fly. Well, as an occasional FileMaker developer, I have done this on a couple of occasions, with disastrous results. Won't do it again, not even to databases I use myself.

Call me a control freak, but the current approach has its benefits as it gives at least some control and consistency, which is important in a practice with more than one person.

The improvement that I would wholeheartedly support is a central depository of value lists (again, a FileMaker feature) so that in the PIO one would only need to define which list to use in what popup. Unfortunately I have the feeling that this would be a major change in the PIO architecture.

I probably should have mentioned this before as a tip: in my colour/material value lists, I always have a choice called 'Special.' This I use for the unexpected colour or texture that is desperately needed in a project.

Now, as comes to this famous stair and your - understandable - request for more options, well, I have two quite complex PIOs with so many parameters that the object info does not show them all at once even with 1600x1200 resolution. And boy, are they difficult to use! One can easily go over the top.

In my view, there are so many more fundamental flaws and shortcomings in the stair PIO that more options is not a priority to me. On the other hand, your wish would be quite easy to fulfil: half a dozen popups (and, hey, lists for you to change & maintain) and the odd additional line of code here and there.

Anyways, I'm glad I was able to help so, in exchange, I hereby nominate you as the value list editing advocate on this board. I have my hands full on the mailing list, where this question pops up (well, indeed...) at regular intervals.

Link to comment
  • 0

Classes for PIOs should be handled no differently from other classes or class-assignment methods. They should be selected from all available classes in the document via drop-down list the same way classes are assigned to any other object in the object info palette - and NEVER, NEVER, automatically created when using the PIO. Simplify, simplify.

Link to comment
  • 0

Indeed, it is important to be able control, and the system should be geared to help maintain an offices drawing standards as much as it can.

(although i want to stop people adding past the 20 classes we use)

personelly i think these sort of things should be combined into an improved workspace editor. not just for selection of which tools are in the workspace, but the default values of tools. That way we could have a number of workspaces for different stages and levels of work.

Link to comment
  • 0

but just to bring it back to the first point, why do are some of these lists Style 1, ....

and others say Style-glazing-1,....

which given the way the programme handles classes, adding this mid name helps alot in tracking classes, so why hasn't it been applied to all Style pop-ups.

so windows for example would have

Style-Frame-...

Style-Trim-...

style-Glazing-...

in the first instance this would be a great help.

Link to comment
  • 0

Petri, if you have 500 classes, I'm impressed - but managing them must be a real chore! If you group your classes using the "-" character in their names, the pop-down list could be relatively manageable, even with a great number of classes. Thus, we can have simplicity and control together! Or, alternatively, each PIO could be assigned a limited subset of classes, selected by the user.

It's not that I don't agree that "Style 1", etc., are silly names. It's that I believe the issue is deeper than just the naming. The program is telling us what to name the classes, and is also telling us that we will have these classes(and their default attributes), whether we want them or not, if we want to use a PIO. This makes it more difficult to tailor the use of VW to each user's standard and way of working. Yes, we can work around the default behavior, but the point is that we shouldn't have to - the interface should be designed for maximum efficiency and ease of use.

By the way, this issue also goes beyond window and door parts - it applies to other PIOs, and to some of our library symbols, which drag unwanted classes into the picture when they are used. What this is about, in my mind, is making the program more intuitive and more responsive to users' needs and workstyles, without creating a burdensome setup "bureaucracy."

Link to comment
  • 0

quote:

Originally posted by P Retondo:

Petri, if you have 500 classes, I'm impressed

No need to be: they usually come from imported AutoCAD drawings by others.

quote:

It's not that I don't agree that "Style 1", etc., are silly names. It's that I believe the issue is deeper than just the naming. The program is telling us what to name the classes,

No, not really. You can give the classes any name you like.

quote:

and is also telling us that we will have these classes(and their default attributes), whether we want them or not, if we want to use a PIO.

Not if you edit the lists. And the classes do not have default attributes.

quote:

This makes it more difficult to tailor the use of VW to each user's standard and way of working.

Agreed, a bit more difficult, but only a bit.

quote:

By the way, this issue also goes beyond window and door parts - it applies to other PIOs, and to some of our library symbols, which drag unwanted classes into the picture when they are used.

The only alternative would be to have no classes in library symbols.

[ 04-06-2004, 07:12 PM: Message edited by: Petri ]

Link to comment
  • 0

quote:

Originally posted by Petri:

The only alternative would be to have no classes in library symbols.

I think there are two much better alternatives:

1) to use only the "None" class when bringing in automated or imported objects; or,

2) presenting a dialog box giving the user options about how to set up a class structure for the object - a more powerful option.

Besides eliminating the annoyance of having to re-tailor names and attributes, either of these alternatives would prevent the time-consuming side-effect of PIO use that we currently suffer from - having to edit all of our saved sheets to properly display or hide the new classes.

Link to comment
  • 0

quote:

Originally posted by P Retondo:

i think there are two much better alternatives:

1) to use only the "None" class when bringing in automated or imported objects; or,

Which is 'no classes'

quote:

2) presenting a dialog box giving the user options about how to set up a class structure for the object - a more powerful option.

Theoretically a good idea, but before one knows how a symbol is constructed, not really a goer.

quote:

Besides eliminating the annoyance of having to re-tailor names and attributes, either of these alternatives would prevent the time-consuming side-effect of PIO use that we currently suffer from - having to edit all of our saved sheets to properly display or hide the new classes.

These (obvious) problems are caused by lack of communication & instructions - and therefore the poor user, not so much by technical reasons.

I'm sure most veteran users know that I am not an apologist for NNA - on the contrary.

Link to comment
  • 0

quote:

Originally posted by Petri:

quote:

Originally posted by P Retondo:

i think there are two much better alternatives:

1) to use only the "None" class when bringing in automated or imported objects; or,

Which is 'no classes'


To continue: I am not sure how well this would work. It would then be left to the user to reclassify everything in every symbol. Even 'bad' class names are better than no classes at all in complex symbols. I have quite enough experience in editing imported symbols (or AutoCAD files without layers) to have this opinion. A typical case has been furniture.
Link to comment
  • 0

The use of classes is supposed to make it possible to either hide/display or modify object attributes throughout the drawings. How many classes are really necessary to do what the ordinary user would want in this regard?

The window and door class structure is reasonable, for example. I don't see how it would be that difficult to present a setup interface to allow the user greater choice and control in assigning classes to the types of objects in a PIO. If you've worked out a class for a certain kind of glass in a previous project, for example, you could import that class and assign it to your window.

If anything is obvious, it is how useful this would be.

Link to comment
  • 0

Once again I want to make a plea for this change.

On even a simple model it is easy to run out of 'Style-x' options, notwithstanding the problem of trying to remember later which 'Style-x' was associated with which particular object.

I will give a simple example of how it could be made better using the Circular Stair PIO.

There are four options for assigning finishes using styles:- Step, Stringer, Rail and Column. Each has a popup list with the option of selecting from Style-1 to Style-15.

Why can't the options for each popup be as follows:

Step finish = Stair-step 1 to Stair-step 5

Stringer finish = Stair-stringer 1 to Stair-stringer 5

Rail finish = Stair-rail 1 to Stair-rail 5

Column finish = Stair-column 1 to Stair-column 5

If possble adding the option for the user to create the class themself (as can be done with Edit Wall Type in Architect) would also be handy, but I would be happy with the simpler option.

Please do something about it!

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...