If by queued you mean the mail in the Outgoing folder then yes I can. If I click the "Send" button in the main window, all the messages in the Outgoing folder are sent. My only complaint is that if I go to the Outgoing folder an select a single message (one message is highlighted) and click on "Send" all the outgoing messages are sent. I've accidently sent some incomplete messages by doing that.

I'm an old user aswell (1989)

The freezing however now of the whole system gave me no clue at all to report.

As i still needed to have a working YAM i first reverted to older nightly builds
which worked and hoped that when newer came out the problem would have been solved.

That's really all i can come up with today,
i would gladly report more however : Please tell me what to check

In the past i indeed sinned a number of times logging in as "anonymous"
Please be aware that this was never intentional. You might consider that people make mistakes. Reporting a bug is not that simple. Often you start, loggin in correctly, writing down what you have seen, have some doubts, go back to the problem, get a crash, go back to the bugtracker, and then, thinking you are still logged in, end up sending something anynomously. That is what happened to me.

New tickets you submit will be routed for moderation. If you have an account, please log in first.

I wonder however why the site offers this possibility, as it is obviously important to know who is reprting the bug.

I have exactly the same problem, since late July. I have no idea at all why it happens. Here on A1XE.

the whole system froze during the loading of the interface. This was the case with at least 3 successive ,nightly builds. It may be correlated with thenew 'resources' drawer that appeared. If any i did miss instructions about this.

I was not able to use the Yam forum too : login did not work (some error message about certificates not OK)

Now 2.7 still has the annoying bug i reported about (and as taken care of in the 2.8dev) that messages saved in "outgoing" folder could not be send later.
Any view on when 2.8 stable could be released?

The FloattextObject is only 3 lines of text, and cannot resize vertically larger, despite containing 5 lines of text.

The TextObject should draw outside of itself (once), although horizontally resizing the window will get rid of the rubbish. The TextObject will behave as if it contains only one line of text (cannot be scrolled or resized to show the other lines).

Quote:

Would be nice if you could set up a tiny demo application which demonstrates exactly this behaviour with MUI 3.x. I'd like to know if this bug is fixed in MUI 4 already.

This is a bit difficult, since all my MUI code is auto-generated at run-time by my own GUI abstraction. However, I will see what I can do.

That isn't the problem. The problem is that a FloattextObject only shows 3 lines (what is required to show the scrollbar+arrows), even if it's initial contents is "a million lines". And it is not possible to enlarge it (nor the window ) to show more than 3 lines. Trying to read a million lines through a (fixed-size!) peep hole is not fun, and I find it hard to believe this is MUI's intended behaviour.

Still, if you think this is debatable, then perhaps it should be an option within MUI Prefs?

BTW, my ideal compromise (solution) would be for the MUI window to be "half way" between it's smallest possible size & it's largest possible size.

Quote:

Because you were telling something about "write outside of itself". I considered this as "text being displayed outside the object's box", because the text was modified externally by your application.

Yes, that is exactly what happens. When I use set().

Quote:

(FloattextObject) It may be zero lines, but it may be a million lines. What should the initial size be in this case?

That's easy. The initial size should be "as large as possible", but if you want more precise: The text box should request the full size (a million lines if necessary), and the Window should try to accomodate that. If the screen is not large enough, then no problem as the text box has scrollbars.

At the moment it seems to take the least useful initial size, which is "as small as possible" (no matter the initial contents).

AND WORSE is that it cannot be enlarged beyond the initial size (so the window is also vertically fixed).

Quote:

No, I am not wrong.

Your answer worries me. Either the autodocs for MUI 3.8 contain a serious error, or MUI 4 is going to break compatibility with MUI 3.x (programs). Since I assume that MUIA_Text_Copy is a new MUI4 thing, I would have expected it to default to TRUE, so that MUI 3.x programs get the behaviour mentioned in the autodocs.

I think you are wrong here, because the MUI Autodocs say "The string is copied into a private buffer, you can destroy the original after using this tag." (Of course you still need to use set() to tell MUI you want to change the text! MUI isn't psychic)

ChrisH wrote:
Quote:

(TextObject) If you really need to change the text, then you must set() it again after the modification.

That is what I *am* doing! Why did you think I wasn't?

Perhaps I misunderstand your reply, but it doesn't seem relevant to what I said: I want FloattextObject to show the entire *initial* contents, but it only shows 3 lines (no matter how large the window starts out). If this is the intended behaviour, it seems kind of useless!

If I use a TextObject, then it has the FULL initial size... but if I append extra lines then these are not visible (although a bug causes it to write outside of itself!). The only way to get it to enlarge for the new text is to iconise & then uniconise the MUI window. Also, the text is not word-wrapped.

If I use FloattextObject or TextEditorObject, then no matter the initial contents, the initial size is always 3 lines of text (which is the minimum space needed by the scrollbar + arrows), but it is at least vertically scrollable. Also, the text is word-wrapped.

If I use a List(view)Object, then there are two cases:

1. If I leave "MUIA_List_AdjustHeight" at it's default (FALSE), then the list only gets 3 lines (for the scrollbar & arrows), whatever the initial content. As a bonus the window can be vertically resized, and the list auto-adjusts to show more contents in the available space.

2. If I set it to TRUE, then it does get the full initial contents height BUT IT IS STILL SCROLLABLE when larger content is added. This SOUNDS like exactly what I wanted, but there is a catch! The list now has a FIXED height, which (in general) means that the window also has a fixed height. So IF the initial contents is empty, then the initial height will be 3 lines (even if the window has room to spare), and the window cannot be made any taller.

BTW, a side-effect of using List(view)Object is that the text is not word-wrapped (since I don't know where it should be wrapped!). But I actually consider this preferable (although being able to word-wrap might be handy).

Yesterday I was trying to create a little chart in an email with YAM and noticed that Tabs don't work on the editor. I don't know if it's an MUI, YAM, Texteditor or settings issue but would like to be able to use Tabs in the YAM editor.