Good catch, Peter.

I see it.
In the meantime, drag and drop into the main preview panel. It will accept dragged images there.
I don't know how many in your queue, but once you have 6 in the queue, then scroll bars appear in the queue list.
Then you can drag and drop as before.
I know, it's a bother, but it should be easy to fix... (I hope)

I'm sure you know that you can replace images that way too, by dropping them on top of the one you don't want, and you can adjust the order of prints using the arrow keys.
Wont be long to wait.

Thanks, Peter.
Fred

That's interesting.
I can repeat it here at will using any image.
It looks like there's not enough room in that filename box until I put 6 images in there, Then scroll bars appear, and it works.
Are you checking with images before there are 6 in there?

Fred

Peter,
The drag and drop is always active for dragging into the upper preview panel.
The lower file name list was mainly for deleting and replacing by dropping a new file on top of an old one.
The upper preview screen gets used for Drag and Drop a lot, especially with multiple images and placement in Freehand mode.

It's time to reboot your computer or at least reboot Qimage.

Fred

Furthermore:

I managed to find a complete set of recent QI U releases.

The last version that drag and drop works properly is 2014.118

Hope that helps identify the problem.

Peter

Thanks Fred.

Have sent the email.

The network is actually a virtual one between the Win 7 virtual machine and Mac OS X host and speed has never been a problem in this manner. Have used it this way successfully for a number of years.

In summary what I'm doing is open post v118 QI with "network" image thumbnails in left pane. Try to drag image to blank page preview. Or if click "+" to add image to page, try dragging another thumbnail onto the previous image in the queue list to replace it.

Hope this helps resolve the problem.

Mike fixed a sudden occurrence of slow network related response a few months ago. Has this fix reverted in recent releases?

Regards

Peter

   

 

Thanks for the video Fred. It was very helpful.

The error that you demonstrated in the video is not the one I am reporting! However I can repeat your error on v118.

My error, only with QI releases post v118,  is that the thumbnails of images stored on my network are not "picked up" by dragging. Local images can be dragged.

For the network based  images, the cursor does not change to the stop symbol while still over the thumbnail pane and the symbol does not change to a page when dropping is possible.

Regards

Peter

Thanks Terry and Fred.

The ongoing saga.

Following Terry's report that drag-and-drop from his NAS drive works I decided to check my drag-and-drop action for images on my real network and not the "virtual" network that I have been referring to.

The tests described below were all with version 122 of QI.

Drag-and-drop of images residing on the real network worked okay, allowing for the relatively slow speed of my Wi-Fi connection.

All of the images that I have had problems dragging and dropping on my virtual network are all moderate to large tiffs (which are used for printing). I decided to check another folder on the virtual network which contained mostly original raw NEF files. To my surprise the drag-and-drop worked.

I then investigated my host machine, a Mac. I checked its hard drive for errors and also confirmed all of the permissions of the files and folders. No problems there.

I then again loaded the Windows 7 virtual machine and ran QIU. I turned off the lightning thumbnail cache and cleared all thumbnail caches. I then regenerated all the thumbnails in the "problem" tiff file folder and then tested the drag-and-drop action. It worked, but only if I dragged about a centimetre (still in thumbnail pane) and held, waited for about a second until the "stop" cursor symbol appeared. Then I could continue to drag and drop the image onto the page or onto the queue list.


It seems that this lag in detecting that a drag and drop action is required is only associated with the tiffs.

Also, this only occurs in versions after release 118.

Maybe some code development that has occurred since version 118 or an updated module that QIU uses are causing the problem, at least on my machine!

Regards

Peter