Hello Innovasys-Team,

I have a REALY BIG Problem with DockStudio 2.x.

It steals in many situations the focus from other forms and applications.

Best to see this bug is, if you use a OLE-Object in the application.

BUT I've find out, that the bug occurs ONLY, if I use "DockWindows" (!!!)

If you dont use any "DockWindows" in the project, everything is OK!

For a better understanding, please see the sample-video AND sample-code:

http://www.file-upload.net/download-1534139/Dockstudio_FocusStealerBug.zip.html

...in this Example Microsoft Word is used in OLE-Container and it is absolutly unuseable, if "DockWindows" are used (Sample-Button #2)!

 PLEASE HELP, it is very urgent, because I can't continue develop my project!

Do you have a sample that reproduces this problem without Word or some other container (i.e. just DockStudioXP)? We would need that to confirm this issue is a DockStudioXP issue and not an issue with the way the OLE object you are embedding handles focus.

This bug occurs WITH ALL Applications, like Adobe Reader, Excel, Paint and many many more...

And yes, this bug will also occurs without the VB-OLE-Container - BUT unfortunately not so easy to replicable - realy heavy to catch it!

That's why I sent you a sample with OLE-Container (because there will this bug ALWAYS and ANYTIME occurs!)

In my own appliaction I don't use the MS-OLE-Container. I use a selfmade OCX - and firstly I was thinking it is my wrong...
...but after many many tests I was able to enclose the realy reason!

In another application I use a Dock-container-control from CodeJock - and there is everything all right - no Bug, no problems...

Hope that'll help you!

Two tips which helps you to solve the problem (maybe): Use "DocumentWindows" instead of "DockWindows" and you will see also, DockStudioXP works well...

...OR use  "DockWindows" BUT as "Flying Windows" - and the bug is also absent >>> Change in "Form3/DockStudio1" the property "DockState=Floating" and restart the sample!!!

Very strange!

In this Video U can good see, if the "DockWindow" is floating, everything is OK ...there is NO BUG!!!

BUT if I activate it, the bug is present - and if I dock it now to Dockstudio the bug is again absent. But after some clicks the bug is back again...

We would need a sample project that does not involve a third part embedded Ole Object, together with step by step instructions in order to investigate this issue for you. If you can put together such a project, please email it to support@innovasys.com so that we can have our developers investigate.

Embedded ole objects frequently have unexpected focus behaviors that are outside the domain of DockStudioXP to change - I suspect that this is the case here.

Do I understand you right? You dont want to help me and do not kill this bug because I have no better sample for you?

PLEASE look to at the second video and you will see that a OLE-object IS NOT the problem!!!

I see that you not download it, so please download it: http://www.file-upload.net/download-1534272/DockStudio_FocusBug2.exe.html

And dont forget, this problems occurs only with dockstudioXP (AND only if I use "DockWindows" in my project and only if they are not floating!) not with other Docking-Control like from CodeJock or Infragistics.

So PLEASE dont let me alone and help me!

I do want to assist, but we will need a sample project in order for our developers to investigate this issue in a meaningful way. Please forward the sample to support@innovasys.com and we will get this tracked as a support issue (these are peer to peer forums) have our developers take a look.

The video is probably going to be useful background information to accompany the sample, but I wasn't able to download it as our security restrictions here prevent running executables from unknown sources. Can you send that along with your sample as a movie file?

OK, I have sent you another sample to your support-mail.

I have spend many hours (more than 5 hours!) to catch this bug.

The bug occurs also unboundedly, if the user press <Ctrl>+<Tab> to switch to another application - but remember: not always and of course "without" any OLE-controls inside the application!

It is realy realy difficult to reproduce this bug because I DON'T KNOW your sourcecode! So PLEASE look inside your code and check the situations with and without "Dockstate=Floating" - and with DocumentWindows instead of DockWindows-elements.

OK, I was found another situation, where your control steals the focus. It was already documented by me, here in your board. So please follow this Link: http://www.innovasys.com/cs/forums/p/187/476.aspx#476

In this one, DockstudioXP will always bring herself to Windows-TOPMOST and catch the Windows-Taskbar-contextmenu to focus hereself! You see this likes a similar problem (*WITHOUT ANY third part embedded Ole Object*).

Hope it will help you!

Important Information for you!

This bug occurs only in DockStudioXP 2.x.

I have testet exactly the same code with DockstudioXP 1.5 Trial on a virtual-pc and it will works absolutly BUGFREE with "DockWindows" !!!

So the fact is, this bug is since DockStudioXP 2!!! So please compare your code with DockStudio 1.5

BTW: I use Version  2.1.2.0159.

 I apologise for the delay with this reply.

This issue is being handled through our support channel, you should have recieved a reply today.

Thank you, but the only answer by mail was this:

I apologise for the delay with this reply.I have so far been unable to reproduce this issue using the sample you have provided, unfortunately without a repro that doesn’t involve a complex embedded application with its own particular focus handling we are not going to be able to find a solution to this issue.

We understand that this issue is frustrating but without a solid reproduceable scenario at this end that identifies a defect in DockStudioXP there is very little chance of a hotfix

...This will not realy help me. Fact is, that this bug occurs only in DockStudioXP 2 and also fact is, that I do not know your sourcecode. I feel me realy helpless and hope (wish) your support dont leave me alone...

I have so far been unable to reproduce this issue Normal 0 21 false false false DE X-NONE X-NONE MicrosoftInternetExplorer4

I can reproduce this issue on all customer PC's - realy all!

 Any News? Do you still look for a bugfix?