Enterprise Client Community

thanks for the suggestion - But I like the "history" of the messages more in this case ;)

I could solve my issue with the code above - thanks for your help

thanks for the quick answer! Well this is not exactly the problem, because the access to HttpSessionAccess.getCurrentLocale() is inside the ResourceManager (and not accessible by me). The ResourceManager itself can be accessed from inside the long polling thread

But if that is simply not possible in that special case, I need to re-write the access to the ResourceBundle by a direct access to the ResourceManager.readProperty(String resourceName, String property, Locale locale, boolean withError) with the Locale I can get from the HttpSessionAccess.getCurrentLocale() outside of the long polling manager (should work, but not as reusable/clean as it should be):

Code:

 final Locale locale = HttpSessionAccess.getCurrentLocale();
 final IObserver observer = LongOperationWithObserverPopup.prepare(ResourceManager.getRuntimeInstance().readProperty("messages", "loading.title", locale));
  // this operation has nothing to do with UI, but can add messages
  // to the observer. Within the operation you should not
  // use UI operations because this is not the UI thread!
  Runnable longOperation = () -> {
    // get data
    observer.addMessage(ResourceManager.getRuntimeInstance().readProperty("messages", "loading.start", locale));
  };
  // this operation is called after the longOperation was finished:
  // here you are within a real request/response processing, i.e.
  // you have full access to all UI operations.
  Runnable finishOperation = () -> {
    // dummy
  };
  LongOperationWithObserverPopup.run(longOperation, finishOperation);

Hi there,

I have discovered a weird behaviour. If i use long polling (e.g. LongOperationWithObserverPopup) and use the ResourceManager.getRuntimeInstance().readProperty(...) to read some localized text, the access to HttpSessionAccess.getCurrentLocale() inside the ResourceManager leads to a null pointer exception.

Take this for example:

Code:

 final IObserver observer = LongOperationWithObserverPopup.prepare(ResourceManager.getRuntimeInstance().readProperty("messages", "loading.title"));
 // this operation has nothing to do with UI, but can add messages
 // to the observer. Within the operation you should not
 // use UI operations because this is not the UI thread!
 Runnable longOperation = () -> {
   // get data
   observer.addMessage(ResourceManager.getRuntimeInstance().readProperty("messages", "loading.start"));
 };
 // this operation is called after the longOperation was finished:
 // here you are within a real request/response processing, i.e.
 // you have full access to all UI operations.
 Runnable finishOperation = () -> {
   // dummy
 };
 LongOperationWithObserverPopup.run(longOperation, finishOperation);

I've debugged that until ResourceManager.readProperty(String resourceName, String property, boolean withError) where your code tries to get the current Locale via the HttpSessionAccess.getCurrentLocale() where the FacesContext.getCurrentInstance() returns a null value

I hope the description is clear enough to reproduce the issue ;)

br
Manuel

Thanks!

and there is no need for an interim version - I can wait for the next update

br
Manuel

update: I've just added many more columns and it looks like the scrollbar is only visible when there are ~30% of the columns visible.. It seems that the more columns I the behavior is getting even worse.

I did some math and in my example, the scrollbar is getting visible, when the viewport gets shrunk below 600px - and I have 24 columns (including the selector) á 25px -> so it looks like the calculation is based on the minimal width and not the "actual" width of the columns

hope that helps

Thanks for fixing the issue with the resizing..

but now it looks like the horizontal scroll bar is only getting visible if the last but one columns visible part is getting low (making the last column not visible any more)

screen 1 - enough space to show all
screen 2 - visible area shrunk just before the scrollbar gets visible. As you see a big part of the last but one and the last column are hidden

all columns hat a minimal size of 100 in this example (I did not set any minimal size)

Thanks
Manuel

one more tiny thing (I think it is not worth to open a new thread):

textabbreviation is bindable via the CC editor, but I do not find setters in the GRIDCOLNode and LABELNode for that (although it is do-able via colNode.addAttribute("textabbreviation", "AUFNR"); - but that is not as nice as a setter)

I partly agree with @4 but with a different view: header columns are texts which are usually translatable in a multi language setup - and especially if you are in a multi language setup this is no longer under the programmers control (just compare some german texts to english and especially russian ones)

I did do some more research:

- if I do not enter any width (neither on GRIDCOL nor on LABEL), it looks like the gridcol width is somehow fixated to 100? (screen 1)
- if I enter some very small (default) width for all GRIDCOLs, then I see the expected behavior (screen 2)
- if I resize just one column per drag and drop and scroll afterwards, all columns (except the resized one) is re-set to the minimum value (screen 3)
- looks like the GRIDCOL text does not count into the width calculation of the dynamicwidthsizing - I would expect it to be considered too (like SAPGUI does and some other Java JTable implementations). I know there is a text abbreviation, but the logic count count both widths ("normal" GRIDCOL text and abbreviated text) into account (and take the smaller one?) when doing the dynamic width sizing

what do you think?

Update:

I've added some more columns now and it looks like the columns do not shrink below the _default_ value (100?), even if the content is lower..

Is it wise to force a lower column width for those columns?

Hi,

is it possible that the dynamicwithsizing is not working from within a ROWDYNAMICCONTENTBinding?

I am not able to activate this feature for my dynamically built fixgrid; the following things are set:

- .setDynamicwidthsizing(true) for every GRIDCOLNode
- no width for any column (expect one to be expanded to 100% for testing) - all others to setWidth(null)
- no width in the labels within the GRIDCOLNode
- fixgrid width to 100%

at the moment it looks like all columns are fixed somehow to the default of 100(px?) width

am I doing anything wrong here?

Thanks,
Manuel

You are absolutely right - the BROWSER component fits better here

Sorry for the noise

best regards,
Manuel

Good morning,

thanks for the fast reply.

We're calling a service on the SAP Backend (webgui), where we do not have control over the parameter handling...
But if that fix is in the release build within the next 2 weeks everything is fine

Thanks,
Manuel

I've some sort of problem with the iframeinclude:

This component has an url bound via a property (but the same "problem" is also in your demo). Every time I open the page bean containing the iframe, the CC framework is adding a counter to the given url like "?2".

The big problem here is: if you use a iframe url which already contains get parameters, the "?2" is also appended which causes errors in the iframe.

like: https://ourserver.com/testpage?field1=1&field2=2?2

is this a bug or how can we avoid this behavior?

Thanks for the valuable input - this looks promising to me.

I'll try to adopt my code to the new component in the next days