Hyperion Entertainment Message Boards

saimo wrote:

nbache wrote:Multiview itself is (probably) irrelevant, it only acts as a hollow container for loading the actual datatype, such as amigaguide.datatype or text.datatype, based on the file content. All of the functionality, including cut and paste, is in the datatype.

I guess the graphical rendering isn't included, right?

As far as I have understood, even the rendering and the GUI are handled by the specific datatype.

What kind of file are you trying to mark stuff in?

Plain text.

Right, that would be ascii.datatype. It does come in a newer version in the now released Update 5 than in e.g. the current state of the First Contact Update 5 for the X1000. But I have tried reproducing your problem both on my A1 XE with the released Update 5 and on my X1000 with the currently released "mini"-updates, and marking, copying and pasting works fine on both. I started Multiview (from AmiDock), selected a file from S: (e.g. User-Startup) and marked and copied some text from it, and then pasted it into an empty Notepad window. Does that same procedure fail for you (just to make sure we are chasing the same thing).

Which versions do you have of datatypes.library, ascii.datatype and Multiview? Does Multiview's About requester say you have an ascii file loaded?

Best regards,

Niels

saimo wrote:

What kind of file are you trying to mark stuff in?

Plain text.

There was a new text.datatype included with Update 5, but no indication of what changes are in the new version.

nbache wrote:As far as I have understood, even the rendering and the GUI are handled by the specific datatype.

I'd be very surprised, as such a thing is IMHO philosophically incompatible with the design of the datatypes - the way I see it, datatypes are meant to give applications a standard interface to access data regardless of the format, but then what the applications want to do with the data is none of the datatypes' business.
Anyway, we're going OT

Right, that would be ascii.datatype. It does come in a newer version in the now released Update 5 than in e.g. the current state of the First Contact Update 5 for the X1000. But I have tried reproducing your problem both on my A1 XE with the released Update 5 and on my X1000 with the currently released "mini"-updates, and marking, copying and pasting works fine on both. I started Multiview (from AmiDock), selected a file from S: (e.g. User-Startup) and marked and copied some text from it, and then pasted it into an empty Notepad window. Does that same procedure fail for you (just to make sure we are chasing the same thing).

MultiView doesn't mark or copy anything (and I personally don't care ).

Which versions do you have of datatypes.library,

datatypes.library 53.4 (11/04/2009)

ascii.datatype

ascii.datatype 53.3 (12/30/2011)

and Multiview?

MultiView 53.3 (07/15/2010)

Does Multiview's About requester say you have an ascii file loaded?

Of course it shows the same version numbers above and adds "ascii Text".

saimo wrote:

nbache wrote:As far as I have understood, even the rendering and the GUI are handled by the specific datatype.

I'd be very surprised, as such a thing is IMHO philosophically incompatible with the design of the datatypes - the way I see it, datatypes are meant to give applications a standard interface to access data regardless of the format, but then what the applications want to do with the data is none of the datatypes' business.

The rendering is handled by the DataTypes object itself. They are BOOPSI objects and can be attached to windows, rendered and interacted with just like any other BOOPSI gadget. Rendering is usually handled by the superclass (in this case, text.datatype)

ascii.datatype 53.3 (12/30/2011)

Oh, maybe it was that and not text.datatype that was in update5. Which version of text.datatype do you have?

saimo wrote:datatypes.library 53.4 (11/04/2009)
ascii.datatype 53.3 (12/30/2011)
MultiView 53.3 (07/15/2010)

Right, those are the same as I have here on the A1 with the public Update 5 installation. And BTW my text.datatype is text.datatype 53.5 (01/05-2011) - but I believe that version was also present in Update 4 (or even earlier).

So that doesn't give us much of a clue.

Best regards,

Niels

@Saimo:

You haven't said so directly, but I get the impression that your Update 5 installation is not "clean" (out of the box). As far as I can see (correct me if I'm wrong), you have not created a clean installation of Update 5 by starting from Update 1 and installing each Update in turn, instead you have updated your old Update 4 installation, which may have corruptions.

If you make a clean installation as I described, I'm sure it will work properly. It certainly does here on a clean Update 5 system. If you still get the problem with a "clean: Update 5, then we can start to look for a fault.

chris wrote: There was a new text.datatype included with Update 5, but no indication of what changes are in the new version.

I don't remember seeing the Paste gadget active when viewing text in Multiview before. I just pasted a line while Multiview was displaying a text file and the window full of text was replaced with the line I pasted. Did Multiview do that before Update5? Maybe I just never noticed.

saimo wrote:Anyway, MultiView is no issue to me, but I'm really concerned about the make problem, which seems to have passed unobserved.
In the meanwhile, I've found that the problem is even easier to reproduce and more troublesome that I thought at first. F.ex. while the simple makefile below is processed, those annoying 1-2 seconds pauses happen in several places (which might differ from time to time).

Code: Select all

test:
	Dir RAM:
	Dir RAM:
	Dir RAM:
	Dir RAM:
	Dir RAM:
	Dir RAM:

You didn't reported your filesystem. Can it be related to it? If you copy your source tree to RAM:T does it expose the same behavior?

tonyw wrote:You haven't said so directly, but I get the impression that your Update 5 installation is not "clean" (out of the box). As far as I can see (correct me if I'm wrong), you have not created a clean installation of Update 5 by starting from Update 1 and installing each Update in turn, instead you have updated your old Update 4 installation, which may have corruptions.

No, I don't have an out-of-the-box installation (that was implied in this answer I gave you when you suggested to make a fresh install).

If you make a clean installation as I described, I'm sure it will work properly. It certainly does here on a clean Update 5 system. If you still get the problem with a "clean: Update 5, then we can start to look for a fault.

I'm just as sure. Which means that such a test would be of no use
What should be found is what in my system causes such a behaviour: it could be that my system is corrupt - in that case, it would be important to discover if that happened because of a system misbehaviour or if the system could be made more robust; and it could be that my system is perfectly sane, but a combination of factors brings to surface a hidden bug. Just like for the smart refresh bug I've found: had I followed your suggestion of re-installing everything from scratch, what conclusion would have we reached other than the already known "the bug doesn't happen on a fresh installation"? Instead, I made tests on my current system, and eventually found what, at user level, causes the misbehaviour.
Later I'll try to see if Snoopy returns anything interesting.

abalaban wrote:You didn't reported your filesystem. Can it be related to it? If you copy your source tree to RAM:T does it expose the same behavior?

This is a good one! And, actually, it does give an important indication: from RAM, the very same makefile I reported above, is processed without pauses. I find this very weird because that makefile executes the same command (Dir) from the same location (C:) on the same location (RAM:), which doesn't use the filesystem of all of my partitions (SFS). The extremely small size of the makefile excludes that it's a problem of the makefile being read in chunks (I don't know if make processes files like that, but it's the only thing that would explain an interaction with the filesystem other then the initial loading).

The new filesystem version is

SmartFilesystem 1.290 (01/21/2011)

whereas the one I had before was

SmartFilesystem 1.286 (11/25/2009)

Any idea anyone?