Who's Online |
105 user(s) are online ( 98 user(s) are browsing Forums)
Members: 0
Guests: 105
more...
|
|
|
|
|
Re: HIGHLIGHTTEXTPEN vs FILLPEN (difficulties colouring MUI text)
|
Posted on: 2015/1/21 7:34
#41
|
Just popping in 
|
@ChrisH If you need specific colors then you should obtain a suitable pen using graphics/ObtainBestPen() before and then tell MUI to use this pen by something like "\033p[pennumber]". Don't forget to finally release the pen again before program termination. MUI does not make any assumption about specific colors for the standard pens. These are defined by Intuition and unless you did not change them or requested something like "Like Workbench" they will default to the internal default colors of Intuition. Finally, you really should no longer refer to the old and ancient documentation on sasg.com. This is limited to MUI 3.8 anyway. Up to date Autodocs can be found in each release archive on http://muidev.de/downloads.
|
|
|
|
|
|
Re: MUI text small & window fails to open if MUI_Text_Contents is too big
|
Posted on: 2015/1/12 20:01
#42
|
Just popping in
|
@ChrisH Quote: 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.deI 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.
|
|
|
|
|
|
Re: MUI text small & window fails to open if MUI_Text_Contents is too big
|
Posted on: 2015/1/11 18:50
#43
|
Just popping in
|
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.
|
|
Why stop it now, just when I am hating it?
Thore Böckelmann
|
|
|
|
Re: What is OS4's default character set?
|
Posted on: 2014/11/10 14:31
#44
|
Just popping in
|
Take a look at the source of codesets.library, function getSystemCodeset(): http://sourceforge.net/p/codesetslib/ ... EAD/tree/trunk/src/init.cThere you will find how codesets.lib supports all systems to obtain the currently active charset. Eventually it falls back to ISO-8859-1 if all other attempts fail.
|
|
Why stop it now, just when I am hating it?
Thore Böckelmann
|
|
|
|
Re: What is OS4's default character set?
|
Posted on: 2014/11/10 12:20
#45
|
Just popping in
|
That depends on your locale settings. For plain english the system charset should be ISO-8859-1, but i.e. for czech or other slavic languages it will be ISO-8859-2.
These two lines will give you the currently used charset:
LONG default_charset = GetDiskFontCtrl(DFCTRL_CHARSET);
char *charset = (char *)ObtainCharsetInfo(DFCS_NUMBER, default_charset, DFCS_MIMENAME);
Both are functions of diskfont.library.
Conversion is best done by codesets.library.
|
|
Why stop it now, just when I am hating it?
Thore Böckelmann
|
|
|
|
Re: Size gadget width
|
Posted on: 2014/10/25 19:45
#46
|
Just popping in
|
If you need to obtain the sizes before opening the window use this approach:
On AmigaOS4:
struct DrawInfo *dri = GetScreenDrawInfo(screen);
GetGUIAttrs(NULL, dri,
GUIA_SizeGadgetWidth, &width,
GUIA_SizeGadgetHeight, &height,
TAG_DONE);
FreeScreenDrawInfo(screen, dri);
On AmigaOS3:
struct DrawInfo *dri = GetScreenDrawInfo(screen);
struct Image *img;
width = 18; /* default sizing gadget width */
height = 10; /* default sizing gadget height */
if((img = (struct Image *)NewObject(NULL, "sysiclass",
SYSIA_Size, MEDRES,
SYSIA_DrawInfo, dri,
SYSIA_Which, SIZEIMAGE,
TAG_DONE)))
{
width = img->Width;
height = img->Height;
DisposeObject((Object *)img);
}
FreeScreenDrawInfo(screen, dri);
|
|
Why stop it now, just when I am hating it?
Thore Böckelmann
|
|
|
|
Re: 2 serious problems with YAM 2.9p1
|
Posted on: 2014/10/20 12:59
#47
|
Just popping in
|
@Phantom Quote: Before creating a new ticket each time I thought that asking first is a better idea, maybe it was something that I missed or configured it badly, so why opening irrelevant bug tickets everytime? Not reporting bugs at all is by far worse than opening irrelevant tickets. In particular this applies for the ASL error requester. So far we got no information about what is causing it. We only know how to get rid of it, but this is not a solution. This is curing the symptoms, not the cause. And keep in mind that we cannot pay attention to all available forums just to scan them for possible reports of bugs or other questions. Quote: About my second problem with that attached emails I downloaded and tried the latest nightly build but to no avail. Either I opened a ticket to YAM. Thanks.
|
|
|
|
|
|
Re: 2 serious problems with YAM 2.9p1
|
Posted on: 2014/10/20 11:07
#48
|
Just popping in
|
@Phantom How do you expect any valuable help if you don't provide any details? You say something about an error requester, but you what does it show? You say YAM refuses to send a mail with attachments, but you don't say in which way it refuses to send it. This is the typical "it doesn't work" kind of bug report. Regarding the ASL error requester, this was reported earlier already. So far nobody dared to check the latest nightly builds which include an error number. Instead people like to workaround the issue by deleting arbitrary files instead of grabbing the issue by its root. This is the perfect way to ensure that the bug will remain in YAM (if it should be a bug of YAM) and that it will arise over and over again for other people. Really, this isn't how bugs should be handled. Finally, YAM has a bug tracker at http://bugs.yam.ch for exactly this purpose: reporting bugs. Use it!
|
|
Why stop it now, just when I am hating it?
Thore Böckelmann
|
|
|
|
Re: ASL error (yam update) Fixed!
|
Posted on: 2014/9/9 9:35
#49
|
Just popping in
|
Good to hear the solution was so simple. But some information about the error message of the nightly build would have been quite interesting nevertheless.
|
|
Why stop it now, just when I am hating it?
Thore Böckelmann
|
|
|
|
Re: ASL error (yam update)
|
Posted on: 2014/9/8 19:49
#50
|
Just popping in
|
@VooDoo Quote: Now try last nightly build but no luck.. dont know how can resolve problem :( What about telling us the nightly build's error message? It contains both the DOS error code and the full error string. As long as you don't provide the most basic information nobody will be able to help you. Furthermore I'd suggest to continue the search for the solution in YAM's bugtracker. A forum like this is the wrong place for this.
|
|
|
|
|
|
Re: ASL error (yam update)
|
Posted on: 2014/9/8 12:50
#51
|
Just popping in
|
@VooDoo Quote: Just trry debug version ..but where log is located? You don't need to use the debug version unless more detailed informations are required. Just use the normal nightly build and try to reproduce the issue.
|
|
|
|
|
|
Re: ASL error (yam update)
|
Posted on: 2014/9/5 10:03
#52
|
Just popping in
|
@VooDoo
Try the nightly builds of YAM 2.10-dev. These will output the error number as well. That should reveal the true cause of that error message.
|
|
|
|
|
|
Re: A way to test if running the DEBUG kernel?
|
Posted on: 2014/5/20 12:51
#53
|
Just popping in
|
@all
Perhaps you should just bring up some very good reasons why it is necessary to distinguish the normal kernel from the debug kernel. Just reasoning "I am just curious" is too weak.
Usually user programs should not care at all which kernel is in use and run perfectly under both. If they fail, then this is most probably not a bug in the kernel.
|
|
Why stop it now, just when I am hating it?
Thore Böckelmann
|
|
|
|
Re: VOTE: openurl , urlopen or both
|
Posted on: 2014/4/18 19:34
#54
|
Just popping in
|
@Chris Quote: That doesn't help with the situation that we currently need to configure everything twice. Why? You choose either one system or the other. There is no need to configure both, unless you cannot decide and want to switch between both all the time. Once you decided for one system you have to configure only this one. Quote: I actually think adopting openurl.library for OS4, and writing a ReAction version of the Prefs GUI, would have been a better approach, but it's too late for that now. There is a ReAction GUI for openurl.library, but it is not included in the release archives for whatever reason. I will change this for the future releases and adapt the Installer script accordingly to let the user choose.
|
|
|
|
|
|
Re: VOTE: openurl , urlopen or both
|
Posted on: 2014/4/17 20:08
#55
|
Just popping in
|
There is absolutely no need for a stub library or any other workaround. For AmigaOS4 you can just try the URL: device first. If opening the URL that way fails (i.e. because URL: is not mounted) then fall back to openurl.library. If people don't like URLOpen then all they need to do is to move URL out of DEVS:DOSDrivers. Those who like it just leave it there. YAM does it exactly this way.
|
|
Why stop it now, just when I am hating it?
Thore Böckelmann
|
|
|
|
Re: how to detect if overlay is present in few strings ?
|
Posted on: 2014/4/3 9:15
#56
|
Just popping in
|
@kas1e
You can one overlay window at most only. Thus you must close the (invisible) window again after a successful check.
|
|
|
|
|
|
Re: how to detect if overlay is present in few strings ?
|
Posted on: 2014/4/3 8:45
#57
|
Just popping in
|
@kas1e
Perhaps you should set WA_Activate to FALSE and WA_Hidden to TRUE to avoid that the window becomes visible and takes away the focus of another active window if the function is just there to check if overlay is possible at all.
|
|
|
|
|
|
Re: echo and shell
|
Posted on: 2014/3/28 11:16
#58
|
Just popping in
|
@kas1e
Special characters must be escaped with a '*' character:
echo >1 "*"aaa*""
|
|
|
|
|
|
Re: MUI 4.0-2014R3 released
|
Posted on: 2014/3/17 19:45
#59
|
Just popping in
|
@sundown
If MUI ticket #23 was raised by you then please provide a crashlog. Furthermore creating an account on muidev.de and makeing sure to login before commenting will make future discussion much easier, because you will be notified about the progress automatically. Otherwise you will have to keep yourself updated yourself.
|
|
|
|
|
|
Re: MUI 4.0-2014R3 released
|
Posted on: 2014/3/17 12:20
#60
|
Just popping in
|
@sundown We have a bug tracker for exactly this purpose. Bugs reported in a forum will not be handled anymore, especially if they come without the crashlog. Please get an account there and don't forget to login before opening/answering a ticket.
Edited by tboeckel on 2014/3/17 12:46:05
Edited by tboeckel on 2014/3/17 12:48:01
|
|
|
|
|
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
