Skip to content

Conversation

@sebHollersbacher
Copy link
Contributor

No description provided.

@github-actions
Copy link

github-actions bot commented Jan 5, 2026

Test Results

  110 files  ±0    110 suites  ±0   1m 11s ⏱️ -1s
6 107 tests  - 1  6 107 ✅  - 1  0 💤 ±0  0 ❌ ±0 
6 108 runs   - 1  6 108 ✅  - 1  0 💤 ±0  0 ❌ ±0 

Results for commit 5772311. ± Comparison against base commit c01798d.

This pull request removes 30 and adds 11 tests. Note that renamed tests count towards both.

 
  *
  Multi-line comment
 Multi-line comment
 comment *)->
 comment */->
(*
*)
*/
…
org.eclipse.fordiac.ide.test.model.util.StringTransformTest ‑ transformStringName(String, String) 10: (*
 Multi-line comment
*)
s := "Hello   World!";
->s:="Hello   World!";
org.eclipse.fordiac.ide.test.model.util.StringTransformTest ‑ transformStringName(String, String) 11: /*
 Multi-line comment
*/
s := "Hello   World!";
->s:="Hello   World!";
org.eclipse.fordiac.ide.test.model.util.StringTransformTest ‑ transformStringName(String, String) 15: whitespace at the end 
->whitespace at the end
org.eclipse.fordiac.ide.test.model.util.StringTransformTest ‑ transformStringName(String, String) 22: test unclosed multine comment
(*
  Multi-line comment
  *
->test unclosed multine comment
org.eclipse.fordiac.ide.test.model.util.StringTransformTest ‑ transformStringName(String, String) 23: test unclosed multine comment
(*
  Multi-line comment

->test unclosed multine comment
org.eclipse.fordiac.ide.test.model.util.StringTransformTest ‑ transformStringName(String, String) 24: test unclosed multine comment
/*
  Multi-line comment
  *
->test unclosed multine comment
org.eclipse.fordiac.ide.test.model.util.StringTransformTest ‑ transformStringName(String, String) 25: test unclosed multine comment
/*
  Multi-line comment

->test unclosed multine comment
org.eclipse.fordiac.ide.test.model.util.StringTransformTest ‑ transformStringName(String, String) 5: (* This is a multi-line 
 
 comment *)->
org.eclipse.fordiac.ide.test.model.util.StringTransformTest ‑ transformStringName(String, String) 6: /* This is a multi-line 
 
 comment */->
org.eclipse.fordiac.ide.test.model.util.StringTransformTest ‑ transformStringName(String, String) 8: // This is a single-line  
test->test
…

♻️ This comment has been updated with latest results.

@mx990 mx990 self-requested a review January 7, 2026 10:01
final DataTypeTreeSelectionDialog dialog = new DataTypeTreeSelectionDialog(
PlatformUI.getWorkbench().getActiveWorkbenchWindow().getShell(),
FBTypeSelectionTreeContentProvider.INSTANCE, FBTreeNodeLabelProvider.INSTANCE);
FBSelectionTreeContentProvider.INSTANCE, FBTreeNodeLabelProvider.INSTANCE);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will also allow to select SubApps and Function FBs for internal FBs. I believe we have to restrict the selection as follows:

  • allow only FB types for Base FB types,
  • allow only FB and FC types for Composite FB types,
  • allow all FB, FC, and SubApp types for SubApp types and systems.

I would suggest to use TypeEntry.getTypeEClass() to determine the class of the type for each marker and show an error when an incompatible type is selected.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for pointing that out.
However, I'm not sure how to get the marker class using TypeEntry.getTypeEClass.
I would have gotten the markers TypeEntry over the Resource and TypeLibrary

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I would have gotten it that way, as well.

@sebHollersbacher sebHollersbacher requested a review from mx990 January 8, 2026 13:54

private boolean isCompatible(final LibraryElement newElement, final IMarker[] markers) {
return Arrays.stream(markers).map(IMarker::getResource).filter(IFile.class::isInstance).map(IFile.class::cast)
.map(file -> getTypeLibrary().getTypeEntry(file).getType())
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add a null check/filter for the result of getTypeEntry(file) in case the file has been deleted in the meantime. Please also use TypeEntry.getTypeEClass() instead of getType() to avoid potentially loading the type unnecessaily. I would also suggest to cache the list of EClasses in prepare to avoid re-retrieving them on each selection change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants