How can we help Xojo to eliminate bugs?

The Feedback app definitely needs some love. That’s one reason I’m glad they’re going to work to replace it with Web 2.0.

Please post a few feedback cases to check.

Here a couple ones, that cost me some time until finding (or getting from someone else) a work-around:
<https://xojo.com/issue/54421>
<https://xojo.com/issue/59351>
<https://xojo.com/issue/58856>
<https://xojo.com/issue/48989>
Because there is some sort of work-around should not mean that a fix is not needed in a timely manner…

This one has really messed me up, I had to convert every sleep call in my app to a Timer that will call Thread.Run and a couple of state variables to pick up where it left off.

<https://xojo.com/issue/56420>

This one had my clients and I very confused for much longer than I wished. It was working in a previous version so I thought it was my code rather than the framework.

<https://xojo.com/issue/54491>

For <https://xojo.com/issue/54421>, you’d better check JPEGImporterMBS and TiffPictureMBS classes. See ScaleFactor property.

Xojo keeps for each picture on MacOS a CGImageRef internally for drawing, which may consume additional memory.

Stupid question:

What Xojo must do:
• squash that bug (with a know workaround)

or

• remove another bug who do not have a work around ? :wink:

Obscure bugs ? We do not have time nor resources, skip them.

[quote=490019:@Emile Schwarz]What Xojo must do:
• squash that bug (with a know workaround)

or

• remove another bug who do not have a work around ?[/quote]

Simply replace the „or“ in the question with an „and“ :slight_smile:

I like to add that <https://xojo.com/issue/59351> seems to be no bug.
The encoding property was added, which is a behavior change, but if you set it, it works well.

I think so too, but to do that, hiring people is certanly needed and they do not want to pay someone during a year for nothing (just to be efficient with the code).

And even if they change their mind today, it will make results in 2021-06…

Do you still want to discus about the bugs ?

BTW: and what are we doing with our own bugs in our own application ?
(I began to be lazy recently, probably an oldster stuff :().

Well, usually we know Xojo staff is busy and a lot of cases are don’t get much attention.
So I personally try to make it as easy as possible for them. e.g. provide an example, steps, maybe a video to show it.
I always hope the engineer sees the problem laid out clearly and can reproduce it in a minute, so they schedule time to fix it.

It looks like the docs for TextOutputStream are missing the Create Write method and the Encoding property.

People could think that having the String with certain encoding should be enough for TextOutpusStream to write with that encoding without the need to define TextOutputStream.Encoding.

Edit: Write not Create

Well, create is there: TextOutputStream.Create

Sorry I wrote Create instead of Write (fixed my post).

There is no information about Write but it is used in the example:

output.Write(TextField1.Value)

Testing the TextOutputStream and using the example on the page, this works:

output.Write(ConvertEncoding(TextField1.Value, Encodings.UTF8))

because output.Encoding is UTF8 by default, if we change the code to:

output.Write(ConvertEncoding(TextField1.Value, Encodings.MacRoman))

it doesn’t work, we need to change the code to:

output.Encoding = Encodings.MacRoman output.Write(TextField1.Value)

I guess that is why <https://xojo.com/issue/59351> was created, it is expected to work by changing the encoding for what is going to be written instead of setting the output.Enconding.

I was thinking that String already has the right encoding, we can add a line of code before write, changing:

flux.write mcRm

to

flux.Encoding = mcRm.Encoding flux.write mcRm

@Norman Palardy suggested:

Create a new module
Add an extension method for TextOutputStream

Sub writeEncoded(extends tos as Textoutputstream, value as string) tos.encoding = value.Encoding tos.write value end sub

now you could probably write ANY number of different encodings into a file but it would be a mess without some other meta data being written into the file to know what encoding you are about to read / write

an alternative would be to write this extensions as

sub writeEncoded(extends tos as Textoutputstream, value as string) if tos.encoding is nil then tos.write value else tos.write ConvertEncoding(value, tos.encoding) end if end sub

The problem is that tos.encoding default value is UTF8 so it is never nil. But yes, we can change that to:

if tos.encodig = Encodings.UTF8 then

but if we alread have tos.Encoding <> Encdogins.UTF8 we just need to do

tos.write value

anyway, no?