PDA

View Full Version : Missing Toolbar menu


hgn98009
09-23-2003, 01:15 AM
Hi, a couple of our users have gotten a strange problem. They can't reach the toolbar menu. The choice is greyed out entirely. We have about twenty users where the choice is still there. All the users share the same configuration which is installed on a common server. SD version is 11.60.0.3 and OS is W2K. The users with the problem have the same type of machine. Others have different types.

This is the machine spec.

Type IBM Intellistation Z Pro 3D Xeon 2,8GHz 1GB 36,4GB CD-RW nVidia Quadro4 980XG

Driver provider: NVIDIA
Driver date: Not available
Driver version: 4.2.0.1
Digital signer: Not digitally signed

I found a recommendation at Nvidia, They say, use version 28.84. CoCreate says use version 40.72. None of these seem to be the same as 4.2.0.1 which I guess is a IBM version number.

Has anybody else seen these problems before?

Hans-Göran Gustavsson

clausb
09-23-2003, 03:35 AM
Don't think this is a graphics driver problem. Try resetting the registry using the ResetUISettings.bat script which is shipped along with OSDM.

Claus

hgn98009
09-26-2003, 05:47 AM
You are right, it isn't a graphics driver problem. I got users to switch machines and the problem follows the user. It seems something is different in the user profiles. Does that ring a bell anyone.

Hans-Göran

clausb
09-26-2003, 07:12 AM
Are you using roaming profiles for users? If so, then this would explain why the problem "follows" the user.

Claus

hgn98009
09-28-2003, 10:04 PM
Yes, we use roaming profiles. The question is what I should be looking for in the profile. I can't find any information under c:\documents and settings\username\Application data\CoCreate that seem to be able to create this error.

clausb
09-28-2003, 10:59 PM
I am not too familiar with those roaming profiles. My assumption is that they store the contents of a user's profile directory in a central location and copy it from there to each of the local PCs which the user logs on to. If this is what's happening, then I'd check those profile data.

If the user ran the "Export Customizations" command at least once, then the profiledir\username\Application Data\CoCreate\OSD_Modeling\sd_customize_11 directory will contain lots of funny small files with extensions *.tlb, *.pum, *.acc etc. Remove those files (or move them away into a different directory for the duration of the test). Then have the user login to the local PC and run the ResetUISettings.bat utility first, then OSDM.

If, however, roaming profiles copy more data than just the user profile directory, then this won't cover everything, obviously. But as I said, I don't really have a clue about those roaming profiles, sorry.

Claus

hgn98009
09-28-2003, 11:55 PM
Fortunately I am not involved in the administration of the domain controller and the user profiles. I know they work as you assume. But maybe somebody knows what CoCreate is doing with all those funny small files.

I mean, we have at least five users who got this error built in to their user profile without knowing that they did anything to get into this situation. What else is CoCreate doing to manipulate what the users can do in SD. How am I supposed to be able to administer the user profiles so that the default setup is consistent and error free.

I have asked a user to look for *.tlb, *.pum, *.acc etc files in profiledir\username\Application Data\CoCreate\OSD_Modeling\sd_customize_11 directory. If she finds any of them she will ask the PC administrators to remove them while she is logged out. Then she will be able to log in and run ResetUISettings.bat.

Hans-Göran

clausb
09-29-2003, 12:12 AM
The "funny small files" contain information about the UI setup (such as toolbar contents and positions etc.). They are created when a user explicitly exports his/her UI customization. By default, they are consistent and error-free. Why in this case there is a mismatch, I cannot exactly tell without knowing more about they tried to do and what happened before they arrived at this state.

If the toolbars somehow are messed up, use the procedure as I described it in my previous message. Oh, and you might also want to try the "Reset" options in under Tools/Customize/Toolbars.

Wait a minute... in your original posting you say that users cannot reach "the toolbar menu". What exactly do you mean by that? The menu labelled "Tools" in the English version? Any specific or all toolbars?

Claus

hgn98009
09-29-2003, 12:54 AM
Under "View" there is a submenu called "Toolbars" where I can alter what assortment of icons is shown under the textual menus. The affected users have the "Toolbars" choice greyed out, no submenu flying out when moving the pointer over it and also have no icons showing between the textual menus and vport1.

What I would like is information on what behaviour is influenced by what file and how to set everything up so that all users get the same default behaviour. I am quite sure that these five experienced unix-SD users who just got their first PC:s didn't all make the same mistake. We have a number of other users who have done the same transition to the PC platform using the exact same configuration without loosing the View -- Toolbars menu. This is what I mean by implying that these files create an inconsistent behaviour.

clausb
09-29-2003, 01:17 AM
My point is that by default those files do not even exist. They are only created when using the "Export Customization" command.

By default, OSDM keeps the toolbar and menu settings in the registry. The "Export Customization" command is there to export those data so that they can be copied to somebody else's machine.

I can only tell you that usually everything works just fine, and there is no need for specific setup or installation procedures.

I'd suggest to contact CoCreate support and work with them on the details to find out what exactly happened in your case.

Claus

hgn98009
10-02-2003, 10:47 PM
Now we have found some kind of cure for this problem. If the user import a registry file created from:

Hkey_Current_user, Software, CoCreate, OneSpace Designer, 11.60.3.0

on a machine where a user who has a working environment is logged in, he/she gets the missing menus back. I haven't found any documentation on how to administer this. I want all users to get the same default setup while they continue to have possibilities to create their own toolbar menus. They should also get the same setup whichever machine they log in to.

CoCreate support didn't seem to have a clue to what I was talking about and today they have a German national holiday.

Does anyone have any experience in administration of register hacks for SD?

Hans-Göran

clausb
10-03-2003, 12:12 AM
Registry operations are intentionally undocumented because a) the registry structure is internal and can change at any time and b) chances are quite good to shoot yourself into the foot by changing the registry. So it's not surprising you haven't found documentation on this!

We do ship, however, the ResetUISettings.bat utility which clears the registry and mostly resets it to factory values.

It should be possible to achieve what you want by having one user set up the toolbars as required, then export his customization and share the resulting customization files by copying them into everyone's profile directories. Note that you also have to distribute any other files which are modified in the process, such as "available command files". For more information, consult the Advanced Customization manual.

My understanding is that you tried something similar to what I described. Why it doesn't work for some of your users I cannot tell; this needs closer examination (by looking at the data in the registry and in the customization files, and by finding out in more detail exactly which steps the users took to customize OSDM).

The new release, OSDM 2004, makes administration tasks like this easier; we've moved away from keeping toolbar data in the registry, and instead keep them in customization files which can easily be shared without having to explicitly export a customization. This improvement is also beneficial because it does away with a certain amount of configuration data duplication; up to OSDM 2002+, toolbar data were kept both in the registry and in exported customization files (if the user chooses to create them), which bears a certain potential for getting out of sync.

Claus

hgn98009
10-03-2003, 03:47 AM
I found a reseller in Hungary who explained it so that I think even I understood.

http://www.mip.hu/technical/osdm_customization_files.htm

However I am glad that OSDM 2004 will be easier to administrate. We are not installing SD on the users computers. Instead we have a number of installed versions on a server. This setup has been succesful in unix for a number of years but it became a bit problematic when we installed the first PC's. We had to make a little registry hack to make SD understand where the license server was and so on. We use: regedit /s sd11.60.3.0.reg. This chapter in the registry was created when I installed SD on the first PC. It was quite easy to change the search path from c: to w: and the rest seemed like quite reasonable information. The info under Hkey_current _user seems to be mostly incomprehensible for a human so I guess the warning for tampering is really needed. But I really think that we would have been helped a lot faster if CoCreate had documented how the user really gets the environment set up. The cloak and dagger method of information makes, at least me, become a bit upset.


Hans-Göran Gustavsson

clausb
10-04-2003, 12:19 AM
Hans-Goeran,

now things are starting to make sense; so you were using roaming profiles AND tried to establish something like a network installation on your own. We do not support network installation at this time, and while I most certainly agree this is a high-wanted and often-needed feature, we just don't provide it out of the box. Therefore, I don't think we can be accused of "cloak-and-dagger" - we are not trying to hide a feature here, we just don't have it at this point in time, unfortunately.

Claus

MikeBoswell
10-06-2003, 10:03 AM
Ive had the problem of missing toolbars when doing a new install.

My problem was that I had set the SDCORPCUSTOMIZEDIR prior to the first launch of SD/Annotation.

1) When I did the variable first....no toolbars.
TO fix.... remove variable and relaunch sd and annot., replace variable.

2) When I do the initial launch and then add the variable, no problem.

MikeBoswell

Thom Ivancso
10-09-2003, 08:57 AM
In OSDM 11.6x there is a System Environment Variable that can be added to your workstations that will allow you to keep the SDCORPCUSTOMIZEDIR variable set, so that after doing a new install the Toolbar menus will appear as out of the box, along with your customizations.

Just added the following Environment Variable SDCORPISADDITIVE and set it's value equal to 1. This tells OSDM to load the standard toolbars and then the customizations.

Hope this helps
Cheers
Thom

MikeBoswell
10-09-2003, 08:59 AM
Thanks THOM!