New items at runtime

Hi Kasper,

The DefaultCommandLinks of a BarSplitButtonCommand is used to populate a BarSplitButtonLink when it is created at run-time. This means that whenever the end user uses the Customize window to create a BarSplitButtonLink, the link is automatically populated with the child links you have in DefaultCommandLinks.

It sounds like you have a BarSplitButtonCommand already defined. Each BarSplitButtonLink (the link in the UI) can have its own child command links, especially since this is customizable by the end user. One way you can do it is update the command's DefaultCommandLinks with your items and also iterated through the BarManager.DockableToolBars and recurse looking for a BarSplitButtonLink with the command full name of the one you're working on. However as you can imagine, that would take a decent amount of code to accomplish.

The better way is to use an expander. Make a BarExpanderCommand that will expand at run-time to your dynamic items. Then add a link to it to the BarSplitButtonCommand.DefaultCommandLinks in the designer. Then add a link to the BarExpanderCommand in all of the popups of each BarSplitButtonLink in the UI, still while in the designer. This way, you have an expander in each child link collection of all the split button links in the UI and are all set for when the end user creates new links at run-time.

Then populate the expander item when requested. We have a WindowList sample of that in our BarForm sample.

Expanders are the recommended way to go because they allow you to easily swap in dynamic commands and links.

Thank you for the detailed answer. The BarExpanderCommand seems to do exactly what I need :)

I do have another question. In the top of my application, I have 3 toolbars. I want 2 of them to be on the top row (row 1, since the menubar uses row 0), and then the third toolbar should be positioned on row 2. I want the toolbars to be positioned right next to eachother, without any of them has the RequireFullRow set to true. However, when I run the app, the 3rd toolbar moves to row 1, and the 2 others moves to row 2. Now, when I close my project and open it again, the layout is even more messed up, and the toolbars are now no longer even close to eachother. I can take a screenshot if needed, but I kinda hope that this is a common problem (since it has happened to me pretty much from the start), and you have some sort of fix for me :)

I'm using the latest UIStudio trial.

Hi Kasper,

I know there was an issue like that which should have been fixed in build 2.0.0061. You can see the Release Notes for a description.

If you are using build 62, can you email us a small project and give steps to use it to demonstrate the problem? Thanks!

Wow, this problem is really frustrating! I can't recreate it (typical), but it won't go away in my application either :/. I actually thought I had fixed it. I tried recreating 2 of the 3 toolbars, by deleting the old ones and creating them again. This appeared to have fixed the problem, but half an hour later, it was buggy again, and now they're acting like described before. I built the application using 61, but I have been using 62 for at least a week now, so I really don't know what's wrong. Do you have any idea how to fix this? I would hate to have to rebuild it all over again.

Haha, I can't believe this. I think I might have found the cause of this error, although I can hardly believe it :). Whenever I enter the word "Edit" in the Key property of one of the toolbars, weird things start to happen. I can reproduce this very easily. Try creating 3 toolbars and a mainmenu. Now position the mainmenu on row 0, 2 of the toolbars on row 1 and the 3rd toolbar on row 2. This will probably work. Now try setting the Key property of the second toolbar to Edit. Run it, and the toolbars should have been reorganized. At least they are here :)

Any news on this subject, Admin?

Was actually working on it as you wrote this. I am able to duplicate the problem. Trying to track down what is causing it right now...

Okay, that's great to hear! No rush, since this is not a problem (for me at least) that needs to be fixed ASAP :). Have a good bughunt!

Tracked it down... should be fixed for the next maintenance release. Thanks for the repro steps!

No problem, glad to help :). Will the other issue I mentioned on this forum (the 4 kb limit when saving layout) be fixed in this release as well, and when will it be released?

I believe the Flush call we added for the upcoming maintenance release will handle that but if you'd like to test a "preview" build of the maintenance release (which still might have a couple other tweaks before release), send us an email and I can give you a link to it.

Hi,

I decided to wait for the maintenance release, and I have just installed them. I have only tested for some minutes now, but so far, the issue with the moving toolbars seem to have been fixed :). Great!

Unfortunately, the save issue does not seem to have been fixed yet. The SaveBarLayoutToFile still only leaves me with the first 4 kb, while the SaveToolWindowLayoutToFile still works fine. I hope that this can be resolved, since it's pretty important to be able to save the user layout :)

Oh a little extra question: Should the "Copy Local" be true or false for ActiPro assemblies?

I changed things around in the run-time sample BarForm enough to generate a 5KB file just fine. And I've never seen the SaveBarLayoutToFile not write out the entire layout. At this point since I can't dupe it and we added a Flush to the writer back a build or two, I have to assume that there's something else, possibly on your end, that is interfering. I need for you to create a small sample project that shows the issue and send it to us so that we can debug it.

Just FYI, as a workaround you can also use the DifferentialBarLayoutData property which gives you an XmlDocument.

Copy local generally does work fine, however we found an issue with the VS.NET designer that can cause things to blow up in the designer if you do have it on. This is documented in the Known Issues in the documentation. This problem is NOT ours and is yet another Microsoft VS 2005 designer bug. Even other large third party component companies have run into the same thing. You used to be able to do it fine in VS 2002 however Microsoft rewrote a lot of the designer for VS 2005 snd introduced numerous bugs in the process. So the gist is, keep it false.

>I changed things around in the run-time sample BarForm enough to generate a 5KB file just fine.

Actually, I don't have to make any runtime changes, to get a file that stops suddenly at 4 kb in my small application.


>Just FYI, as a workaround you can also use the DifferentialBarLayoutData property which gives you an XmlDocument.

That seems to work, although the resulting file is smaller than 4 kb, so I don't know if it will cause problems if the user makes too many changes. Is this method just as good as using SaveBarLayoutToFile?

>So the gist is, keep it false.

Okay, and that goes for all the Actipro assemblies, including the ones for SyntaxEditor and Wizard?

Are you doing a complete layout save or a differential? From what you are saying, it sounds like you are doing a complete. The second parameter to SaveBarLayoutToFile controls that. For run-time and for most of our customers, you should only need to do differential. In BarForm, a differential layout saves as ~2KB, which is why I had to make run-time changes to increase the size. Even if I flip it to a complete layout, it saves to 33KB just fine.

Yes, DifferentialBarLayoutData gives you the same data as SaveBarLayoutToFile. It's just in an XmlDocument instead of to a file.

I haven't heard of issues with the other products. However they don't need to do as much in the designer as UIStudio. The type converters on commands and command links are what expose the problem in VS.NET.