Bugzilla – Full Text Bug Listing
| Summary: | [design] Action's disappear when there are form based views in the same folder stack | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [RT] RAP | Reporter: | Hasan Ceylan <hceylan> | ||||
| Component: | Workbench | Assignee: | Project Inbox <rap-inbox> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | hceylan, holger.staudacher | ||||
| Version: | 1.2 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Hasan Ceylan
By error the comment below was added to the previous bug. Sorry... Hello Holger, I think it is rather then being a form based something else. The common behaviour for our form are the data is passed after the view is created therefore the actions are added to the bars lazily after the initial creation phase. I think this should be it! Regards, Hasan Hi Hasan, sorry but I can't reproduce the bug without code. Please provide a snippet to reproduce it. I know it's not possible to take code from your project, but maybe you can create a standalone example with the same behaviour? Regards Holger Hello Holger, I further debugged the code: The common things for the views with action problems: 1) All of them have secondary View IDs 2) All of them are: i) created with id + secondary id ii) a domain object is passed to them like much like IEditorInput. also the secondaryId is created based on the domain object to be passed in the step (i) iii) They create their actions based on the domain object So, if I temporarily remove the secondary id from the showView call and then if I switch to another view and switch back to view in question, then the actions are correctly presented... Would that information shed some light on the issue? Hasan Created attachment 143376 [details]
Modified Mail Demo to recreate the problem.
Modified Mail Demo to recreate the problem.
Hi Holger, Attached is example modified mail demo to recreate the problem. Try to open multiple mail messages and notice that action either invisible or in wrong places. Hasan Hi Hasan, thanks for submiting this modification. I will take a look at this bug in the next few days. Holger Hi Hasan, I can now reproduce this error and I will fix it soon. Thanks. Fixed and committed to CVS HEAD. Changes were made in org.eclipse.rap.design.example and org.eclipse.rap.ui.workbench. Hello Holger, I got eclipse 3.5 and installed RAP 1.2. Checked out design, workbench from the HEAD. also chjecked out rwt and rap.jface to satisfy changes in workbench. Then I had a workspace compiling fine, however I still have the problem with the attached test case, either action is missing, becomes visible as I switch between views or action is placed on top of the configuration action. Hasan Thats curious. Do you have added the checked out bundles to your launch configuration or do you use the bundles from the target? That was the first thing I checked too :) Hi Hasan, I can't verify this behavior. When I run the maildemo no action is shown above the configuration button. But I saw that the configuration behavior can not work with you attached maildemo. Take a look at org.eclipse.rap.maildemo.View in Line 85. There you give the new action a dynamic ID. To save the visibility of an action the view ID and the action ID is used. If the action ID is dynamic it becomes always invisible. So the action id has to be not dynamic. Can you change this in your application, delete all cookies from the localhost and test it again please. Thanks. Hello Holger, I think the solution assumes that the actions for a given view is always the same. But in our case the actions are added based on the data of the view instance. That might be what's causing the problem ...that's actually why I head the dynamic actionid's in the sample code... Hi Hasan, I talked with Rüdiger and we think that a viewaction with a dynamic id is very seldom. So we decided to close this bug and does not support dynamic action ids coupled with the new design, sorry. Maybe you can create a patch by yourself and submit it, I will than take a closer look. But in the meanwhile we will put no more effort in this issue. So, I think this bug is fixed. The issue with dynamic action ids seems to be a separate issue. I will now close the bug. |