OS4.1 bugs

@tonyw
Quote:
Yes, I did. Using the mode 1680x1050 but setting screen size to 1696x1056, screen was cleared correctly. I tested even makeing 1696x1056 screen mode and using that mode in another pub screen. I think my monitor didn't like it. The whole screen was s***wed and there were random stripes, strange colours and everything. But when I took a screen grab with Sgrab that "sgrabbed" picture was perfect. (But when using 1680x1050 mode and the screen is not cleared it looks same in both sgrabbed picture and reality.)

I think making it possible to set backdrop of any public screen in screen prefs would be nice work around. Because setting the background would clear it

@Atheist

That happens to me too - has done since some OS4.0 update. I'm using a USB keyboard and mouse, don't know whether that is relevant.

There doesn't seem to be any particular reason for the lock-ups, and I've never managed to capture a crashlog for them over serial (I'm not sure if one is output or not)

@TSK

I also get gfx distortion, i.e. uncleared screens. I have seen it on DOpus textviewer two pixels below its menu there are random pixels and when I open PicShow as a flash before it opens its black window ontop of it.

Tried ImageStudio, it has had clearing problems all the way since A1200+BVision where I had to grab a window and "paint" away the wrong backgound screen colour. I tried it with different resolutions and 640x480 it got an incorrect background which I could paint away, but with 1680x1050 it became all garbage (i.e. not the same colour) including the window contents(!) after I switched screen mode! I could paint away most of it though.

Normally running 1680x1050x32 on Radeon9250 A1XE/OS4.1 but think I noticed it on OS4.0 too.

@TSK

The problem is not exactly that something is "not cleared".
The problem is that the video card reads bursts of 32, 64 or 128 pixels at a time. If the screen size is intermediate between two multiples of 32/64/128, then the card reads out of the bounds of the memory area set aside for the screen.
Usually, that means reading uninitialised or non-existent memory, hence the junk pixels.

I'll write another bug report.

@tonyw

Quote:

I believe you, of course, i'm not a betatester nor do i know any details about changes done on the system since 4.0

So, not to step on anyones toes, but it is clearly a limiting misbehaviour (if not a bug) when the system behaves like i described, is it not?

Maybe (and i say maybe because i cannot know) something else was changed which brought this limitation with it?
Would it hurt to file a bug report for it, too? It shouldn't be high priority, of course, but it breaks at least the AREXX script i did, because limiting the text output so that it fits again will limit the readability of the script in a rather ... well, limiting ... way

The text output in the top bar through ENV vars is btw limited since OS4 came out and i mentioned it, not as a bug but rather as a feature request, on, again, not very high priority.

Thanks tony for looking and answering

@tonyw

What about my second problem: Colours of the non-WB pub screens are wrong after DisplayBeep() (f.ex. when typing non-accepted characters in file requesters) ? Did you make a bug report for that too ?

@TSK

Here's one more. Anytime I quit MEmacs all my apps iconifies and deiconifies themselves. They accept/read SNOTIFY_AFTER_OPENWB and SNOTIFY_BEFORE_CLOSEWB messages only. That's annoying. (I don't know if this is related to the old SDK.)

My problem is probably no bug but something missing or not 100% compatible. Here we go:

I use os4.1. I have sonyericsson K810i mobilephone with 2gb memorycard for it. If the mobilephone is connected to the internal port of amigaoneG4XE it will show both internal mem and the 2gb of my mobilephone like a harddrive (masstorage).

If i connect the mobilephone to my NEC U-143 STLab usb2.0 card then os4.1 will show that it finds the mobilephone but will not mount the internal nor the 2gb memorycard.

I tested to connect a memorycard reader and the 2gb memcard to it and use it on the nec usb2.0 card then it will mount the 2gb memorycard.

I tested also my usb midi from ESI and it works both with internal usb and the nec card.

Only thing i havent tested with the nec card is my moms canon camera. It works on internal port and shows PTP.
Ill test some day on nec too.

Thats all from me.

A rather minor bug: Sam440's ethernet driver does not work with a 10Mbit connection. (This was on a VERY old hub.)

But it worked fine with OS4.1 on an AmigaOne (just ask Mikey C).

@Raziel

I've tried your Window title length problem and I can confirm it. It seems to have appeared between the July Update last year and the release of 4.1 this year.

I'll put in a report on it, but I think it'll probably be down to me to fix it... *sigh*.

@tonyw



Thank you very much

Could you by any chance comment on the title bar (ENV vars length limit) too?
I would take it as given if you say this is meant by design.
If so, maybe i'm allowed to ask if you might want to add a feature request to the bug tracker (very little priority, of course), just so that it don't gets forgotten?

Many thanks again

@tonyw

Can you look if there is also a bug report filled about scrollbar no updating themselves correctly in WB lister windows (every OS 4 versions since the first pre-release) ?
I can describe a way to reproduce it each time 100% if not.

@Raziel

I didn't understand your ENV vars limit problem so I've been unable to reproduce it. However, if you are using the same "> CON:///<title>" trick, there is a simple explanation:

The redirection "> output-file" is parsed by DOS, which treats it as a filename. Like any other filename, it is limited to 108 characters. Your "111111111x222..." string was truncated at 107 characters + a terminating Null. That's 107 characters counting from the "CON:...".

I'm still trying to find out why it USED to work and when it stopped working (hence, which component changed its behaviour).

I'll look into the other "bugs" as I get time.

@Abalaban:
The story about the scrollbar sounds familiar, I'm sure there was some discussion about it ages ago. When I get a chance, I'll look it up.

@tonyw

Quote:

Thanks a lot for the explanation

OK, here's how to test the titlebar issue.
Do a

echo 111111111022222222203333333330444444444055555555506666666660777777777088888888809999999990 >ENV:test

followed by changing the Workbench Prefs in "Screen Title Format" by adding a "%e test", wait some seconds and see what comes up on the Titlebar.

For me the line is cut at 69 chars, why, i don't know, but thats what i meant with Bug(?)/Feature Request to either fix(?) this behaviour or up the size of the string that's being displayed to at least 100 chars (maybe even make it userconfigurable?)

The problem here doesn't seem to be prominent as noone may use such long strings on the titlebar, but if one uses the Titlbar information feature from TuneNet and listening to radio stations, those informative strings can get long and i mean really long.

Would you be able to do something about it?

Please?

Thanks again for the quick feedback

@Raziel

Well, I can confirm that it truncates the string at 69 chars (weird).
I'll see what I can do.

[edit]
I've had a look and there is no specification for the maximum size of the string, in other words it can be limited to any arbitrary length.

I see that it is the same 69 character length in OS4.0 July Update, so it hasn't recently got smaller.

The best I can do is to put in an enhancement request to expand it.
[/edit]

ASL filter hooks are broken - they only work when in the current directory, or with a full path.

I've tracked this down to the following:
In the OS4.0 asl.library, the current directory was always set as the initial directory.
With OS4.1 asl.library, the current directory is set to the one displayed in the requester.

When the filter hook function runs using pre-OS4.1 compatible code, it is therefore unable to find any files, as filtering in sub-dir SUBDIR will cause any attempts to read the files as being in PROGDIR:SUBDIR/SUBDIR (PROGDIR:SUBDIR being current directory, and the displayed directory being added to that) instead of PROGDIR:SUBDIR.

Obviously this only affects relative paths.

Chris

@tonyw

Thank you very much again ... awesome feedback

@Chris

could you please cook up a small test app which clearly shows the behavior and provide the source?

That way Tony or myself can file a proper bugreport for the ASL maintainer who needs to reproduce this.

Thank you.

@Cyborg

Sure - WBPattern Prefs

Or, alternatively, the below will filter out files it can't open. you will quite clearly see the requester empty in relative paths, and ok in the initial dir or in full paths.

Add a GetCurrentDir() and printf the value within the hook function and the reason will be obvious.


#include <proto/asl.h>
#include <proto/dos.h>
#include <dos/anchorpath.h>

static const ULONG AslHook(struct Hook *mh,struct FileRequester *fr,struct AnchorPathOld *ap)
{
BPTR file = 0;
char buffer[10];
char fname[1024];

if(ap->ap_Info.fib_DirEntryType > 0) return(TRUE);

strcpy(fname,fr->fr_Drawer);
AddPart(fname,ap->ap_Info.fib_FileName,1024);

if(file = Open(fname,MODE_OLDFILE))
{
Close(file);
return(TRUE);
}

return(FALSE);
}

int main(void)
{
struct Hook aslhookfunc;
struct FileRequester *filereq;

aslhookfunc.h_Entry = &AslHook;
aslhookfunc.h_SubEntry = NULL;
aslhookfunc.h_Data = NULL;

filereq = (struct FileRequester *)AllocAslRequest(ASL_FileRequest,NULL);

AslRequestTags(filereq,
ASLFR_FilterFunc,&aslhookfunc,
TAG_DONE);

FreeAslRequest(filereq);

return 0;
}

@Chris

Quote:

Hm... I remember investigating that ages ago and even started to work on it.. Or at least it was on my todo list. I'll recheck with Colin to get this finally fixed, hopefully in time.