Question only for standalone API users.

Do you have any issues resizing a JFrame in either dimension and having the
standalone IChart respect the new sizing? I need somebody to reassure me,
this is such a basic thing, I must be doing something wrong.

I'm having an issue where horizontal resizing is fine but vertical sizing in
the container is wacko.

Any tips or guidelines. I know that layout managers are all different in
their behavior, I was using both BoxLayout and BorderLayout in attempts
to find something that works.

(I even defined a ComponentListener, adding a ComponentAdapter to intercept
the componentResized event, and still couldn't manage to get the chart to
shrink vertically, after it had expanded vertically.)
It just sort of continued to expand vertically and would never shrink vertically...
(I know, makes no sense) I used IChartPanel.setSize, etc. and still had no good luck.
I could get the chart's drawing surface to clip its image to the new size, but the
entire chart didn't shrink vertically, so drawing was outside the clipping rectangle.)

Previously I put the chart in a scroller, so I didn't resize it. Now that I'm asking the chart to
fit in its resizable container, I'm having problems.

HyperScalper

Well, I did a lot of fiddling on this resizing issue for the standalone IChart.
Ultimately, I had to "fiddle" a delayed resize event to "tweak" the display, and use
setPreferredSize on the charting panel. So I have a workaround.

I'd like to ask API Support how do you synchronize windows refresh/resize activities against the asynchronous data events streaming into the charts.

When I do it, I use double buffering and make sure everything's on the Swing dispatch thread.

I've done a lot of such asynchronous "soft realtime" activities, and I know that unless it's done properly, there are a lot of problems.

In particular, are all of the charting update operations performed on the Swing event dispatch thread?

For my part, I am making sure that I never access the chart, except on the Swing event dispatch thread.

But if asynchronous charting events are streaming in with data, and that happens to collide during a repaint/refresh event, then there will be erratic behavior.

So exactly how does the standalone IChart design handle this issue? What's the thread-safety and the design model for accessing these charts? I'm seeing some repaint anomalies which would be consistent with an asynchronous conflict, but I wanted to ask to be sure.

Since I'm using raw Tick charts, the probability of an asynchronous data update thread conflict with a GUI update thread becomes very high, unless the design is right. If a chart's data structures are disrupted during a graphics refresh operation, then all bets are off.

HyperScalper

Please provide a full standalone example program which demonstrates the issues that you just have enlisted.

Thanks, I will work up a standalone example in a few days. Would you please outline the guidelines for accessing a standalone tick chart to ensure there are no concurrency conflicts.

For example: Should we always access charting functions from within the Swing event dispatch thread, or should we access some functions within IContext.executeTask(task).

Having these guidelines would be very helpful. We would know which operations are thread safe, and which need special care in dealing with standalone API charts.

HyperScalper