Hi,

This has always worked up to now. I have been able to work around it in most programs that use it but 1 program is giving me fits and i wanted to see if there was a better way to accomplish my objective.

I have a program (or many) that use a box to add data in rows similar to a grid layout. I use a header line for the box that has a background color with labels. The columns of these boxes vary depending on whats happening in the program at the time, so the program will setup this line with the background color (say yellow) and print gui labels inside the yellow background (also using yellow when populating). The problem is that after the first label prints the yellow background disappears and is now only showing under the labels themselves and not the whole way across. Hope that expalais it well enough. I just want a way of populating a line with a background with labels that i can specify at a column position while keeping the entire background yellow. It seems like when it prints now its similar to the old "field" view... pics can be provided if necessary.

Thanks

It might be best to send me the instructions to see this online on your system.

I'm guessing that the issue is that the text/label control is replacing (i.e. deleting) the underlying yellow box, perhaps because we loosened the requirement (in 1250.2 - see http://www.microsabio.net/dist/60rel/ash60notes.txt) that they must have the exact same srow,scol coordinates. (Now I believe they have to be within one or two columns of each other and substantially overlap.) If that's the issue, maybe the test can be refined to attempt to recognize a situation like this where the overlap is deliberate.

This is probably the cuase.

Instead of trying to fix my approach, how about you just let me know how to accomplish the overall objective of having a solid background with multiple lables inside starting at particular start / end cols. (while still keeping the entire background color the whole way across.

Thanks.

Here's one possibility (using MBF_STATIC+MBF_FRAME to create "frames" or "panels" which are designed for layering text controls on top of them):



The trick (or limitation) here is that because the frames have beveled edges, while ordinary text controls do not, you have to make them about 300 millirows taller than the text controls that overlay them, which effectively means that you'll have to double-space the rows. Here's the code:

Of course, if we use AUI_CONTROL for the label text (instead of tprint), we could then have millirow control over them as well, so we could have put the colored rows closer together and made the label text a bit shorter.

Without seeing an example of your layout, it's hard to know whether this is something you could easily adapt to or not. If not, I'd be willing to fix the issue, but I may need to be able to run it remotely in order to see exactly with is triggering it.

Or, here's a possibly simpler variation, where I eliminated the MBF_FRAME attribute (and the beveled edge along with it) on the second row:



The trick here to avoid the auto-replacement logic is to simply adjust the starting row coordinate by a single millirow (i.e. from row 5, i.e. 5000 millirows, to 4999 millirows):

(The auto-replacement logic requires that the new control have the same starting row as the older control to be replaced.)

Hey Capn, thanks "Plan B" did the trick. Altering the millirow on the labels did not clear the existing control (which was the background)

Unfortunately this issue has snuck up in a number of different programs. Mostly the cause is adjoining controls with labels. Because the nature of printing a gui label with say 3 characters causes almost as much non-displayed space as characters there is ofter trailing parts of the object that run into the next object... i.e. a button, icon or perhaps next label. Some of this might be becuase some of our older programs print labels using old -10,20 syntax but we almost never issue end column parameters even to the full syntax.

This actually leads to another issue/problem going forward... when using end column parameters often times dependednt on the resolution and/or size of font if a station some of the label or object could be chopped. This is a very frustating annoyance. Is there a better way to place labels or text on a screen w/o worrying about the display resolution?
(sometimes i think we are still stuck back in the wyse30 vs am62a days!!)

First let me reiterate that if the change in 1250.2 is causing significant headaches, I'm willing to figure out a workaround that would avoid making you change a bunch of code. But I probably will need to study the cases more closely to figure out a good way of separating out the cases where it makes sense for a new control to replace an overlapping old one, and when it doesn't.

The problem I was solving was mainly related to automatic text-to-GUI conversions of programs where the input coordinates and re-display coordinates were close but not identical.

One approach to the problem of positioning labels next to other controls (input fields, buttons, etc.) without overlapping or wasting too much space is to right justify them. That way, any excess space appears on the leading edge of the label rather than between the label and its next-door control.

I'm not sure there is a TAB(-10,20) syntax for that, but you can use the 3D Tab mechanism with the T] style, nearly as easily.

The larger question of how to deal with differing resolutions is, well, a larger question. The MBF_ALTPOS scheme was intended as one solution, in that the grid size is effectively based on the default character size, which is related to the resolution and font scale factor or "DPI". But I gather you aren't using that scheme, perhaps for other reasons? What it doesn't solve (and in fact no unified grid scheme can have any hope of solving is the problem of how to know how much space is actually required for a specific text string in a particular font. About all you can do is call a function (such as AUI_WINDOW) to measure the actual size in grid units, then use the results to reposition/resize the control. But that's probably too much work to be practical. Which is why most designers just dodge the problem by leaving a lot of white space around their controls and text. Or try to set a boundary by designing screens at a relatively low resolution or relatively high font scale factor and then specifying that as the minimum requirement.

Thanks for the reply, Jack.

1) Thanks for the offer to adjust ATE/Ashell... for now i have been making patches to programs as we find them. I think this is an easier approach than you tinkering with a patch and asking our customers to re-download it. It is just a difficult issue because of our "text to gui" software transition. Most labels and objects are designed to be tight on the screen. Moving forward with new programs we will heed recommendations of plenty of white space b/w objects. I think Left justifying labels is a cleaner look so they all align, as well as the INFLD controls. Even in this scenario you could wind up with too much trailing space left over by the label and could wipe out the INFLD control or vice versa. Perhaps there is merit to re-think the idea of deleting overlapping controls. If controls were "placed" next to each other intentionally, why would the OS decide on its own to remove one or the other? Unless they simply cannot exist this way... i am thinking of this even in a forward design strategy for new programs. It is very difficult to layout a screen with large labels and really know now much trailing space might overlay an adjoining control.

2) Perhaps ALTPOS would resolve some of these issues. Initially in our R&D and GUI renaissance this was not available and did not retrofit in a constructive way into our existing and working scheme. Perhaps in "ZOOM-2" we will do a full reboot and work from the ground up... which i am fully behind and have mentioned to ownsership.

The problem (or feature, depending on your point of view), does not occur for controls that are merely next to each other. It requires that they start on the same exact row, have starting positions within +/- 3 columns of each other, and actually overlap by at least 100 millicolumns. It's the 100 millicolumn overlap which is apparently tripping you up, because your labels are sometimes coming out longer when rendered in a proportional font than they would have been in the text font (where you presumably arranged them to be snug up against the following control).

I could easily enough turn this feature off (just as I turned it on in 1250.2, although now I would need a switch so you could specify which way you wanted to go). But that would require an update, which it sounds like might be more trouble than working around it in your code. Unfortunately, you're being punished for others' sloppy programming, since the 100 millicolumn overlap threshold was arrived at through trial-and-error in working on an auto-text-to-GUI conversion of some AlphaACCOUNTING-inspired code where it is not unusual for the edit and display of a fields to be offset slightly. Without the auto-removal feature, the corresponding controls created by the display and edit operations would just keep accumulating, with visually unpleasant results.

I probably should have required a special switch to activate the logic, but I figured (perhaps wrongly), than no one would ever want to have overlapping controls, since it would almost always produce a visual anomaly in the overlapping region, as one control or the other got the upper hand. (The exception would be with two static text controls whose overlapping regions were just blank.)

What I failed to take into account was that when you create labels using a method that doesn't specify the ending column (e.g. TPRINT or certain abbreviated TAB(-10,20) formats like you are using), it is possible that the resulting control is actually wider in GUI mode than it would have been in text mode. (The normal case is the reverse, but some upper case letters can be extremely wide in some proportional fonts.) So your problem is likely confined to cases where you have a short label containing upper case letters, snug up against an input field.

Since even without the auto-removal of the overlapping control, you would experience some clipping, the ultimate solution would require either re-aligning the labels (which you apparently don't like, although I'm not sure you've given fair consideration to how clean right justified labels can look, especially when combined with left justified edit boxes). Or, making the label text smaller so as to not exceed one grid unit per character. (You could experiment with different fonts or reducing the font scale factor by a few percent, or maybe just using lower case.) Or you could convert your simplified TAB(-10,20) statements into more complete ones which included the ending column (in which case you'd be back to clipping but at least wouldn't lose the overlapping control.)

Hey Capn,

Actually i have done both of the above.. is some cases i have added ending columns so that there is no overlap, in others i have adjusted millirows just a tad so the controls dont overlap exactly. Its interesting you think right justified labels look cleaner, thats what most of our apps have, but i have recently been moving them to the left side because i thought that was more aesthetically pleasing, and it seems most standard windows forms employ this look... Either way i think its Ok for now, but i wonder if moving forward there should be a way of turning this feature off... i suppose if its not created issue for Herman, i can live with it Hmm 4:00.. time for tapioca...

I didn't mean to suggest that right justified labels were necessarily cleaner, but I think they look as good. It probably just depends on the individual screen and personal tasted. (But for what it's worth, Herman uses them, so that may be one reason he never reported this.)

I'll think about a way to turn the feature on/off, or perhaps to adjust its sensitivity...

Actually I have an option for the user to use left or right justified labels

wow... i am impressed

Just one switch statement in a procedure. I don't do fancy programming like you!

Not to diminish our proper adulation of Herman's towering ... intellect? (or hair? - choose one), but to be fair Jorge deserves some of the credit for that miracle of programming flexibility by reducing the option to a single character in the SBXINP parameter list.

Absolutely. I just decide which character to pass to Jorge. As I say, I don't do fancy programming, but then Jorge... Thanks very much Jorge for sbxinp. It's great and I use it everywhere.

By the way I came in second for most hair at my recent 45th high school class reunion. Obviously I was not even in the running for most intellect.

Either way very impressive Herman.. that you would even consider to give your users that option... i couldnt imagine going that far! But i do seem to recall some of the crazy things that your users complained about!!

I think I've come up with a compromise solution here. Starting in 1254.0 A-Shell will revert back to the pre-1252.2 behavior regarding the auto-deletion of existing controls that conflict with a new control, unless the
GUI_SPC_IND option (i.e. OPTIONS=GUI_SPC_IND) is set. That option is generally only of interest in cases where you are using AUTOTPRINT, which is also typically the only case where you would want the expanded auto-replace feature that was introduced in 1252.2.

Sounds good to me moving forward Jack, thanks... as long as it doesnt mess other vendors up. I sense that you might have had more complaints about overlapping controls disappearing as time moved on...