Hoping a MUI expert here can help with this wierd MUI4 behaviour:
If I try to open a MUI window which contains a MUI_Text object, where MUIA_Text_Contents is a very long string (probably larger than can fit the screen's width), then all the program's existing MUI windows close & reopen themselves, with all their text now extremely small (almost unreadable), and the MUI window I was trying to open will NOT be open (although the program acts like it thinks it is open). I then have to close my program using Commodity Exchange, since I cannot interact with the new window.
Ideally what I'd want to happen is that the string is just truncated to whatever will fit on the screen.
If it helps, the code for the MUI element looks something like this: Quote:
I've seen the 'extremely small text' exhibited in MUI before, but its a little random, if your able to consistent reproduce this I would suggest registering and reporting it on muidev.de where it will get the attention it deserves - and not here.
I can confirm that I have encountered 'extremely small text'on my classic Amiga running MUI ver 3.8 registered.
Usually after a system failure before a re-set. (Very rare).
Unfortunately I usually have to change my Font Prefs in MUI again after the re-boot.
This seems to effect IBrowse mostly.
Regards, Michael
aka rockape
"A veteran is someone who, at one point in their life wrote a blank check made payable to 'Their Country' for an amount of 'up to and including their life'.
As rockape already pointed out this is neither a bug nor feature of MUI4, but this situation has been handled in MUI3.8 and before exactly the same way. If the calculated size of the GUI is too big to fit on the screen then MUI will try to reduce the required space by reducing certain sizes (spacing, font size, etc). Of course this approach has its limitations and if the GUI is still too big after the final try the window(s) will stay closed. But the application is running nevertheless and there is no reason to quit it automatically. Having an application with no opened windows is no illegal state for MUI.
Setting MUIA_Text_SetVMax to FALSE will only affect the calculation of the required height which is of no use in this case. For a too long text line you should set MUIA_Text_SetMin to FALSE to avoid enforcing the minimum required object width to the full text width. This will allow the text object to cut off the text while still allowing the window to be fully resizable horizontally. Additionally MUIA_Text_Shorten can be set to MUIV_Text_Shorten_Cutoff. MUIV_Text_Shorten_Hide will hide the object if the text is too wide, but I doubt this is desired in your case.
"A veteran is someone who, at one point in their life wrote a blank check made payable to 'Their Country' for an amount of 'up to and including their life'.
@tboeckel Thanks for the advice... But unfortunately "MUIA_Text_SetMin, FALSE" causes another problem that I've previously experienced: Windows can default to a size so small that NO text is visible. That's why I didn't use this solution :(
I have run into this kind of issue before, and I've previously suggested that MUI should choose a default window size half-way between it's minimum & maximum, but I also recall that you didn't agree with that suggestion for reasons I didn't understand :-/ .
If there is really no better solution, then I might have to start manually reading & changing MUI window sizes, which seems totally against the philosophy of MUI (and might effectively prevent MUI windows from save the window size chosen by the user, since it'd be overridden each time the window is created).
"MUIV_Text_Shorten" doesn't seem to exist in my MUI3.8 autodocs, so I assume it's something new to MUI4. I'll have to see if I can find documentation for MUI4... Is it likely to solve the above problem(s)?
I have run into this kind of issue before, and I've previously suggested that MUI should choose a default window size half-way between it's minimum & maximum, but I also recall that you didn't agree with that suggestion for reasons I didn't understand :-/ .
MUI chooses the default window size on basis of the default dimensions of all contained objects. Additionally each object has a minimum and a maximum dimension which define the limits between which the object can be resized as MUI requires it.
Quote:
If there is really no better solution, then I might have to start manually reading & changing MUI window sizes, which seems totally against the philosophy of MUI (and might effectively prevent MUI windows from save the window size chosen by the user, since it'd be overridden each time the window is created).
You couldn't be more wrong. First of all you don't have to tweak the window size, because it would be enough to create a subclass of Text.mui which sets your preferred minimum dimensions. MUI can only provide the basics, but these don't fit your needs then it is up to you to do anything that is missing.
Text.mui has calculated minimum and maximum dimensions for ages now, but no explicit default dimension. That's why setting MUIA_Text_SetMin to FALSE might let a text label default to this minimum width of zero if there is no other object which enforces a larger minimum width.
Quote:
"MUIV_Text_Shorten" doesn't seem to exist in my MUI3.8 autodocs, so I assume it's something new to MUI4. I'll have to see if I can find documentation for MUI4... Is it likely to solve the above problem(s)?
MUIA_Text_Shorten exists since MUI 3.9. You can find the full updated documentation if each and every release archive as well as the nightly build archives on http://muidev.de
I will add the default width calculation to MUI 3.9 and MUI4, but this won't help you for MUI 3.8. For that ancient version you will either have to accept how things have been working for more than 20 years by now or you implement the necessary subclass of Text.mui to do the default/minimum width calculation during MUIM_AskMinMax which fits your personal taste.
@tboeckel I've finally fixed this issue, now that I know how to create MUI custom classes (and have mostly automated the process so I don't need to remember all that BOOPSI boiler-plate code).
What I don't understand is why the following behaviour is not the default for MUIC_Text (or at least be an option), since it's what I'd intuitively expect:
The only thing I needed to do was to sub-class MUIC_Text so that it's MinMax method contained the following lines: Quote:
(That's AmigaE code, but the C equivalent should be fairly obvious.)
I did also add a New method to force MUIA_Text_SetMin to TRUE, since that's required by my code. But it's not strictly needed, since that's the default value.
The magic number "6" is what the Text class would otherwise have for minwidth, if MUIA_Text_SetMin was FALSE. Unfortunately I don't know how to calculate/deduce this, so it's hard-coded (if it causes problems then it would need to be increased). Any idea how to improve this?
Edited by ChrisH on 2015/6/16 19:45:11 Edited by ChrisH on 2015/6/16 20:07:20 Edited by ChrisH on 2015/6/16 20:11:13 Edited by ChrisH on 2015/6/16 20:11:54 Edited by ChrisH on 2015/6/16 20:13:32 Edited by ChrisH on 2015/6/16 20:16:58 Edited by ChrisH on 2015/6/16 20:19:22 Edited by ChrisH on 2015/6/16 20:30:13 Edited by ChrisH on 2015/6/16 20:31:27 Edited by ChrisH on 2015/6/17 0:36:04
What I don't understand is why the following behaviour is not the default for MUIC_Text (or at least be an option), since it's what I'd intuitively expect:
The reasons are simple: 1. compatibility to older MUI versions 2. MUI just offers the basic functionality. If this is not enough for a specific case then it is your task to enhance the behaviour to match your requirements. MUI cannot guess everything. Completely vanishing text might be desired. If Text.mui would enforce an aribtrary amount of text to remain visible it would be impossible to revert this calculation in a subclass.
Quote:
The only thing I needed to do was to sub-class MUIC_Text so that it's MinMax method contained the following lines: Quote:
(That's AmigaE code, but the C equivalent should be fairly obvious.)
I did also add a New method to force MUIA_Text_SetMin to TRUE, since that's required by my code. But it's not strictly needed, since that's the default value.
The magic number "6" is what the Text class would otherwise have for minwidth, if MUIA_Text_SetMin was FALSE. Unfortunately I don't know how to calculate/deduce this, so it's hard-coded (if it causes problems then it would need to be increased).
You definitely failed to read and understand the file MUIdev.guide. Please reread it from top to bottom, especially the section about the MUIM_AskMinMax method. It clearly states that the custom dimension values of your class are to be added, not just set. Adding is necessary, because at the time the MUIM_AskMinMax method reaches your class at least Area.mui (the superclass of Text.mui) and Text.mui already have added up their size requirements. Area.mui fills in any size requirements due a frame (frame size + spacing) and Text.mui fills in the size requirements due to the text size, depending on the values of MUIA_Text_SetMin/Max. Then it is your task to enlarge the sizes according to your class' personal requirements.
The value 6 you are seeing is the summed up size requirement of your class' superclasses, namely Text.mui and Area.mui. Most probably you have set a visible frame. I'd guess it is a frame that is configured to have a frame size of 1 pixel plus a horizontal spacing of 2 pixels on both sides (or vice versa). Due to MUIA_Text_SetMin being FALSE Text.mui will add 0 to the minimum width in its MUIM_AskMinMax method. All this sums up to the value of 6. It is a bad idea to override this value by any other fixed artificial value, because this effectively makes the user's frame configuration void. In the worst case this might cause unwanted graphical corruption, because Text.mui's MUIM_Draw method might draw outside the desired area or at least it might ignore some certain frame spacing settings, because it doesn't know about your aritifically restricted minimum width.
If you want a text object which is able to shorten its contents but which does not allow the text to become completely invisible, then all you need to do is to set MUIA_Text_SetMin to FALSE and add an arbitrary small value to MinMaxInfo->MinWidth to ensure that the object cannot become smaller than that size while a possible frame is still correctly respected with its size and spacing. For example something like this: Quote:
This will leave at least 6 pixels for the text to be displayed and will correctly respect any frame being set for the object. But I must add that such a fixed minimum size is still a bad idea, because depending on the user's font settings these artifical 6 pixels might still not be enough to display even a single character.
MUI4 offers the MUIM_TextDim method to calculate the dimension of arbitrary strings depending on the object's font settings. The returned 32bit value contains the width in the lower 16 bits and the height in the upper 16 bits. The next nightly build of MUI4 will also contain the two DIM2WDTH/HEIGHT macros to extract the values in a convenient fashion. So better use MUIM_TextDim to calculate the width of a commonly fairly wide character (i.e. "W" or "M") and add the calculated width as the additional minimum width requirement within your MUIM_AskMinMax method: Quote:
ULONG dim; DoSuperMethodA(cl, obj, msg); // calculate the dimension of the character "W" using the object's current font settings dim = DoMethod(obj, MUIM_TextDim, "W", -1, NULL, 0); msg->MinMaxInfo->MinWidth += DIM2WIDTH(dim);
This will ensure that at least the widest character will remain visible while more narrow characters might fit.
You definitely failed to read and understand the file MUIdev.guide. Please reread it from top to bottom, especially the section about the MUIM_AskMinMax method. It clearly states that the custom dimension values of your class are to be added, not just set.
Oh I did read it... I just chose to ignore what it said, since I could not see an alternative. I've implemented my own hierachial redraw system similar to MUI's, so I have a good idea why it works the way it does.
The post I made was in fact a plea for help in doing it a better (i.e. non-rule-breaking) way using MUI, since I'm fully aware it could cause graphical problems with some configurations/situations.
Quote:
If you want a text object which is able to shorten its contents but which does not allow the text to become completely invisible, then all you need to do is to set MUIA_Text_SetMin to FALSE and add an arbitrary small value to MinMaxInfo->MinWidth to ensure that the object cannot become smaller than that size while a possible frame is still correctly respected with its size and spacing.
Unfortunately that does NOT produce my desired behaviour. Since you apparently didn't understand my code's intended behaviour, let me try to clearly state in English:
I want these two behaviours: 1. A minimum width of 'zero' (i.e. the text can be completely hidden). 2. A default width that is the same as the initial text width.
This produces the extremely nice behaviour that MUI will try to show the whole text, but only if it's too large for the screen will it then truncate the text. It also allows the user to resize the window smaller, if they don't mind the text being truncated.
Quote:
MUI just offers the basic functionality. If this is not enough for a specific case then it is your task to enhance the behaviour to match your requirements. MUI cannot guess everything.
The point I was trying to make is that the above behaviour (that I want) seems extremely sensible/desirable for a large amount of programs/situations, and I find it very baffling that MUI doesn't offer this as a standard option.
@tboeckel While thinking about how I could fix this by writing my own alternative Text class (inheriting Area), I realised that I'd need to calculate the width of the text I'd be writing (as well as finding out which font MUI wanted me to use)... and if I could do that, then I might as well just sub-class Text & use that calculated width to replace the default width.
So I did finally implement it in a "MUI friendly" way. It's E code, and uses my easy-custom-class wrapper, but what I'm doing should hopefully still be obvious: Quote:
PROC askMinMax(cl:PTR TO iclass, obj:PTIO, msg:PTR TO muip_askminmax) OF muiText DEF rp:rastport, te:textextent, contents:ARRAY OF CHAR
Setting MUIA_Text_SetMin to FALSE and MUIA_Text_SetMax to FALSE should do exactly what you want. SetMin serves to set either no minimum width (FALSE) or the text's maximum width as minimum width (TRUE). SetMax serves to set either no maximum label width (FALSE) or the text's maximum width as maximum label width (FALSE). Thus perhaps your own implementation should only restrict the minimum width to not let the label disappear completely.
If you really want to implement your own dimension calculation you can use MUI4's Area.mui method MUIM_TextDim. This has the advantage of respecting every detail MUI's text engine. Otherwise you are most probably restricted to plain texts only.
And regarding your example code, you really should not set the default width, but call the superclass' MUIM_AskMinMax method first and then add your own space requirements.
Setting MUIA_Text_SetMin to FALSE and MUIA_Text_SetMax to FALSE should do exactly what you want.
Unfortunately it does not, which has been my whole problem. It behaves as if the Text class does not modify the default width to take account of the initial text's width.
edit: If you have changed MUI behaviour in a recent version of MUI4, then it's possible I don't have that installed... however I would have assumed the default behaviour would be unchanged due to backwards-compatibility reasons.
Quote:
If you really want to implement your own dimension calculation you can use MUI4's Area.mui method MUIM_TextDim. This has the advantage of respecting every detail MUI's text engine. Otherwise you are most probably restricted to plain texts only.
Yes, I realise that my current implementation doesn't correctly handle formatting.
Thanks for the tip about MUIM_TextDim, I'm now using that when compiling for AmigaOS4. (edit: It also dynamically checks that MUI4 is available.)
Quote:
And regarding your example code, you really should not set the default width, but call the superclass' MUIM_AskMinMax method first and then add your own space requirements.
Don't worry, my MUI wrapper already does that automatically. Since it should always be called, it happens without me needing to remember such BOOPSI boilerplate
Edited by ChrisH on 2015/8/14 13:36:35 Edited by ChrisH on 2015/8/16 18:49:27
Setting MUIA_Text_SetMin to FALSE and MUIA_Text_SetMax to FALSE should do exactly what you want.
Unfortunately it does not, which has been my whole problem. It behaves as if the Text class does not modify the default width to take account of the initial text's width.
edit: If you have changed MUI behaviour in a recent version of MUI4, then it's possible I don't have that installed... however I would have assumed the default behaviour would be unchanged due to backwards-compatibility reasons.
The initial behaviour of Text.mui was to modify the minimum and maximum width only and to leave the default width untouched. In January of this year I added a small change to set a default width of 3 "wide" characters to avoid invisible text labels by default. I guess this is the inconvenient behaviour you are experiencing right now. I just commited a change which sets the full text width as default width. This will let MUI make the window as wide as possible while still being able to cut off the text if its width exceeds the screen width.
Quote:
Don't worry, my MUI wrapper already does that automatically. Since it should always be called, it happens without me needing to remember such BOOPSI boilerplate
Calling the superclass' method depends on what you want to archive. For certain methods the superclass' methed MUST be called (i.e. MUIM_Setup), but in certain other methods it is ok to skip the superclass' method (i.e. MUIM_Draw) if you are sure that this is ok and if you can ensure yourself that this doesn't cause any harm. Sometimes this is necessary, because otherwise superclass might do things which you definitely want to avoid to happen.
I just commited a change which sets the full text width as default width.
This sounds good in general... but it's gonna cause some confusion when testing MUI programs on AmigaOS4, and then later finding-out they look much worse with MUI3.x on AmigaOS3 (and other compatible) systems (including any old AmigaOS4.0 systems that haven't been updated!). Personally I'd have prefered such an improvement to be opt-in...
Quote:
Calling the superclass' method depends on what you want to archive. For certain methods the superclass' methed MUST be called (i.e. MUIM_Setup), but in certain other methods it is ok to skip the superclass' method (i.e. MUIM_Draw) if you are sure that this is ok and if you can ensure yourself that this doesn't cause any harm. Sometimes this is necessary, because otherwise superclass might do things which you definitely want to avoid to happen.
I spent some time examining the MUI documentation & examples before deciding on whether or not super-methods should be automatically called by my MUI wrapper class. The only instance I could find/think-up, where it'd be a problem, was the get() method.
I'd be interested to know which other methods/situations it could be a problem for...
This sounds good in general... but it's gonna cause some confusion when testing MUI programs on AmigaOS4, and then later finding-out they look much worse with MUI3.x on AmigaOS3 (and other compatible) systems (including any old AmigaOS4.0 systems that haven't been updated!). Personally I'd have prefered such an improvement to be opt-in...
You cannot make every single bit optional. That would make the MUI settings even more complex than they are already. Furthermore the default dimensions set during MUIM_AskMinMax are just a hint about how big the object wishes to become. If the desired dimensions exceeds the minimum/maximum dimensions it will be restricted accordingly. Finally MUI offers to snapshot the windows to make the layout/dimensions permanent. If one thinks the default sizes are bad it is no problem to adapt them and restore them for future uses.
Quote:
The only instance I could find/think-up, where it'd be a problem, was the get() method.
OM_SET should also end up in DoSuperMethod(). Otherwise it will be impossible to modify any attributes of the parent class.
Quote:
I'd be interested to know which other methods/situations it could be a problem for...
In general you can call DoSuperMethod() for any overridden method, unless you have very good reasons not to do so, i.e. if you want to replace the method's behaviour completely. If you class adds own custom methods then DoSuperMethod() of course is useless, because the parent class doesn't know the method and cannot do anything with it except passing it up to rootclass which eventually will do nothing than returning zero. To make it short: a waste of time.
You cannot make every single bit optional. That would make the MUI settings even more complex than they are already.
Fair enough, although from *a* point of view I was merely advocating a kind of "backwards compatibility"
Quote:
OM_SET should also end up in DoSuperMethod(). Otherwise it will be impossible to modify any attributes of the parent class. ... In general you can call DoSuperMethod() for any overridden method, unless you have very good reasons not to do so, i.e. if you want to replace the method's behaviour completely.
I think you misunderstood me, and we are talking at cross-purposes now:
My MUI class wrapper *automatically* calls the Super methods, so that I don't have to. I thought we were arguing about cases where you might *not* want this to happen.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
