Password protection of 16 objects = a problem

[Barry Kelly]

The new password protection for objects created in version 16 is a nice option and provides much more security than the old "hide scripts".

So I welcome that, but it does cause one slight problem that the old "hide scripts" didn't have.

Now when you password protect an object you can't open the object without that password.
"That's the whole idea!" I hear you say.
But now we can't even open the parameter list to set default pens, fills line types etc., if they don't work in our customised templates.

At least with the "hide scripts" option we could see the parameters and would be able to change them to suit our custom setup and then re-save the object.

So now we have 2 choices.
Contact the person that created the object and ask them to save a version with custom settings - I'm sure they would love to do that for everyone.
Or use the object as is and change the settings everytime you place it.

Even selecting the object and saving that selection as a new object so that you have a new unprotected object that "Calls" the protected one doesn't work.

Anyone have any ideas for a solution?
I might have to make a wish for this one.
Barry.

[Erwin Edel]

Use favorites?

[Barry Kelly]

Erwin wrote:
Use favorites?

That is an option but my favourites list is already over populated.
If only we could have a folder structure in the favourites rather than one long list for each tool.
Plus then I will be for-ever saving a new favourite list every time I import an object.
Then have to load that into each job.
Not such a big deal but just updating a library part once is much easier.

Barry.

[Anonymous]

The locking/hide scripts has always been an interesting topic, because you can still open them via text editor...

[Barry Kelly]

sdb wrote:
The locking/hide scripts has always been an interesting topic, because you can still open them via text editor...

Which is why this new password protection is so much better.
But we still need access to amend all the default pen colours, fills, line types, etc., to suit our particular templates.
It is crazy having them set and locked to a standard that most users probably don't use.

Barry.

[Hoa Tu]

How about the object is unprotected but calling a protected macro object.
Hoa

[Laszlo Nagy]

As far as I know password protection means that you will not be able to open the GDL object for editing.
It should not affect the ability of other GDL Objects to call the password protected GDL Object.

[Barry Kelly]

Yes you can call password protected objects but you still have the problem that you don't know the parameters that have been used.

The only trick I know of to see them is to drag the password protected object into the 3D scrip of a new object.
It will automatically create the "CALL" command and list the parameters with their values fixed to those that were set when you drag it in.

This might help to reset pen colours, fills and linetypes - even default sizes.
But you won't be able to see a value list of any parameters - you will need to re-create these manually.
Of course the scripts all remain invisible (which as I said before is a good thing).

The big problem is I don't want to have to create a second "CALL" object just to get some control for the defaults of a password protected file.
If I can by-pass the password protection in this way to see the parameters then why can't we have access to the list from within the password protected file.
All I want to do is be able to set my own defaults that suit my template.

Barry.

[rocorona]

I think this makes sense absolutely. So, for me, this is a request to Graphisoft for a change in the way protected elements are handled.
Let the final user access at least to parameters.
My suggestion:
- Show the Detail page, with dimmed fiends (unchangeable)
- Show the Parameters page, with locked "New" and "Delete" buttons, but editable names (description) and values. So one can even translate for his own use, for example, some i.e. chinese text...
- Hide all the scripts

[Laszlo Nagy]

I will forward these requests and suggestions to the developers.