3.) I'm using two screens. While the preferences panel does allow me, to place a drawer on the first monitor, it always appears on the second one. Placing the drawer by using the context menu works as expected. This does not happen with docks and shelves.

1.) If the shelf (or a drawer) is placed on the top edge of the screen, it does no longer use the flipped bitmaps (WsFullBodyF, WsFullTabAF, WsFullTabIF, ...). It never used flipped symbols for settings an closing the shelf body, but the bitmaps (if provided) where used. I know, this option was hardly used by any themes ...

Ok, but it's the whole tab that takes a long time to appear, or does it appear and then the controls are SLOWLY drawn one by one?

It takes long time to appear

Even right after rebooting Windows?

after reeboot of windows its fine for some time (dont know how long exactly since my computer is mostly on for long sessions)

What Windows version are you running? Also, doesn't restarting Winstep Xtreme fix it as well? It should.

after reeboot of windows its fine for some time (dont know how long exactly since my computer is mostly on for long sessions)

This might be because of an handle/memory leak (although no fault of the application itself) I just found out about: in my new Windows 10 system (I never noticed on Windows 7, so I don't think it happened there), I noticed WorkShelf was leaking an handle every time I clicked on a tab in the Shelf.

At first I assumed it was a bug in the application itself, but after spending some time on this I eventually figured out that the leak happened on the Windows sndPlaySound API call, which is used to play the .wav based sound effects.

So, every time WorkShelf played a .wav sound (such as the one played when expanding or collapsing the Shelf or switching to a new tab) it would leak an handle, and possibly some memory too. Over time this adds up, especially because WorkShelf is a 32 bit application and is thus limited to 2GB of address space, regardless of total system memory. As available memory begins to run out, memory allocations start getting slower too, which might explain what is happening there since you keep your system up for a long time.

Since this is no fault of the application itself, I fixed it here by 'passing the buck', that is, using the SND_SYSTEM flag in that API call, which makes the system play the actual sound instead of it playing within the application's own process space. Let Windows do all the leaking, it is already leaky enough as it is. Seriously now, I don't think the leak will happen if Windows itself does the playing, so this shouldn't cause any problems.

Until the next release, try restarting Winstep Xtreme, that should fix the issue, at least for some time. Before you do and when it gets sluggish again, open the Windows Task Manager in the Details tab (assuming Windows 10) or Processes tab (assuming Windows 7) - nice going MS, good way to confuse everyone! - right click on the header and select 'Select Columns' in the context menu that pops up. Enable 'Handles', 'User Objects' and 'GDI Objects'. Also, monitor memory usage and please let me know.

If you make the change, will I still be able to access and adjust all of the Winstep volume levels in the Volume Mixer?

there is a slight delay now, nothing big yet, workshelf using 12.308 K Handles 423 user objects 458 gdi objects 340