@Deniil

1. there is a MUI bugtracker at https://github.com/amiga-mui/muidev/issues
2. just a single register content from a crashlog does not help anybody. Please provide a full crashlog. And if possible please use the debug version of muimaster.library to get a more detailed crashlog.
3. Popasl.mui is a subclass of Popstring.mui and does nothing fancy but allocating an Asl requester in its constructor. have you tried Popstring directly in your application?

@Hans

Use the Java based lha package:
apt install jlha-utils libjlha-java

@white

It took me quite a while to discover what you are trying to show. Perhaps you should describer the problem a bit more instead taking videos of several minutes including the boot process, although the interesting part comes towards the end and one has to guess what might be wrong.

If I understand your video right, then at one point the Odyssey window is on the Workbench screen and no matter how often you try to jump the the "Odyssey" screen it still remains on the Workbench screen. Only explicitly choosing "Workbench" first and "Odyssey" afterwards makes it jump to the desired screen. Is that correct?

You could try the debug version of muimaster.library and produce a "screen" debug log as described here: https://muidev.de/wiki/FAQ/Debugging#B ... ersionofmuimaster.library

Since you don't have any crash the additional mentioned tools like MemGuard, Enforcer or SegTracker are not required.

I need that debug log to get a hint of what might go wrong during screen switching.

It would be nice if someone could try to reproduce the crash using the supplied binaries with debug symbols included. That way the crashlog contains file names and line numbers.

@ddni

The addition to S:User-Startup depends on the user's choice. As such I cannot tell whether it will stay or not. But at least the Installer script will continue to offer to add the call.

If you encounter DSIs or other crashes then don't hestitate to open a new ticket in MUI's bugtracker and attach the crashlog. Just telling about issues without providing any details doesn't help anybody.

Just disable or remove the MUI:PatchASL call in S:User-Startup.

@all

First of all, I am unable to reproduce this issue on my emulated AmigaOS4 setup. Free memory figures stay exactly as they are after starting any MUI application and simply waiting for whatever to happen.

Everybody who is experiencing this effect is asked to try the current nightly build and produce an "ALL" debug log using the debug version of muimaster.library.

The current nightly build can be found here: https://muidev.de/download/MUI%205.0%2 ... 5.0-20180724r6309-os4.lha
and the debug version can be found here: https://muidev.de/download/MUI%205.0%2 ... 180724r6309-os4-debug.lha

Details about how to prepare your system for a debug log can be found in the FAQ: https://muidev.de/wiki/FAQ/Debugging#B ... ersionofmuimaster.library

Please attach your log to MUI ticket 387: https://muidev.de/ticket/387

@kas1e

Although reporting bugs anonymously is possible it makes communication a real pain, because the reporting person cannot be automatically notified about changes to the ticket. As such it is hard to ask for further details.

To sum it up: better create an account and log in before reporting bugs.

@remotenemesis

Use Floattext class. Examples can be found in MUI's MUI-Demo application.

Every project on github automatically gets a bugtracker. I really recommend to use it.

@Vulture

The official site for MUI for AmigaOS exists since 3 years by now. It is really quite ignorant if you didn't spot it by now, left alone the regular announcements of new MUI versions here on this site. The last release is just 2 weeks ago.

But ok, once more just for you: www.muidev.de

@kas1e, @xenic
Please refer to ticket #333 in the MUI bugtracker: https://muidev.de/ticket/333

All further discussion about the bug should be continued there. The bugtracker exists for very good reasons.

@kas1e
Roman, you really should include your modified source code in your release archive. Otherwise it will be hard to tell whether a bug is caused by your modifications or whether it has been in the original code already.

@xenic
You should not jump to conclusions so easily. The fact that an MUI application openes an Asl requester does not necessarily mean that Popasl class is responsible for the requester. Popasl class opens a requester upon user interaction only (i.e. clicking the popup button). This should have become obvious when reading the corresponding Autodoc, which you obviously did as you mentioned the Autodocs yourself.

I almost forgot. The "missing character" bug is fixed now. It was as old as MUI 3.8 (or maybe even older). But of course it looked like a bug of VPDF on the first sight.

Calm down boys. The release of MUI 5.0 2017R1 has just been preponed to January 31st. So there is no need to wait two more month for an official release for those who are affraid to use the nightly builds.

But I must second Roman. Sometimes one really has to force people to upgrade to a new version, otherwise they will continue to use the old versions and more sooner than later they will complain again about already fixed bugs. And since most users are not able to tell whether a bug is caused by component A or component B they will most probably blame the obvious but wrong component. A simple version check against known bugs like Roman did in VPDF is much better than having to deal with invalid bug reports over and over again.

@kas1e

It doesn't matter who produces the output. If only samo can reproduce it, ok. But without this information we are just guessing what might be causing the missing character instead of pointing out facts.

@kas1e

Perhaps you should follow my advise to add some output of the chapter titles to the shell before they are added to the listtree, just to make sure they are correct before MUI gets hands on them.

If they get printed out correctly, then it is MUI's fault, otherwise VPDF is guilty.

@jabirulo

NEVER mix different C runtime libraries. Choose either one or the other, but do not mix them. Although they (amost) offer the same set of features and functions they are operating on completely different internal structures.

This should be fixed in the next nightly build. Please test and if the bug persists please reopen the appropriate ticket in YAM's bugtracker: https://github.com/jens-maus/yam/issues/647

Does anybody still have this expiring problem, or is this issue invalid/solved?

@djrikki

I just installed the latest nightly build by copying over all libraries and MUI prefs definitely states that it expires on April 9th 2016, which is exactly 30 days after the build date, as expected.

The AutoInstall script might be the culprit here, because the CopyStore command will copy libraries with a different version only. Hence muimaster.library will not be copied unless its revision was bumped. I also just noted that the AutoInstall script copied the class files (#?.mui, #?.mcc, #?.mcp) only, but not muimaster.library. The next nightly build will fix this.

However, installing the nightly builds is better done by manually copying all relevant files. This will ensure that nothing is omitted.