... which got revertes because of the SSD problems !
So, still (or again) at SP0 here ...

Certainly not !?

This reminds me of Manisandher who was ever so good as pointing out these things.
I will perform the RME "Digicheck" in due time which will for sure point that out. Btw, not when I can avoid it because currently I'm using the SPDIF clock from the Fireface for driving the I2S interface in my setup, which is fragile and possibly not to be copied at will afterwards ...

Anyway, until you find couter proof, I'm assuming you're right ...
?

Thanks !
Peter

Ah ... yes, this is very helpful. Not that I know where to begin looking, if I'd only be able to copy this behaviour. I see chances for that now.

Thanks !
Peter

PS:


I only had this once, and you can bet I have some crashes !!
Might you be able to tell what kind of crash causes this, please let me know.
Btw, do not forget that the "I" button restores desktop Icons but also implies some internal consistency when used at the right time.
Lastly, I too can have the situation that the wallpaper has vanished, but bringing up XX and quit it (or the other way around) always restores things. If not, this is not good and requires attention from me.
Just to let you know ...

Because there's absolutely no analogy between that area changing color on one side, and what you suggest on the other, BUT you quite well feel what it should be about ...

You're on the wrong track. That area stays as you see it. Nothing to be in there. Only the color can change (as you see it).

Very odd. But I assume during the "pre-load" of the tracks (say, right after Play) ?

Anyway it should be solved in the next version.

Thanks !
Peter

Whether you like it or not, below two pictures have one main difference : the color of that small area at the bottom in the middle.

What would that be for ?

By now I have changed things, and although something else may show up from it, this can't happen anymore. Not like it was anyway.

Indeed the message being masked by the XXHE window may tell that the message was first, which is exactly the proof that things don't workout for proper timing.

About InitialTrackDirectory : That is used for the "Library" button, and it indicates the first (default) directory to show. This should be the last one you used with that same button a previous time.
I don't see how that can influence here, but there's more I don't see.

Thanks,
Peter

Wow Russ, what a work you've put into this !

With the help of the scenario's you layed out so beautifully, I have a hunch in which direction this goes. It is about a technical thing and it may behave differently on different PC's I think. What happens is :

Such a slider (like a spinner) can be denoted a minimum (and maximum) value for the position. In this case this is 1.
As I told elsewhere, a microsoft (or whoever) bug causes that conflict situations can emerge, and actually this was just the one (causing problems at startup). It can happen that mr. Gates did not initialize everything properly yet (or just too early !), while in the mean time the rule "minimum value must be 1" is applied already. Now what happens is that the value of 7 is saved and should be restored, but before that has happened something else says "hey ! that's 0 in there, not allowed my boy !" and it never comes to it.

In the before version this was a hidden error, and a general message was presented instead, and I didn't even know this was a problem. So, I solved it, but not in your situation ... somehow. It may be as complicated as actually another message wanting to pop up, which causes the form to get visible (too early) while that other value is still not restored, and the form getting visible causes the internal check to fire (think like : must be, because we said the slider can be 1 for minimum, and it would visually show 0 -> wrong at this moment in time).

Now, since I already had to apply a strange solution (it was and is an MS bug from the beginning) I will apply another one. Allowing a minimum of 0 is one of the possibilities. And as you know, it is a remapping of something else anyway. So 0 actually is allowed if I only denote a picture size to it.

Thanks for all the effort !!
Peter

Uhohh, I actually can't find anything in the code about that picture size;
It can only reset to the default when you receive the message "Load previous settings" as happens after a new install;
You aren't receiving this message all the time, are you ?
Or switch versions perhaps ?

Dear bug hunter down there,

Yes, I noticed the one but last highlighted. This is since 0.9x-3 and it came with the solution of playing back a selection properly (as mentioned in the release notes). You can't have 'm all !
Haha, will try to solve it of course.

About the other thing ... Is it porno you show in there ? It might be related. Will try some myself.
Anyway, never heard of it, never seen it, but then I never touch the default. But now I think of it ... something indeed *has* changed at initialization in this area, and these sliders are treated special now in that process. Probably something wrong. Please don't look for copying it. It will be more easy to find this in the code.

As always, thanks.
Peter

Hmm ... so this may happen when you restore to the normal size ? or when you do Alt-Tab to reacivate XX perhaps ?

... which is a combination that does not exist. I think ...

Please switch on logging and post both the XX and X3 logfiles (watch the several X3 files probably existing for the one session !) when it happens again. And reconsider the error message ...

Grrr

Hi Telstar,

I did not know of these, although I know what kind of stuff can incur for it. But I really must know at what occasion(s) this happens.
I know they (usually) can't be copied at will. So if it happens again, can you please tell me what you did ?
Leaving the loggin on for a while is another idea. Might you not recognize what you did to incur for it, you can always post the most recent XX logfile (X3 logfile is not necessary).

Thanks,
Peter