Enterprise Client Community

Hi,
might have looked at the standard first, before complaining.

We have recently switched to log4j logging, using your ILogOutput interface mechanism. Then it is of course our duty to ensure that all relevant information is output.

Manfred

When an error occurs, the user is informed basically with some text and a java stacktrace.

We would like to change this. The text should be more user friendly. We would like to add some links which

(1) allow an attempt to reconnect to the session (this should be possible)

(2) something like save the error message + stacktrace + possibly other client state, plus the most recent part of the client log, to a temporary location, and prepare an email to send this information to our help desk (or if mail client cannot be started directly, offer a detailed description on what files to attach). It seems important that the log be made accessible via such a procedure since the java console (webstart/applet) is not readily accessible for normal users.

I know that the layout of the error page can be changed (some start parameter "clienterrorscreen", defining a different xml layout), and we can probably implement (1), but this is definitely not sufficient, since the algorithm provides only very basic "real" information (error message + stack) to include into this screen, so any beautiful layout we might implement is not too helpful.

Maybe you (or others) find such thing also useful, so we might put this onto the big captain casa wish list (and find it under the Christmas tree, due in a dozen weeks);

or at least (--> this finally is a small dev request; ...especially since our detailed requirements are not yet fixed; so that we might even not find under the tree exactly what we wish...) please allow a better possibility to customize the behavior, not just provide different layout xml, but instead allow to provide the name of a handler class which is to implement some interface (with e.g. public String getLayoutForError(Throwable t, String contextMessage), where we can take over the task and return the xml to display, and make it as complicated or user friendly as we see fit).

For server side errors we can probably live with the current handling, defining the error page with client parameter "errorscreen", although passing this through our interface would not harm either so that we might pass client information (e.g. log, other state) into the roundtrip to the error page.

Manfred

p.s. as for the client log, maybe you know of some logger implementation where the the data is not just output to console/file, but the latest part (up to some configurable size) is also available in memory, to include in the above processing. If not, this is probably not too difficult to implement...

is it possible to add something like session id, or thread name, to each line of the log output, so that each roundtrip can be analyzed correctly.

a minor problem: some lines of the output (..."request to be processed" et. al.) contain a number [...345] which is probably the milliseconds since the last such output, useful to determine the processing time of each request. However this is rather useless with more workload when requests overlap; additionally the calculation of this seems to be rather vulnerable to parallel access.

regards
Manfred

sorry but I don't get what is your "real" problem.

what this thread contains is rather loose wordings about "calling" from one application to another, even "from" and "to" seem to be mixed.

You have to differentiate precisely between "starting" the other application and "contacting" the other application.

The scenario described in my first reply was "start captaincasa from smalltalk"; how to start another process should be familiar to your smalltalk developers.

Other scenario might be "start smalltalk from captaincasa"; don't know for sure if this is possible out of the box, but can surely be implemented as a new control; might be possible already now when smaltalk client registers a certain file type (e.g. *.smalltalk), and in captain casa you download such a file with immediate "open" (such a control is available in captaincasa), and then the OS will start your registerd smalltalk, you can use this file to contain appropriate parameters so that the smalltalk process will show the correct views (...same as downloading a word document and have winword started).

next scenario is contacting the other application when it is alreadly running: this is probably best done using socket communication. This should be available on the smalltalk part, it is available in captaincasa client; of course you will have to invent some protocol which both sides understand, and it might be difficult to bring the other application really into focus, since the operating system typically doesn't allow another application to grab the foreground, it will merely blink in the task bar.

cannot come up with code since I doubt we use the same smalltalk.

Manfred

If you are not talking about "embedding" captaincasa screens in your application, it is as simple as invoking an exe (javaw.exe with PageBrowser class), or a url (the applett or webstart url).

Hope this helps
Manfred

Is it correct that there is currently no way to change the look and feel of progress bar control?
Could you offer some more settings here, at minimum various colors/font, other things which designers might want.
Lately I have had two suggestions on my desktop which are appended to this request.

regards
Manfred

There is a client switch "animate=false" which is supposed to switch off all animations. It seems however that opening of (modeless?) popups ignores this switch.

regards
Manfred

The seemingly simple task of displaying and printing a pdf file is driving me nuts...

We have tested many different combinations, and none works perfectly.

(1) t:jbrowser - it is simple to open a screen containing a jbrowser element which is pointed to the url from where the pdf is loaded, displayed, and the user can print or save the file.

There are definitely some issues with using browser in activex control. Using more complex test scenarios, containing several browser instances in windows and popups, closing and reopening them, we could repeatedly produce protection violations with hard termination of the client.

But for this (much more simpler) case let's assume that these problems do not exist. So it looked good on our developer workstations. Now come someone who has installed Acrobat professional instead of Acrobat reader. Here nothing is displayed at first, until the user changes the size of the client window, e.g. by maximizing it, or dragging the edge with the mouse. So there must be a problem in the interaction from eclient to swt to activex causing the size of the component is not be updated correctly. Is there a chance to get this fixed?

(2) we also tried a second solution, which is much less complex than the activex scenario, and therefore initially the most preferable, namely using t:jshowurl. This is very simple to use, no extra jars required, just pass the url, and the operating system opens a browser, loading acrobat plugin and displays the file.

Here however, modern browsers seem to be sooo proud to be able to display pages in tabs (if the user needs this or not). So in case the user happens to have open some browser windows, this solution just picks one of these windows, adds a tab, and displays the pdf there. So far so good. However now when the user closes this, there is an annoying warning if only the current tab, or the whole window, is to be closed, and if the user closes only the tab, she finds herself in a totally unrelated webpage and has to locate our captaincasa application somewhere via alt-tab or taskbar. This makes this solution rather unacceptable.

(3) this brought us to yet another solution. We created a custom component similar to jshowurl, which instead of Desktop.getDesktop().browse() calls Desktop.getDesktop().open(). Here the argument must be a File (instead of URL), so this also requires that our code first downloads the pdf to some temp dir, and then this opens Acrobat. This seems to work all right, but leaves us with the task of creating and managing/deleting the temp files. When the user wants to save the pdf, in solution (1) or (2) pressing "save" opens a file dialog where to specify the target location. Here however, this would only save the pdf to its present location in temp dir (where it will be deleted sooner or later), so the user has to choose "save-as" in order to save the file to the desired destination.

(4) we also tried pdfrenderer which is delivered with captaincasa. This might be an attractive solution, especially since the whole thing can be integrated into our application as far as desired, even print without user interaction, but also requires some work to offer things like "save", "print", possibly search, copy-to-clipboard and other things which acrobat reader offers per default. While this works remarkably well for the famous "This is a pdf" file contained in the demo workplace, using an only slightly more complex pdf gives completely discouraging results, characters are not displayed due to font/embedding issues, so this clearly shows that pdfrenderer is far from production quality.

So this is where we are at this stage. We will probably start with solution (3), but are eagerly waiting for some tips in this forum.

regards
Manfred

We have a fixgrid with editable fields and set avoidroundtrips=true.
We want a fast typing user to be able to enter all cells in several rows without interruption. A roundtrip when changing the row will always risk losing some input, let alone interfere with focus.

It looks like the flag "avoidroundtrips" is not obeyed when a change has been made in the current row.

So we would like to have an option like avoidroundtrips="really".
regards
Manfred

b.t.w. there also seems to be a flaw in that client events come in unexpected sequence. Change the value of a field and (without tab) click into the field of a different row. This change of row does not trigger a server roundtrip since the "row-is-changed"-Event from the field comes after the fixgrid has processed the newly selected row. But then any next click in the list triggers the roundtrip even if no further input has been done, so the server roundtrip also comes somehow unpredictable.

we have lots of lists that are not editable. When clicking into such a list, the row should be selected (and this works fine), but not the individual cell when it is not an enabled control. The disabled cells currently get a dark background color when clicked, which looks inappropriate.

To make things more complicated for you, we would still like to use a column of type t:formattedfield, to utilize e.g. your date-to-string conversion, we even want to add a t:button column, which has to be clickable of course. So we would like that disabled field columns, or label cells, should not be displayed with the "selected" style, and have this feature switched on and off, because for real "editable" lists it is probably quite useful.

regards
Manfred

Hi,
we are still not exactly content with current status.
There is a rather large offset added to the bottom of the text, from the sourcecode I see that 15 pixel are added arbitrarily (WrappedTextPane.getPreferredSize()

.

Also the issue http://www.casabacdemo.com/forum/posts/list/597.page is still unsolved and is probably the cause for these additional pixels.

It looks like the pane has a default margin of 3 pixel; in your calculation of required height, this margin is not taken into account, so to correct for it the 15 pixels are probably added as best guess.

We would like you to make the calculation more precise taking the margin into account, especially the case when the margin is zero and therefore no offset is required. We would prefer to have a margin of 0 as default value (...there are lots of possibilities to introduce spacing if required, e.g. padding, rowdistance, etc.), but this is not so much an issue since we have subclassed the control anyway, so the margin can be set easily. (- but we do not want do duplicate the entire height calculation which is why we bring this up here, and we are sure others also will like this improvement -

.

regards
Manfred

So one thing is menu, other thing is combofield, where eclipse also works "normal".

And even if eclipse choses to reopen the menu on second click this need not be taken as definitive standard - microsoft products like explorer, outlook etc. behave differently.

close + reopen is against standard windows behavior.
Can directly experience this while I type this reply in forum editor, 2 cm above these words.

Typical usecase is non-power-user scanning through a view to find what to fill into the fields. Position mouse on the drop down button to open the list, find there is nothing of interest and (without having moved the mouse) click again to close the list.

Don't want to argue against your usecase, but then you should provide either a flag to switch between the two behaviors, or arrange your code such that this effect can easily be overwritten in a subclass (...and tell us the method name).

regards
Manfred

works like a charm.
Thanks for your help

Manfred

Installed new version, result is:
On the click in question, the popup now closes and reopens.
So this makes 50% achieved...

.

...speaking more seriously, hopefully I made it clear what we consider the desired behavior: the second click closes the list and that is it - all windows comboboxes (and also in browser) behave like this.

thanks for your quick reaction.
regards
Manfred.