Forums Bug Reports bug in dialog list verticle sizing

I have 3 tables that sit side-by-side, that should visually connect across each row, but the middle one does not line up.

Image of this



You can see the middle table (control #5 from code) is shorter than the 2 check box lists. Tried the code with the style size on the 3 lists and got this.



Forgot to mention mIRC 7.52 and using 'option dbu'. Disabled that to use pixels and got the same but half size - $dbw and $dbh results are 2 and 2.

I have no idea what Size does, cannot locate any documentation on it, but it does make the tables line up as far as height is concerned, but makes the text to check boxes line up even worse. Notice 7 check boxes in the outer tables, but 9.5 text items in the middle table.

Changing the middle table by adding style check does make everything line up



but now I have a check box that I dont want.

At one time I combined list #5 and #6, but that causes the state of the check box to toggle everytime a channel name was selected: not an acceptable effect.

What this does show is that it is something to do with the font that is causing this. I'm using Times New Roman regular at 12 point. I have no idea what font is being used to generate the tick box, but that character's greater height is what is making things go adrift.

Given from the fact the DBU and pixels showing the same result it is not something to do with them.

Given the 2 different font sizes (I assume) then it must be down to the line height of the fonts in play because it is resulting in 65 DBU/Pixels not equaling 65 DBU/Pixels visually on the same monitor.

That rather points the finger at the list vertical sizing code within mIRC.

I have tried to change font to fixed sys and FS Excelsior 2.0, and selecting a different point size in Times New Roman, but it doesn't chanage anything in the dialog.

Could anyone confirm this and hopefully fix it. I can make the complete code available if it will help.

1. It helps if you post enough code that would reproduce what you're seeing, so we don't have to add the other table elements.

2. Did you try using the 'size' option when defining your list?

Fair enough. I had assumed that the relevant table coding was enough, but here is the rest of that part of the dialog. There is another 'half' that duplicates this dealing with invite only channels, dont know if you need that too, but it suffers from the same thing.


stick a } bracket char at the end of that, it exists, in my code, after that other 'half' of the dialog segment ..

and I notice that I used verticle instead of vertical .. still no coffee (yet) today.

Regarding the 'size' style, no I didn't. I only tried it in desperation given that this appeared to be size issue. Given that there does not appear to be any explation or documentation regarding this style, it seemed worth while trying it.

"did you try" meant "you should try". Adding the size option to the list of options (which don't need to be comma delimited) for all list controls makes them all line up across the bottom. I didn't need to see the other part you didn't show. A simple example demonstrating the 'bug' is enough to post. Sometimes while stripping away unrelated items from your example makes the bug go away, showing that the bug is actually interaction with something else, like your other post where 2 controls were fighting over the same pixels.

Ok, but I had already tried using the style size option. Image 2 in this thread shows the results. The lists boxes do line up, but not not the contents of those lists, nor the number of items displayed in them.

I'll have a look and see what posting you are referring to. I have 2 in there, and one of them reffers to this subject.

Sorry, but that is not a bug. The height of listbox items currently simply depends on whether the "check" property is present or not. As such, you are trying to achieve something that is not supported.

The "size" property, by the looks of it, forces the listbox to the exact given height instead of being truncated to whole items. As such, it is unrelated to your issue.

I would recommend turning this post into a feature suggestion, along the lines of "please add a property that gives list items the same height as though they had a checkbox". Even then, given that your whole design won't work without additional extensions (the synchronized-scrolling thing), you should probably start thinking about a new design, no matter how cool this looks. mIRC dialogs only provide basic functionality; for anything more advanced you'd have to use something like DCX.

Sorry sat but your too busy focusing on what I am trying to do and missing the point about the height parameters of the lists with check and the list without it.



Height = 65, but the 65 (dbu) in list 5 != 65 in list 6. Thats a biggie, To start off with. Whether there is a check box or not is irrelevant.

In the real world 65 == 65, always.

It should not take an extra 'code word' to make it so.

The second part of my issue is to do with the contents of those lists. Focus appears to have gone on that and missed the height parameter issue, but since I have mentioned it, why is there no param for the height of the spacing between items in that or any lists. As I tried to point out somewhere, you can do that with text and edit controls, and list 6 is (effectively) a list of text or edit boxes.

In a different dialog (same script) I achieved that with


The height of the check item here has been reduced to counter the 'ghost' highlighting of the check boxes, when selected (by using the Tab key when cycling through the property) on the check's text attribute which does not exist. Thanks to maroon for pointing that out. Height was originally 10.
it was the abilty to riase the height of the edit box (15) that achieved alignment.

He's not missing your point at all.

The source of your problem is that you're wanting the height of X apples to be the same as the height of Y oranges. The row-height spacing of a list control using the 'check' option is fatter than the listbox without checkboxes, because it's accommodating the presence of the checkbox.

The /help can often be so brief that the text makes sense only after you understand what the $identifier or /command does. Sometimes I've had to glean clues from versions.txt. However it does say that x y w h are the size of the control - which isn't necessarily the same as the size of the visual area of the control.

By default, the list control's window is a size that's rounded down to be the largest size that fits entire rows in the visual area. When using the 'size' option, that overrides the default and makes it create the window as large as possible for the 'h' you used to define the control.

So the list control is doing what you told it to do, even though you didn't realize you were telling it to do that - not what you want it to do. Depending on the 'h' value of the control, if 'size' changes the height of the window, you'll notice that it causes the window to contain a fraction of another row instead of showing only complete rows.

Depending on which 'h' you use to define your window, it's possible that some 'h' values could result in a checkbox window being taller while other 'h' values make the checkbox window shorter.

He tried to tell you that the dialog controls were very simple, and don't contain all features. For example, you can't override the centering of a button's text without padding $str($chr(160),N) to the right or left of your text label.

I'm not sure what you mean by being able to change the spacing of items in a text control. You can wrap the text, but it always has the same default spacing between wrapped rows.

The purpose of "option dbu" is so you can make something that looks the same for someone having an 800x600 monitor as for someone on a 1920x1080. It shows the same font, which seems to be sized according to someone's screen resolution, and it doesn't let you change that. It divides by $dbuw and $dbuh which supposedly can be different, but I've never found anyone who had differing values. I posted a request to even find out which font gets used, and got no answers.

https://forums.mirc.com/ubbthreads.php/topics/260772/Font_Name/Size_in_Dialog_text_

Ok, I take your points which just prove the fact that mSL is poorly documented. I had realised what the size style was doing, but not why or if it could be controlled in anyway - no documentation.

Regarding the apples and oranges comment, I'm trying to make one line of a font to stand up to the same line size of a symbol that should be part of the same font. Thats apples being the same size as apples.

Your font question also raises a similar problem to the one I raised but in the width field. I hadn't even considered that.

I have had a good look at the dialog I created and the font in use is the Times New Roman that I mentioned ealier (at 12 point).

Given what I detailed in this thread, and your query, it does rather raise the issue of dialogs in general. Dialogs are a visual interface, in fact a GUI element. They are visual, and if the visuals does not make sense, it is pointless.

On the matter of font width, the use of a proportional font as a default is not going to look anything like a default of a fixed font, and what point size is being used as the default. Are our very nice looking dialogs going to be big enough for someone else's system with large fonts, for someone who is partially sighted (as an exmple) ?

I think I will drop this, it's a waste of time. It's a visual implementation that doesn't make sense in a visual world.

It is apples vs oranges, because a control having checkboxes is different than a control without them. Otherwise, all the other list controls would be forced to space their display to the spacing of the checkboxes. After adding 'size' to your list controls, they're all the same height, but the controls without checkboxes display more lines and fit together closer because they don't need the padding for the checkbox being larger than the text.

The goal of 'option dbu' is so that your dialog looks the same for everyone, regardless what font/size they use on their systems. To achieve that, the dialog tries to pick default fonts that are on everyone's system, then displays a size depending on the $dbuw/$dbuh values, so it would appear the same for everyone. But I wish at the very least there were a fixed-width font option.

There are dll's like dcx or mdx, but I've never used them. They add features, like changing font/fontsize, colors, etc.