Quick View for Universal Viewer v1.0 beta2

[majkinetor !]

And what is your proof ?

[Alextp]

You cannot tell plugin that it must draw "not to real DC" but "to memory". At last, I cannot, maybe you can?- if so, please tell us (me and my moggy) about how to do this hack.

[majkinetor !]

First, you got wrong impression that hacks are something bad.
They are not.
U know how to do things or you don't know, that is only in question.

HWND __stdcall ListLoad(HWND ParentWin,char* FileToLoad,int ShowFlags);

This is only mandatory function in lister API. The plugin obtains the DC using GetDC(ParentWin).

This means that you must create hidden window off the screen, load plugin into it, and use BitBlt after operation is completed to your visible window. I am not sure if this will work, but I think it should. Its easy to try it anyway.

[Alextp]

This means that you must create hidden window off the screen, load plugin into it, and use BitBlt after operation is completed to your visible window.

This will draw plugin screen 1 time. When events occur, we need to copy hidden window again, right? On every event! So we need to go into plugin message loop. What messages to catch there? What will happen with owner-draw plugins windows? Will this be stable and fast? What to do if plugin requires not fake hidden window but normal window in which it modifies Main Menu? What if plugin creates some ActiveX?... Do you suppose I should debug all this by myself?

[majkinetor !]

what about using the same dc, and issuing a fake image over main window while you load next ?

[Alextp]

what about using the same dc, and issuing a fake image over main window while you load next ?

http://ghisler.ch/board/viewtopic.php?p=98930#98930

First, you got wrong impression that hacks are something bad.
They are not.
U know how to do things or you don't know, that is only in question.

The debug and compatability is the second question...

[majkinetor !]

I'm not sure this hack will work Ok: even if I display a bitmap, new loaded plugin will draw over it and this gives flicker. If I make bitmap topmost, then it will pop to the top of other topmost windows. It's ugly hack.

New plugin will NOT draw over it as you will create new window on top of it. If you make bitmap topmost, it will NOT pop to the top of other topmost windows as you should make this happen in your application, that is you should change the Z-order of controls inside AT viewer.

For instance if you make Panel1 contains ATViewer control and Panel2, you can save current image at Panel2, show it on top ATViewer, load the file, and hide the panel2. To do this add both controls to Panel1, set Panel2 to be hidden, and set its alligment to client. On load, create the image, set Panel2.visible to true, set ATViewer.visible to false, load, and return all back. As an option ofcourse.

[Alextp]

Maybe you're right. Need to test this to make sure.

[Alextp]

I want to suggest Ghisler that he try to implement this in Lister first. If in Lister it will be ok, then I may do the same. What if he prefers new API func. instead?

[majkinetor !]

Alex, both you and me know that Ghisler is not easy on suggestion. He refused to do changes even when we had large support for requests on this forum. Its not wise to count on that, but you may try to influence him. CHanging the API is of course good. Incoming TC 7 is shurely good place to change it (as new developers will certanly come), you may go into that direction.

I doubt Ghisler will do imagining. I think that he don't understand this as an important issue. I think you can try it alone, its not hard at all. If you need any help saving image, let me know.

[Alextp]

BTW. Now there is no flicker at all in internal image viewer and QV script. So this work may be not needed at all: I just suggest users to use internal image viewer, i.e. temporary turn OFF Viewer option "Plugins have higher priority"...

Edit
Oops, there is flicker a little. Little more than with "Next file/Prev file" commands (confused)

[majkinetor !]

Did you try to put some nice word to the Ghsiler about changing the api ? That is not "changing" but "updating" so all old plugins can work without changes.

You really care about qv script, don't you ?
I am not sure why as I doubt you use it.

Anyway, if nothing else, I will do it for you and me
Just some patience, I am currently creating new toy that fascinates me from Linux world for some time (Conky)

[icfu]

I use it, as you can see here:
http://ghisler.ch/board/viewtopic.php?t=12306

So, if you ever plan to make it work for mouse presses, do it optional please.

By the way, have you thought about redirecting the usual shortcuts 1-8 to Universal Viewer? Would that easily be possible with your script, to be able to switch views and plugins?

Icfu

[Alextp]

Did you try to put some nice word to the Ghsiler about changing the api ? That is not "changing" but "updating" so all old plugins can work without changes.

Yes, there was a suggestion and you should remember that thread where Ghisler suggested temporary bitmap.

You really care about qv script, don't you ?
I am not sure why as I doubt you use it.

I care a little about script, more care about UV and plugins API...

me from Linux world for some time (Conky)

Fancy name

[majkinetor !]

So, if you ever plan to make it work for mouse presses, do it optional please

I really thought about this originaly, but for some reason I didn't implement this and you took advantage of it

Don't worry, when I come back to this scirpt I'll see not to change this behavior or make it optional.

2 Alextp

I care a little about script, more care about UV and plugins API...

So, all your questioning is out of .... curiosity ?

I prefer feedback from people who use it, so to know how much time to invest in this...