Hi KalleAnka,
by default each ItemType shares a basic set of default GUI elements. With a custom Presentation Configuration you can add/replace/delete GUI elements.
My current sample doesn´t overwrite the default configuration. Every other ItemType will still use the standard stuff. The changes are unique for the Fake-Part-ItemType.
The main work is done in the Methods. We need two different types:
- Click Methods -> they do the job . By default the Methods link to their original ItemType. Normally that's good. But in our case that's exactly the wrong behavior. My Methods read the Part ID from the grid and use it for operations with the original Part. The Methods shall never sees the Fake-ItemType.
- Init Methods -> they take care for the appearance, e.g. shall the lock button be active or greyed out. I currently use the default reinit methods. This works fine in most cases. In my current version only the Save button still makes some trouble. But it shouldn´t be a big task to fix that.
As example:
The standard Lock button is CommandBarItem com.aras.innovator.cui_default.mwt_main_toolbar_lock.
It use the Init Method cui_reinit_mwt_lock and the Click method cui_default_mwt_onLockCommand.
The corresponding CommandBarSectionsItemreplace this lock button with my own. The look&feel stays the same, but the Click Method now references hard to Part.
I recommend to delete the browser cache to make the project run properly.
I plan to use the project in production in around 2-3 weeks, then I will fix the last few bugs. Maybe I can provide a sample of the full ItemType. There are many small config settings necessary to make it run flawless.
Of course, if there is another simpler solution, I would be highly interested in it! I think the whole stuff can also be solved on SQL level (Polyitems do something similar), but my SQL-skills are incompatible with the requirements of such a task.
Since Aras use a similar concept in the Inbasket, the solution cannot be that bad.
