[archive] Very Complex Screens

[Migrated content. Thread originally posted on 12 October 2005]

We are developing an application with a very complex screen. There are in excess of 60 controls, including lables, radio buttons, check boxes, push buttons and a grid control on the screen. This is an order entry screen for a large and complex industrial electric distribution application.

Is there anyone out there using a screen of this sort. The environment is Linux servers, Samba, and XP work stations. The AcuBench is on the work station and the execution is on the Linux server using the standard thin client alias etc.

We would like to exchange ideas, some experiences, and problem resolutions.

Thanks

Vins Nash

Hi Vins Nash,

We have an application with one input screen with nearly 90 controls. The app runs on win98 and XP work stations.

What did you have in mind?

[Migrated content. Thread originally posted on 12 October 2005]

We are developing an application with a very complex screen. There are in excess of 60 controls, including lables, radio buttons, check boxes, push buttons and a grid control on the screen. This is an order entry screen for a large and complex industrial electric distribution application.

Is there anyone out there using a screen of this sort. The environment is Linux servers, Samba, and XP work stations. The AcuBench is on the work station and the execution is on the Linux server using the standard thin client alias etc.

We would like to exchange ideas, some experiences, and problem resolutions.

Thanks

Vins Nash

We also have serious complex order input programs with lots of controls on the screen

Only issue we've come across is the initial load and dispay of the screen.
Apart from that its fine

Again, what did you have in mind?

Shaun

[Migrated content. Thread originally posted on 12 October 2005]

We are developing an application with a very complex screen. There are in excess of 60 controls, including lables, radio buttons, check boxes, push buttons and a grid control on the screen. This is an order entry screen for a large and complex industrial electric distribution application.

Is there anyone out there using a screen of this sort. The environment is Linux servers, Samba, and XP work stations. The AcuBench is on the work station and the execution is on the Linux server using the standard thin client alias etc.

We would like to exchange ideas, some experiences, and problem resolutions.

Thanks

Vins Nash

We also have multiple screens with MANY controls on them and some even extend beyond the one physical screen down (must scroll down to see screen).

If I can be of any help let me know.

Thanks

[Migrated content. Thread originally posted on 12 October 2005]

We are developing an application with a very complex screen. There are in excess of 60 controls, including lables, radio buttons, check boxes, push buttons and a grid control on the screen. This is an order entry screen for a large and complex industrial electric distribution application.

Is there anyone out there using a screen of this sort. The environment is Linux servers, Samba, and XP work stations. The AcuBench is on the work station and the execution is on the Linux server using the standard thin client alias etc.

We would like to exchange ideas, some experiences, and problem resolutions.

Thanks

Vins Nash

Hi there!

We have an application window that when completed will have approx 140 controls on it.

It currently has approx 80 controls defined, with a treeview on the LHS and a six page TAB control on the right. Apart from more usual controls, the Tab pages contain 10 grid controls, with another 4 grids planned for the un-finished tab pages.

There are also various pop-up dialogs that are triggered from this screen, but I try to keep them to a minimum and incorporate as much functionality on the screen itself (one of Alan Cooper's favourite user interface design concepts).

If the network is slow, then the thin client can chugg a bit while it loads the screen, but then it's just a case of switching the visible flags on and off to change pages or views.

We don't use AcuBench, so I cannot comment on designing a screen of this size using it. It would probably be a nightmare!

Do you have specific concerns about using a complex screen?

[Migrated content. Thread originally posted on 12 October 2005]

We are developing an application with a very complex screen. There are in excess of 60 controls, including lables, radio buttons, check boxes, push buttons and a grid control on the screen. This is an order entry screen for a large and complex industrial electric distribution application.

Is there anyone out there using a screen of this sort. The environment is Linux servers, Samba, and XP work stations. The AcuBench is on the work station and the execution is on the Linux server using the standard thin client alias etc.

We would like to exchange ideas, some experiences, and problem resolutions.

Thanks

Vins Nash

Good day, not sure what you are looking for or if you just have concerns... Like many noted already, our company does have some screens with large amounts of controls on it. I am sure one of the screens I worked on has over 200 controls on it. I would guess that there are 100 visible at all times. I uploaded a screen shot or I did try and it did not work.

Unlike some, we do develop our screens using AcuBench.

My first suggestion is to develop the screen on a system with a larger screen with a higher resolution set. This way you can see the entire screen as well as all of your property screen and controls tool box.

My second suggestion is to have a good idea of how you would like to layout the data and flow before you start tossing controls on. Moving large amounts of controls and keeping everything in the right tab order and aligned right can be a nightmare depending on the screen itself.

Another big I ran in to was being able to access a specific control since I would try to click on it and it may be under another frame or control. I started by sending stuff to the back, but this also change my tabs and I didn't want that. My suggestion is to select your control you want to modify by using hte drop list at the top of the property window. Note that due to some limitations of tabs, we did not use them so all of our controls are visible on the screen at one time. If you can use tabs, then this is a much nicer approach.

I have noticed no issues with the screen loading or in use here at our development site or at our customers. As noted below, when running thin client the first load takes a second, but nothing to long.

If I had a wish list item it would be that the screen designer implemented layers or grouping like many graphics/3d programs use so you could turn off and on the layer or group for easier manipulation of the visible elements without impacting the ones turn off. If this is in V8 then we just need to upgrade from 7.

If you have anything specific, please feel free to ask.

[Migrated content. Thread originally posted on 12 October 2005]

We are developing an application with a very complex screen. There are in excess of 60 controls, including lables, radio buttons, check boxes, push buttons and a grid control on the screen. This is an order entry screen for a large and complex industrial electric distribution application.

Is there anyone out there using a screen of this sort. The environment is Linux servers, Samba, and XP work stations. The AcuBench is on the work station and the execution is on the Linux server using the standard thin client alias etc.

We would like to exchange ideas, some experiences, and problem resolutions.

Thanks

Vins Nash

I also work on an application where one of the screens has 90 controls on it.

There has been no real performance issue when using the screen itself. There is a small hit when starting it, but nothing really noticeable.

It is a thin client app that we provide for our customers who may be using it on dial-up accounts. Testing showed no real issues unless, when searching for things, a large number of records were being returned to the thin client. Otherwise, it appears to work pretty well.

The only issue that I have is, when working on this program, which contains a ton of other screens, AcuBench tends to start bogging down after an hour or so.

@DuncanK
What are you using to lay your screens out?

[Migrated content. Thread originally posted on 12 October 2005]

We are developing an application with a very complex screen. There are in excess of 60 controls, including lables, radio buttons, check boxes, push buttons and a grid control on the screen. This is an order entry screen for a large and complex industrial electric distribution application.

Is there anyone out there using a screen of this sort. The environment is Linux servers, Samba, and XP work stations. The AcuBench is on the work station and the execution is on the Linux server using the standard thin client alias etc.

We would like to exchange ideas, some experiences, and problem resolutions.

Thanks

Vins Nash

@Buggabil
I layout the screens by hand using manual coding in the SCREEN SECTION. After a while I find that I develop a mental image of the screen layout so I know what effects adding another control would do.

I also make extensive use of 78 level constants based on other constants to give me relative placing of controls.

For instance, if I have a screen with a tree-view on the left and fields on the right, I'll use a constant to define the width of the tree and base the positions of the right-hand fields on this constant. That way, when I change the width of the tree by changing the constant, the fields on the right move appropriately.