Chart remains on other panels

[SDeanD]

I added a Chart widget to show sales trending by Item. It works great the first pass. But, It stays on all panels(screens) after it is displayed. Until I exit program and start again. I am using IE11 browser. I am sure I am missing something. I have looked at all the properties and can not see what I am missing. Any thoughts?

We are running RPG OA only.

thanks, Dean

[Scott Klement]

Make sure the chart is actually "on" the tab panel. it sounds to me like the chart is simply on the screen in the same place as the panel, instead of being actually "in" the tab panel.

try dragging the chart a little bit. when its added, it should show a message that says "element added to panel" at the bottom. if you dont get this, its not in the panel, its just overlapping it on the screen.

if that does not work, let me know.

[SDeanD]

Scott.
Thanks. But, I do not get the message, "element added to panel". Have tried scaling smaller and moving between panels. I am using standard panels not tab panels. The screens were converted with the Enhanced style.

is there a parent Container property? I am having the same issue adding CSS buttons. they stay on all format/screens. they are listed on the element tab for the proper format. But, show on all formats after the first rendering.

Screens that convert work great. adding elements is causing issues.

Thanks for your time,
Dean

[SDeanD]

Scott,

Since my last post I have done some testing.

I Find that it does not matter whether it is Chrome 31 or IE 11. I have checked Keywords and other values. It appears to rendering old form data on the screen. Is there a method to insure that the Previous Form is cleared. most have a translated Start Line = 01 Clear= *all remove windows = True in the screen properties .

It seems once I add elements, Even if I later remove them. the rendering is messed up between screens/Formats. like they are overlayed.

Thanks, Dean

[SDeanD]

UPDATE Since Last POST.

It appears to be caused buy Auto-Arrange for some being True and some being False. When Auto-Arrange is True on the Converted Buttons in the Action Panel. It seems to mess with the rendering on the next screens once you add items to the screen when they are not auto-arrange.

I looked at the HTML data in the saved Source. It seems to be bracketed correctly. I compared the Original to the modified. it adds the new Item to the end of the items collection within the screen collection. from what I can tell.

PROVEN:
It seems any widget(button/Chart) added not auto-arrange is showing on all subsequent screens. I change all to False. they all show on all screens after. change all to true and they do not. Please provide some guidance? I did not notice this behavior prior to Installing V4.7.2.

I am going to re-install today. Just to see.

Thanks, Dean

[Alex]

Here is my assessment, although I could be incorrect, as I have not seen the exact setup of your screens.

It looks like this is a converted display file. From what you describe, it appears that in in the original green-screen program, the screens you mention were overlaid (is the overlay property set to “true” on some of these screens?), but it was still erasing the previous screens using “clear line” property instead.

Clear line (CLRL) is a green-screen concept, because it is based on line numbers (i.e. row numbers) to clear content. Profound UI determines if a widget belongs to that line by looking at its “cursor row” property. “Cursor row” and “cursor column” properties contain the original green-screen row and column numbers. All converted fields will have this. However, new widgets that you add do the screen do not, unless you manually specify the properties.

I can see how this can be problematic as you starting to enhance the screens. You could start adding “cursor row” and “cursor column” to any new elements that you place on the screen, but that’s ***. I think the ideal solution is to change things up so that your program and display file logic no longer rely on row and column numbers. This may be as simple as removing the “overlay” property from the screens that are being placed on top.

[SDeanD]

Alex,

It may very well be the issue. But, the buttons do not have the Cursor Row property.

Is still seems to revolve around the Auto-Arrange being set off. Somehow?

For a test, I re-converted the screens. then simply turned off auto-arrange (false) on the Action buttons. those buttons once rendered, never go away. till the program ends. I did not add anything. I changed nothing else. Turn back on. presto they work correctly.

I am adding search Icons and such to converted displays. I do not want them auto-arranged.



This particular screens set has a couple of screens that overlay. but, the problem exist even for the screens that do not. Once the new widget has rendered, it stays on all screens no matter what the clear or overlay properties are. I may be able to re-code that portion. But, we have many screens that do this. Old-School Programmers seemed to love to overlay screens. I have to admit, back in the day, I was a bit guilty of using overlay as well. pre-1990.

My system is available via Static-IP if someone once to take a peek. I can provide credentials via email.
deand@resoftware.net
Thanks again for your time,
Dean

[Alex]

Yes, this is a symptom of the same basic problem.

Buttons are a little different than other widgets that are produced by the conversion process because they represent function keys. And function keys are not associated with any row or column. However, converted buttons have the "auto arrange" property. This property has 2 purposes...

First, "auto arrange" is used to position the button. Here, the actual position of the button in the designer is largely ignored. At run time, the buttons are positioned one after another with predefined spacing in between. This way, if there is a conditioned button (i.e. conditioned function key), the user does not see any gap.

Second, "auto arrange" makes the buttons follow "green-screen-like" behavior when it comes to overlaid screens. On the green-screen, only the function keys of the last written screen are available for use. Buttons with "auto arrange" follow the same rule ... they will only appear if they were written as part of the last screen. In your example, something is causing Screen A and Screen B to be unnecessarily overlaid. When buttons have "auto arrange", this is not a problem. As soon as you remove "auto arrange", the buttons from Screen A will bleed through to Screen B.

A good solution might just be to NOT overlay the 2 screens. It appears that Clear Line is what causes them to overlay. In your display file, I removed the following properties from both Screen A and Screen B:
- clear line
- starting line
- overlay range

This seems to have solved the problem.

If you see similar problems, you may need to do the same to other screens.

[SDeanD]

WOW.

Thank You!

I was really struggling to get it right. Your explanation is invaluable.

I will work to remove overlay.

Thanks very much and Happy New Year.

fyi, we are prototyping (converting key programs) our system for a demo to a NEW prospect that wants GUI. I think this will work well once we can figure the this small stuff out. we wrote a nice .NET front-end that works with the GUI panels.

Thanks so Much,
Dean