SWT designer & ClearCase

[Hansz]

Normally, when starting to edit a file in WSAD, ClearCase checks it out and/or asks if it should be checked out ...

Making a Change to a file through the Designer doesn't trigger such behaviour ... or at least not by default. Am I missing something ? or is this just something I have to learn to live with ... ?

[Eric Clayberg]

Normally, when starting to edit a file in WSAD, ClearCase checks it out and/or asks if it should be checked out ...

Specifically, which editor are you using to edit the file in WSAD? The standard Java editor or something else? If you open a file with the Eclipse text editor and make a change, does ClearCase ask the same question? I am trying to determine whether ClearCase possibly includes some hardcoded support for the standard Java editor or whether you are using some special CLearCase-supplied editor.

Making a Change to a file through the Designer doesn't trigger such behaviour ... or at least not by default. Am I missing something ? or is this just something I have to learn to live with ... ?

Designer would not have any knowldge of ClearCase, so I don't know how that would even be accomplished.

[Hansz]

I assume it's the default java editor... it's the one that opens up when I select the 'source' tab... as when I do something in the Designer it would edit the same source file I guess... but when I try to save that file it complains about being 'read only' (which it is because Clear-case hasn't done a 'check out' yet). Putting in an extra space somewhere is enough in triggering it into asking if it should check it out and then I can save it.

It just feels to me that the same behaviour should appear if I change something through the Designer which effectively is just another way of changing the source file ... right ?

To be honest I don't know how close ClearCase and WSAD integrate ... but as far as I can see ClearCase is 'just' another plugin ...

[Eric Clayberg]

I assume it's the default java editor... it's the one that opens up when I select the 'source' tab... as when I do something in the Designer it would edit the same source file I guess... but when I try to save that file it complains about being 'read only' (which it is because Clear-case hasn't done a 'check out' yet). Putting in an extra space somewhere is enough in triggering it into asking if it should check it out and then I can save it.

I am still not clear on which editor is exhibiting the behavior your like. What are the exact sequence of events you see when using the standard Java editor and when using the Designer editor? What happens in WSAD, if you open and edit the file with the built-in WSAD test editor? Does ClearCase ask you to check out the file in that case?

It just feels to me that the same behaviour should appear if I change something through the Designer which effectively is just another way of changing the source file ... right ?

No. The ClearCase behavior you are seeing is likely due to some hack they have introduced to specifically intercept changes in the standard Java editor. They may have injected a text changed listener on the Java editor's text pane so that they can detect any typed in changes. They don't, however, detect any changes made to the editor's buffer, so they don't detect changes made by Designer.

To be honest I don't know how close ClearCase and WSAD integrate ... but as far as I can see ClearCase is 'just' another plugin ...

I haven't looked closely at the ClearCase plugin since WSAD v4.0. At the time, it didn't integrate very well, and, in fact, used several hacks to implement its behavior (including things like direct access to widget tree selections rather than getting selections via the Eclipse API).

In order to do anything here, I need to better understand exactly what ClearCase is responding to and in which editors it actually works (there are several different editors in WSAD). If it is, in fact, hacking in a text changed listener on the editor's text pane, we might be able to simulate a text changed event and thus trigger their check out request behavior.