Enterprise Client Community

Hi Björn

I have detected a bug in FIXGRIDExcelExporter.
Values of type BigInteger are not exported!

I sent you separately the code snippets from CC source where the bug resides.

Kind regards, Daniel

Hi Björn

Thank you for improving in version 20190301 focus management in case of removing components.

However, there is still a scenario where the focus is set to the browser scope.

I send you by separate email some screen shots and the recorded traffic to reproduce and analyze.

Kind regards, Daniel

Hi Björn

Sorry, normally I test a bug against a new CaptainCasa version, but this time I forgot.

The bug is present in version 20180827_2, but not anymore in version 20181210.

The issue is therefore solved for me, I will get the newest version.

Kind regards, Daniel

Hi Björn

Please verify the following bug in the demo workplace.

1. Open the "Date Input" page
2. Enter the date 31.12.2018 by typing in the field without popup
3. In the graphical calendar, step back with left arrow to september
4. Choose day number 30 (sunday)
--> The date set is 30.10.2018, instead of expected 30.09.2018

Can you please fix this bug?
(A similar bug was described in http://www.captaincasademo.com/forum/posts/list/0/2637.page#8757)

Kind regards, Daniel

Hi Björn

I am afraid that this issue has reappeared.
I have noticed it in version 20181210 of CaptainCasa.

Can you please verify and refix?

Kind regards, Daniel

Hi Björn

When popping up the calendar with time in the "Date Input" page of the demo workplace (RISC), the time is initialized with the current time instead of zero, although the attribute "exacttime" is set to true. See attachment.

For the java version of demo workplace, the behaviour is still initializing time with zero as desired and implemented long time ago (this thread started 2009, time flies quickly...).

Could you please fix the RISC version?

Kind regards, Daniel

Hi Björn

I have noticed that in web_template.xml, FileUploadServlet and ClientDirectUpdateHttpServlet are missing.
However, they are still in web.xml.

I suppose they are missing in web_template.xml by mistake?

Regards, Daniel

Hi Björn

I have checked with CC version 20181007.
The bug is still not fixed.

Unfortunately, I cannot provide a JSP snippet, since t:arrayfixgrid ist dynamic and onRowExecute() is on server side.

But I have attached screen shots hoping they are useful to reproduce and fix.

Regards, Daniel

Hi Björn,

On some clients, the mailto protocol handler is not present, so the t:mailto component is not effective.

Do you see some possibility to failover?

It seems there is a way to detect the failure with Javascript:
https://www.uncinc.nl/articles/dealing-mailto-links-if-no-mail-client-available

It would be nice if in such a case an event could be thrown to the server or at least a customized message could be popped up.

Regards, Daniel

Hi Björn

Could you reproduce the bug in the meantime?

Regards, Daniel

Hi Björn,

Sorry for having provided a too complicated example.

Lets say simpler:
If I set "peep" as tooltip, then
1) if the text (not the tooltip) doesn't wrap, then the tooltip is correct ("peep").
2) if the text wraps, then "peep" is not shown in the tooltip. Instead, the text shown in the schedule box is repeated in the tooltip.

Not effective means here that the tooltip I set ("peep") is not shown in case the text contained in the schedule box wraps.

Regards, Daniel

Hi Björn,

Yes, I guess you must look for wrapping part of your code.

In the attachement, there are two examples.
Use case: display a text with time range at last position.
In the tooltip, show the time range at first position.

1) Short text without wrapping --> tooltip setting works
1) Longer text with wrapping --> tooltip setting isn't effective

Regards, Daniel

Hi Björn

I have detected that in RISC, setting the tooltip for t:SCHEDULEITEMNode is not effective.

Could you please check and fix?

Kind regards, Daniel

Hi,

The issue is solved by workaround.
Thank you Björn for your support off forum.

Regards, Daniel

Hi Björn

Thank you very much for finally resolving the issue.
You said: ...will try our best...! ;-)
Well, your best is always good enough

Now I have realized that the same problem occurs with t:smartarea.
Could you please fix that?
I hope this is easy for you.

Kind regards, Daniel