@zzd10h

Quote:

"That's interesting the crash that's fixed by NOCACHING has only been seen predictably on a SAM 460 so far." On X1000, too, I had a lot of crash until that I use NOCACHING tooltype.

Curious, apart from couple of PDFs I don;t think anyone of the testers has seen this crash on x1ka SAM or a1XE only Epsilon when he tried it on a SAM 460

Quote:

I just sent you by mail 2 littles pictures that are well displayed on different picture viewers but not in MV without NOCACHING.

No crash here, please send me the crashlogs.

Quote:

Datatype.library DSI is skippable, after all works well.

That's subtly different then, I think the previous SAM 460 crash resulted in no file displaying.

Quote:

What is the goal of "NOCACHING" tooltype ? According to the doc "Cacheing is required if the editor feature is used" but even with NOCACHING, I'm able to edit text in NotePad, Pictures in FastView...

MultiViewer caches the files data in memory, both to speed up later accesses and to prevent the datatype from locking the file. If NOCACHING is enabled you will be able to edit the file, but not save it back over the original.

When NOCACHING is *not* used then the file is watched when edited and automatically refreshed in the MultiViewer window when you save your edit.

At the programming level MultiViewer is using source type DTST_MEMORY and switches back to the more common DTST_FILE when NOCACHING is enabled.

Almost all other software likely uses DTST_FILE

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@Lazi

Quote:

Quote: Quote: there is no way to know if you have class to display agiven datatype But if I start MultiViewer and select an executable file in the asl requester it pops up the message: "Unknown data type..." and MultiViewer quits. So it knows that can't display the content.

Maybe I need to expand y statement a little for clarity:

There is no way to know if there is a class available to open an object of a given datatype, without attempting to open the object. This means I can't filter the object out at when adding to the file list except at a higher level via the group ID (Picture, Sound, System etc).

Clearly if you scan a directory with 1000 images and i binary which happens to be there by accident (or even design if it happens to be PPView :-0) I can't load every file at the start that would rapidly use up all memory.

I did try an create test for a class by opening and closing the <basname>.datatype library to detrmine if it was present, however this caused random crashes in some datatypes so was clearly not 'legal' within the datatypes framework. I've raised an enhancement request for an API extendion to allow detecting a class ahead of attempting to open a file, but even if that's get high priority, it wont appear tomorrow, so a comprimise situation offiltering by group exists for now.

The empty tab is not completely useless, you will see it tells you what type the object is in the status bar.

You could also install a binary datatype there are a few out there.

Last edited by broadblues on 22-Jun-2015 at 10:28 AM.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@Lazi

Quote:

Open a simple text file. Try to select all lines by mouse. It does not stops at the last line, scrolls the text out of the page. I think it would be better if the scrolling would stop if the last line is at the bottom of the page or the page is larger than the content.

This behaviour is defined by the text.datatype the scrolling is in response to requests by the from the dataype object to be scrolled.

This is the behaviour most people would expect for text I think.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

Quote:

This is the behaviour most people would expect for text I think.

Maybe I am expressing my thoughts badly. Here is a picture that tells more then several
malformed sentences:



Left side is the classic multiview, where you cannot expand the selection beyond the end of
the file, thus the scrolling is stops at the bottom of the window.

Right side is MultiViewer where the scrolling does not stops even if we reached the end of the text.

I am not expecting such behaviour. I hope I am not alone :)

Last edited by Lazi on 22-Jun-2015 at 01:55 PM.

@Lazi

Ah okay, hadn't spotted that it will scroll past the end of the doc, I thought you meant past the end of the visible section. MultiView must overide the scroll request if beyond the end of the file, I'll take a look at that.

Last edited by broadblues on 22-Jun-2015 at 02:03 PM.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues
Quote:

I've raised an enhancement request for an API extendion to allow detecting a class ahead of attempting to open a file, but even if that's get high priority, it wont appear tomorrow, so a comprimise situation offiltering by group exists for now.

It shouldn't that hard to make the API extension since the code is already in the library in the form of the ARexx command "EXAMINEDT". Try the "examinedt.rexx" script located in the datatypes.library autodoc (datatypes.doc). It worked well when I tried it.

_________________
X1000 with 2GB memory & OS4.1FE

@broadblues
Quote:

Thanks for that extra info, tried that (16bit wbscreen) on my X1k and still no crash, but something to investigate further....

Since nobody else has confirmed it, Ihave to assume that everyone else is using 32 bit screenmodes or that it's not crashing for them in 16 bit screenmode either. Possibly my graphics card or drivers have something to do with it. I'm using an X1K with Radeon HD 5450, PCIGraphics.card 53.9 and Radeon.chip 2.10. Thanks for trying to reproduce it though.

_________________
X1000 with 2GB memory & OS4.1FE

@Xenic

ExamineDT just returns the datatype not whether there is class installed for the datatype, usually the two go hand in hand but not always the most obvious cases when it doesn't being System binary System drawer System Font etc which will be indentified but have no class to deal with them by default.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@Xenic

Quote:

Since nobody else has confirmed it, Ihave to assume that everyone else is using 32 bit screenmodes or that it's not crashing for them in 16 bit screenmode either. Possibly my graphics card or drivers have something to do with it. I'm using an X1K with Radeon HD 5450, PCIGraphics.card 53.9 and Radeon.chip 2.10. Thanks for trying to reproduce it though.

Give or take a few revisions of gfx library my setup is just about the same, I will have another go at testing for this crash later.

I think you are right that most people use 32bit screens, especially on an X1k. Some with micorAones and SAms with low gfx mem may use 16bit though.

I did do couple of test on 16bit early on, as the compositing code for the marking mode needed a some adustment for them but I haven't tested regularly on that mode for a while.

I believe PJS tested on 16bit with his SAMep

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues
Quote:

Ah okay, hadn't spotted that it will scroll past the end of the doc, I thought you meant past the end of the visible section. MultiView must overide the scroll request if beyond the end of the file, I'll take a look at that.

It's easy to overlook because it returns to a normal position when you release the mouse button or click on the window again. There is something strange about the scrolling when marking textt in Multiview and Multiviewer. When marking text, scrolling speeds up if you move the mouse pointer back and forth (horizontally) while scrolling. In my text editor (and other editors an viewers) the scrolling is faster when the mouse pointer is at the left side of the window and progressively slower as the pointer is moved toward the right side of the window. That method provides more user control over the scroll speed. However, the scroll speed is probably under the control of the datatype so there's possibly no way to change it.

_________________
X1000 with 2GB memory & OS4.1FE

@Xenic

Quote:

When marking text, scrolling speeds up if you move the mouse pointer back and forth (horizontally) while scrolling.

Moveing the mouse pointer side to side like that generates more input events, if the scroll is increment by a line for each event (or number of events if there is some scaling involved) where the mouse is outide the scrolling area then that would explain that phenonimum. I've seen a fair few programs exhibit this behaviour (not just in amigaos either).

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

Crashlog sent with my MV binary if the problem comes from my tooltypes.

Thx for your explanation about NOCACHING, you are right, "Replace" of modified original file doesn't work in this mode.

Last edited by zzd10h on 22-Jun-2015 at 05:53 PM.

_________________
http://apps.amistore.net/zTools

@Xenic

Quote:

Xenic wrote: I think I've found a reproducible system freeze with Multiviewer. Here are the steps to reproduce the freeze: Double-click the Multiviewer icon to open an ASL file requester. Select several JPEG files in the requester and select OK. When the Multiviewer GUI opens, select the "Project/New Tab" menu item. My system freezes completely; including the clock. Can anyone else reproduce this freeze??

Tried this but couldn't reproduce the freeze.

Cheers

_________________
If your nose runs and your feet smell, you're upside down.

@TiredofLife
Quote:

Tried this but couldn't reproduce the freeze.

After my post I determined that it is only happening on 16 bit screens. The procedure I described wasn't even necessary. When Multiviewer is running on a 1280x1024x16 Workbench screen it will freeze if I select the "Project/New Tab" while an image (jpeg, png etc.) is displayed. If I run Multiviewer on a 32 bit Workbench (1280x1024x32) there is no freeze when I open a new tab while an image is displayed. Thanks for trying.

_________________
X1000 with 2GB memory & OS4.1FE

@broadblues

I use ImageFX a lot for editing and creating alpha blended images. I tested Multiviewer for previewing some of the images I've created and the checkerboard background makes it impossible for me to see them accurately.

Old multiview uses a grey background and I get a better idea of how the image will look on a normal background. Could you please use a solid background to display alpha blended images?? Better yet add a Tooltype/Arg to set the background for alpha blended images. Alternatively, have Multiviewer load a background pattern with a specific name if it's found.

As an example of why I find the checkerboard background unsuitable; save the normal image from SYS:System/Typemanager and view it in Multiviewer. I can't even tell what the image is supposed to be, let alone how good it looks.

Sorry to be a pest but the checkerboard really spoils it for me.

_________________
X1000 with 2GB memory & OS4.1FE

@Xenic

Strange, I tried with a 16 bit screen and had no problem.
What graphics card and driver are you using?

Cheers

_________________
If your nose runs and your feet smell, you're upside down.

@TiredofLife
I'm using an X1000 with Radeon HD 5450, PCIGraphics.card 53.9 and Radeon.chip 2.10. I also purchased and installed the Warp3D stuff from AmiStore but I don't think it will do anything with my graphics card.

_________________
X1000 with 2GB memory & OS4.1FE

@TiredofLife
After a lot more testing I've discovered that the freeze only occurs if my system partition is locked (write protected). I found 2 ways to eliminate the freeze:

1. Unlock my system partition. The only Multiviewer activity that Snoopy shows when adding a tab is some font access.

2. Before starting Multiviewer, issue the command "path C: add head" in a shell. How an AmigaDOS command that essentially does nothing could prevent a freeze in Multiviewer is anyones guess. It doesn't make sense to me but it works.

If you want to test in 16 bit mode again, you can try entering something like "lock DH0: on password" in a shell before running Multiviewer.

_________________
X1000 with 2GB memory & OS4.1FE

@Xenic

Tried locking the partitions as well as using 16 bit screens.
Still unable to reproduce the problem.

Cheers

@Broadblues

Is it possible to set up MulitViewer to scan sub directories?

Cheers

_________________
If your nose runs and your feet smell, you're upside down.

@TiredofLife

Quote:

Is it possible to set up MulitViewer to scan sub directories?

A recursrive scan rexx script shouldn't be too difficult to create.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad