Hi, I recently started using DF (I switched from another framework due to bugs). It took me just hours to do most of the change over, and my issues went away Thanks for the great work.
I’m sure my question has a simple answer. I have some closable windows (SingleCDockable). I wish to remove the underlying model object when the window closes. No problem, I added a vetoable close listener and did the job in closed(). However, I find the window actually still exists in DF so the user can’t add it again (the window represents a view of part of my domain model and so should be displayable/hideable; i.e. closable). Shouldn’t the CDockable be removed entirely after closed()? I tried to call remove() of CControl but I get an exception:
Exception in thread "AWT-EventQueue-0" java.lang.IllegalArgumentException: not a valid character of a segment: ' '
at bibliothek.util.Path.<init>(Unknown Source)
at bibliothek.gui.dock.common.intern.CPlaceholderStrategy$1.removed(Unknown Source)
at bibliothek.gui.dock.common.CControl.remove(Unknown Source)
...
Could you please clear up my misunderstanding? Thanks.
PS: I have a workaround which is to not delete the underlying model, and simply make the appropriate dockable visible again when required, but I’d still like to know the answer. Thanks.
Dockables remain registered at the CControl until you remove them. The framework stores meta data about a Dockable as long as it is registered at a CControl. This way you can reopen a Dockable and it will be shown at its former position. If you remove a Dockable its meta data is deleted. You can however register a SingleCDockableFactory for it (or install a new MissingCDockableStrategy) and then the meta data will remain available as well.
Now the exception should of course not happen. There are two questions to answer:
Which version are you using? The stack trace is a bit suspicous and indicates an old version. Newer version should not throw this exception.
What is the unique identifier you are using for your Dockable? At least the current version should handle spaces and other special signs without problem. In older version you will have to make sure that the identifier is a string that could also be the name of a field or variable in Java.
Thanks for the reply. I have a Maven project and I’m using 1.0.8, which is the latest version (apart from ‘preview’ version 1.1.0)? Or should I use 1.1.0 manually in my project? I can try it and report back. As I mentioned, I did try and remove the dockable with code similar to below code:
boolean removed = false;
MyView itemToRemove = null;
int dockableCount = event.getDockableCount();
for (int i = 0; i < dockableCount; i++)
{
for (MyView view : allMyViews)
{
CDockable dockable = event.getDockable(i);
if (view.getDockable().equals(dockable))
{
**// Remove the dockable that the user has closed.**
// not sure why this cast is necessary, as SingleCDockable
// is derived from CDockable, which this method takes.
**control.remove((SingleCDockable) dockable);**
itemToRemove = view;
break;
}
}
**// remove the underlying model element**
removed = allMyViews.remove(itemToRemove);
if (removed == false)
{
throw new IllegalStateException(
"MyView could not be removed from list of views");
}
}
And yes, I have spaces and punctuation in my unique ID.
If I were you, I would include 1.1.0. I think the additional bugfixes and features will compensate for the additional work easily.
P.S. You might need to execute the code to remove your Dockable with SwingUtilities.invokeLater. (I’m not sure if it really is necessary. But if you suddenly see strange effects, try it).
My initial attempt with 1.1.0 shows the same results as above. I’ll try with a different dockable unique ID and also try with SwingUtilities. Thanks.
Edit: update–have tried with a simple unique ID (“abc”) and still get the same exception. Also tried with SwingUtilities.invokeLater() and same results.
Could you please send me a small application that reproduces the bug? Because I really was not able to reproduce it. I thought this is a 3 line application, but I seem to miss something. You are sure the application had 1.1.0 in the classpath?
[Edit: This is my attempt to trigger the issue, but it runs without exception. If you run this code in your application does it throw the exception?
import bibliothek.gui.dock.common.CControl;
import bibliothek.gui.dock.common.DefaultSingleCDockable;
public class Dock41 {
public static void main( String[] args ){
CControl control = new CControl();
DefaultSingleCDockable dockable = new DefaultSingleCDockable( "dfs \\ ö . , fdas" );
control.addDockable( dockable );
control.remove( dockable );
}
}```
]
Hi. I did have some library issues in NetBeans. Now that I am definitely using 1.1.0 the issue seems to have gone. Your sample code also worked without exception. Thanks for the quick support. ::manklatsch
Thanks for the great work.