[JBoss Tools Development] - List of XULRunner Issues Related to Visual Page Editor
by Yahor Radtsevich
Yahor Radtsevich [http://community.jboss.org/people/yradtsevich] modified the document:
"List of XULRunner Issues Related to Visual Page Editor"
To view the document, visit: http://community.jboss.org/docs/DOC-15275
--------------------------------------------------------------
h2. Known problems in XULRunner 1.9.2
h3. org.mozilla.interfaces.inIFlasher
inIFlasher does not work on MacOS. It is needed to show a border around selected elements in VPE.
*Workaround:* To show a border on MacOS the following style is used: "border: 2px solid COLOR_NAME !important". But the workaround has a drawback: if the selected elements has its own border, it is not visible.
h3. draggesture event
XULRunner does not fire 'draggesture' event on Linux.
*Workaround:* Special button for Drag&Drop actions is used. Instead of listening to the 'draggesture' events, VPE listens to the 'mousedown' event on this button.
h3. org.mozilla.interfaces.nsIDragService.invokeDragSession(...)
The method invokeDragSession works differently on Windows and Linux. On Windows it exits *after* the session is ended. On Linux it exits *immediately*. The following snippet illustrates this:
document.addEventListener("dragstart", new nsIDOMEventListener() {
nsISupports queryInterface(String uuid) {
return null;
}
void handleEvent(nsIDOMEvent event) {
nsIDragService dragService = (nsIDragService)
Mozilla.getInstance().getServiceManager()
.getServiceByContractID("@mozilla.org/widget/dragservice;1",
nsIDragService.NS_IDRAGSERVICE_IID);
System.out.println("BEFORE invokeDragSession");
dragService.invokeDragSession(node, transferables, null,
nsIDragService.DRAGDROP_ACTION_MOVE
| nsIDragService.DRAGDROP_ACTION_COPY
| nsIDragService.DRAGDROP_ACTION_LINK);
System.out.println("AFTER invokeDragSession");
}
}, false);
document.addEventListener("dragend", new nsIDOMEventListener() {
nsISupports queryInterface(String uuid) {
return null;
}
void handleEvent(nsIDOMEvent event) {
System.out.println("dragend");
}
}, false);
document.addEventListener("dragover", new nsIDOMEventListener() {
nsISupports queryInterface(String uuid) {
return null;
}
void handleEvent(nsIDOMEvent event) {
System.out.println("dragover");
}
}, false);
* Windows output:*
> BEFORE invokeDragSession
> dragover
> dragover
> ...
> dragover
> dragend
> AFTER invokeDragSession
* Linux output:*
> BEFORE invokeDragSession
> AFTER invokeDragSession
> dragover
> dragover
> ...
> dragover
> dragend
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-15275]
Create a new document in JBoss Tools Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 11 months
Re: [jboss-dev-forums] [jBPM Development] - JBPM-2414 and JBPM-2506
by HuiSheng Xu
HuiSheng Xu [http://community.jboss.org/people/rebody] replied to the discussion
"JBPM-2414 and JBPM-2506"
To view the discussion, visit: http://community.jboss.org/message/544446#544446
--------------------------------------------------------------
H Maciej,
I think the point is whether we should achieve the discriminator design pattern. In discriminator design pattern, the join node will end split executions when they arrived join node, it do not terminate them while the first of execution arrived join node.
Indeed, it will increase the complex level of implements. So I think we could terminate all other executions in jBPM 4.4. And think about other scenarios in the future.
By the way, I had met the wrong behaviour you mentained. There were two managers in a department. When a contact arrived, both of them need review it. But if one of them is off the office, the process should not wait, the process will continue to the next step when one of them review it. And if the other manager come back, he need review the contact again and let the process go to next step again.
In my opinion, this process is totally strange, so we neednot achieve it in jPDL. :)
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/544446#544446]
Start a new discussion in jBPM Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 11 months
Re: [jboss-dev-forums] [jBPM Development] - JBPM-2414 and JBPM-2506
by Maciej Swiderski
Maciej Swiderski [http://community.jboss.org/people/swiderski.maciej] replied to the discussion
"JBPM-2414 and JBPM-2506"
To view the discussion, visit: http://community.jboss.org/message/544429#544429
--------------------------------------------------------------
Hi HuiSheng,
Thanks for reference.
I am wondering what we could gain with this new attribute?! Since either way execution must be ended regardless of if it has timer or not. Because if we leave such execution (with timer on transition) then such execution will be fired as soon as timer goes off.
Consider following scenario:
- for creates four branches all of them goes to a task
- multiplicity on join is set to 2
- users complete first two tasks meaning join will move on with the execution - join signals based on the multiplicity - 2 execution must be joined to continue
- next users complete two remaining tasks (from the fork that are still active)
- since multiplicity is set to 2 join will execute again - which in my opinion is wrong behavior
My fix for this was ending all remaining forked execution only if multiplicity attribute was used so it does not break any other cases - as Ronald has pointed out in jira.
What do you think about it? Maybe I am missing something ... so please correct me if I am wrong.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/544429#544429]
Start a new discussion in jBPM Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 11 months
Re: [jboss-dev-forums] [jBPM Development] - JBPM-2414 and JBPM-2506
by Maciej Swiderski
Maciej Swiderski [http://community.jboss.org/people/swiderski.maciej] replied to the discussion
"JBPM-2414 and JBPM-2506"
To view the discussion, visit: http://community.jboss.org/message/544387#544387
--------------------------------------------------------------
Hi,
as suggested, I started to look into multiplicity attribute of join activity and found out that there is quite serious issue (if I got it right).
In general, please consider following scenario:
- there is a process with one fork that has three branches
- each of the branch points to another task activity
- join activity uses multiplicity attribute to continue flow as soon as two any branches will reach it
- after join there is a state activity
So what will happen is that after two tasks will be completed execution will move on to state activity but the last task will still be active. So in case where some one would like to signal the execution (assuming that execution is now in state node) there will be an exception (execution[ForkJoingMultiplicity.7] is not active: inactive-concurrent-root) because signalling will be task instead of state activity.
In my opinion (in case of using multiplicity attribute of join) all not finished child execution should be terminated at the time of signaling join activity to prevent problems with active executions.
Hope I described the issue good enough.
Please find attached test case that should fail when using trunk version of join activity together with multiplicity attribute.
I made a fix for it but just want to discuss that my understanding is correct.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/544387#544387]
Start a new discussion in jBPM Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 11 months