[Logo] Enterprise Client Community
  [Search] Search   [Recent Topics] Recent Topics   [Members]  Member Listing   [Groups] Back to home page 
[Register] Register / 
[Login] Login 
Messages posted by: brandt  XML
Profile for brandt -> Messages posted by brandt [45] Go to Page: 1, 2, 3 Next 
Author Message
That is phantastic. Thanks a lot.
Hi Captain,

we updated from CC-Version 20210525 to CC-Version 20220808.

In our outest page we have a clientconfig component with doubleclickclearstextselection="false" .

The parameter doubleclickclearstextselection was introduced on 01. of March 2019. And i think we (the guys from XpertCenter company) were the reason for introduction of this parameter.

After changing to the new CC-Version 20220808 we have a different behaviour in the area of text selection for field and textarea components.

With old CC-Version 20210525 a double click on a single word in a textarea component (with a lot of text inside) selects only the single word. If you click three times the whole text in the textarea is selected. That's the way our users like it.

But with the new CC-Version 20220808 a double click on a single word already selects the whole text. Now it is very hard to select a single word. It seems that clientconfig attribute doubleclickclearstextselection="false" does not work anymore.

Can you please correct this? Thank you.

Hi Björn,

this is absolutely fantastic.

Next update is perfect.

Hi Captain

We would like to set the initial position of the area selector. The methods (setters) are available, but it seems they have no effect.


At the beginning the area selector covers the whole image. In our case we would like to select the right half of the image. For that we should be able to set the X1 with the value of the half of the image width.

We also remarked that the methods areaInfo.getPixelHeight() and areaInfo.getPixelWidth() are swapped.

Kind regards

Hi Captain,

which captain casa version is necessary to use this fantastic feature?

Hi Captain,

thank you so much.

Hi Captain,

we encountered a problem with the handling of file extensions.

We have an upload component with following allowed file extensions:

public String getFileExtensions() {
return "jpg;jpeg;tif;tiff;pdf;png";

Our user wants to upload a file with filename = "IMG_0623.jpg.pdf".

(I know: It is a strange filename).

But if the user selects this file for upload, the upload will not start. It seems that the captaincasa logic detects as file extension "jpg.pdf" (which is incorrect) and because "jpg.pdf" is not defined as uploadable file extension the upload does not start.

Can you reproduce this behaviour?

CaptainCasa-Version = 20200427

Hi Björn,

thanks for your answer.

So i changed my code and made a "type-cast" from TreeItem to FunctionNode.

Works perfectly.


Code snippet:

List<FIXGRIDTreeItem> listTreeItem = menuTree.getFtree().getRootNode().getChildNodes();

for (FIXGRIDTreeItem treeItem : listTreeItem) {

FunctionNode fNode = (FunctionNode) treeItem;

Hi Björn,

we want to have a dynamic menu tree in our application.

We want change the image and the text of an end node of the menu tree.

So i have an WorkplaceFunctionTree object and now i have to find the corresponding FunctionNode element, which i want to update (change image and text).

Unfortunately there is only the method "getItemByText()" to find/get a FunctionNode object within the menu tree.

WorkplaceFunctionTree menuTree = ...
FunctionNode fNode = menuTree.getFtree().getItemByText("_WHATEVER_");

So i have to find a FunctionNode by its text property.

What i would prefer, would be a method [ for instance getItemById ] to find a FunctionNode by its id.

What do you think about this ?

Regards Joe

Side remark:
FunctionNode fNode = ...
When i set image = null for an function node element, then there is an empty space in front of the text and the text is indented to the right.
I would have expected that the text would not have been indented.
Hi Captain,

we changed from CC-Version 20190820 to CC-Version 20191120_2.

With the new version we encountered a different behaviour of "focussequence".

We use the following sequence string in our code: P/1 , P/2 P/3, … P/10 , P/11 , …

We use this sequence string to jump from one photo to the next photo.

With the old CC-Version 20190820 we jumped from the first photo (P/1) to the second photo (P/2) by pressing the tab key. That was okay.

But with the newer CC-Version 20191120_2 we now jump from the first photo (P/1) to the tenth photo (P/10). That is not what we expected.

So we changed our sequence string to a string with leading zeros. P/0001 , P/0002 , P/0003 , …. Now everything is fine again.

Just one question at last:
Did you change the focussequence behaviour by intention?

Regards and get well soon

Hi Captain,

we used fileuploadbuttonasynchronous and defined "jpg" (in small letters) as allowed file extension.

Some users reported us now that they were not able to upload image files. After a short analysis we found out that their image files had the extension "JPG" (in big letters). As consequence the upload of this "JPG" file was not possible with fileuploadbuttonasynchronous.

Do you think you can make the check for the correct file extension case insensitive?

Thanks in advance.

Regards Joe

Hi Captain,

our power users find it quite disturbing that double click to select a single word is not working in Google Chrome anymore.

To select a single word by double click is an absolute standard functionality which works in almost all programs. So the user expects this double click behaviour in our CaptainCasa applications.

And before CC-Update 20190107 it worked in Google Chrome.

From our users perspective the double click behaviour has gotten worse.

We would be really happy if you keep an eye on this topic.

Thanks a lot.

Fantastic. Thanks.
Hi Captain,

in our application we use fileuploadbuttonasynchronous in combination with drag'n drop.

At least we told our users to upload files always with drag'n drop from the windows file explorer.

For fileuploadbuttonasynchronous we defined the property "fileextensions" with a list of the allowed file extensions.

But with drag'n drop from the windows file explorer users can drop any file with any arbitrary extension on this upload button. So it is possible to upload files with a "wrong" extension.

Is it possible to suppress the uploading of "wrong" file extensions?

Hi Captain

With CC-Update 20190107 you introduced a new behaviour for text selection via mouse-cursor.

We are now facing problems if the user wants to select a single word by mouse double click inside a LABEL/FIELD/TEXTAREA or TEXTPANE-Component.

With Google Chrome it is not possible to select a single word by mouse double click.

With Internet Explorer and Firefox mouse double click to select a single word is okay.

Could you please check?

Many greetings from Switzerland.

Profile for brandt -> Messages posted by brandt [45] Go to Page: 1, 2, 3 Next 
Go to:   
Powered by JForum 2.1.6 © JForum Team