Child window is being interfered when applying win API SetParent

[ermai]

I wrote one child window in vb6 "Form" object ,which is embedded into a parent window to cover some buttons by passing it's handle to "SetParent", intend to prevent user pressing the buttons. The code is as below



Private Sub Form_Load()

Locked = False
LockedFormName = InputBox("Input the Form would be locked", "Mask-0.1")
LockedProberMaskWhnd = Me.hWnd
LockedFormNameWhnd = FindWindow(vbNullString, LockedFormName)

If LockedFormNameWhnd = 0 Then

MsgBox "Not Found"
End

End If
SetParent LockedMaskWhnd, LockedFormNameWhnd

End Sub


==============================================================================

LockedMaskWhnd is the handle of the child window form , LockedFormNameWhnd is the handle of parent window got from findwindow

The child window was embedded into the parent window actually, but the graphic of the child window was interfered by the parent window ,even I have set it topmost by "SetWindowPos", as showed in the link below (the child window is in where the black rectangle frames )

https://imgur.com/a/ZqLhF

How could I keep the graphic of the child window ?

[SamOscarBrown]

There is a much 'easier' way to "prevent user pressing the buttons." Toggle their "Enable" property (Make them false). Why go to all the trouble of parent and child forms to do this task?

[ermai]

There is a much 'easier' way to "prevent user pressing the buttons." Toggle their "Enable" property (Make them false). Why go to all the trouble of parent and child forms to do this task?

Thanks for your reply!!
Because we provide application to customers for remote control in our company , but do not want customer pressing buttons that are risking our production , and the application is commercial , we do not have it's source code to modify it.

[SamOscarBrown]

I see. I didn't fully understand your problem. Sorry that I cannot help...but am sure someone can....

Sam

[dilettante]

Is it legal to have a cross-process parent/child or owner/owned window relationship?

Goes into the hazards of attempting this unstable scenario.

A customer liaison asked whether it was legal to use Set*Parent to create a parent/child relationship between windows which belong to different processes. "If I remember correctly, the documentation for Set*Parent used to contain a stern warning that it is not supported, but that remark does not appear to be present any more. I have a customer who is reparenting windows between processes, and their application is experiencing intermittent instability."


...

Yes, it is technically legal.

It is also technically legal to juggle chainsaws.

...

The existing text was probably removed when somebody pointed out that the action is technically legal (though not recommended for beginners), and instead of trying to come up with new text that describes the situation, merely removed the text that was incorrect. The problem with coming up with new text that describes the situation is that it only leads to more questions from people who want to do it in spite of the warnings. (It's one of those "if you don't already know what the consequences are, then you are not smart enough to do it correctly" things. You must first become the master of the rules before you can start breaking them.)

New Windows features like the upcoming "Sets" feature in a future Windows 10 will probably place even more explicit limitations on the use of cross-process SetParent() calls.

[dilettante]

Also:

Sharing an input queue takes what used to be asynchronous and makes it synchronous, like focus changes

Bonus reminder: If two windows are related by a parent/child relationship or owner/owned relationship, then their input queues are automatically attached. For example, if you do a SetParent where the parent and child are in different threads, you have just synchronized the two threads. This sort of cross-thread relationship is technically legal, but it is very difficult to manage correctly, so it should be avoided unless you really know what you're doing. And if you are doing cross-thread or cross-process between windows that were not designed to participate in cross-thread or cross-process parenting, you are almost certainly doomed.

[baka]

you want a program that will disable another program (not your own) remotely.
it is one thing if the program is your own, as SamOscarBrown suggested, you can disable the buttons easily,
or if the computer is located locally, its your own computer and of course you can decide what programs are active or not for the person that use it.
even so, to hostage a program that is not your own, i would not like my own programs to be used by someone else like that!

and who can stop the user from starting the application on his own?
is it even allowed (if I understand it correctly) to upload a commercial program into someone else computer and run it?
and if you want to control another person computer remotely, theres other ways. if this is to "help" the customer if theres some issues.

[ermai]

you want a program that will disable another program (not your own) remotely.
it is one thing if the program is your own, as SamOscarBrown suggested, you can disable the buttons easily,
or if the computer is located locally, its your own computer and of course you can decide what programs are active or not for the person that use it.
even so, to hostage a program that is not your own, i would not like my own programs to be used by someone else like that!

and who can stop the user from starting the application on his own?
is it even allowed (if I understand it correctly) to upload a commercial program into someone else computer and run it?
and if you want to control another person computer remotely, theres other ways. if this is to "help" the customer if theres some issues.

Thank you Baka . The program is local and customer would access the local desktop for remote(such like webex).

I found another way to do this as

"hWndForm = CreateWindowEx(0, "Mask", "MaskForm", WS_CLIPCHILDREN, ParentForm.Left + P_Left_Offset, ParentForm.Right + P_Top_Offset, P_Width, P_Height, hWndParentForm, 0, App.hInstance, ByVal 0&)"

The window created from CreateWindowEx is not interfered by it's parent window than SetParent a form object of VB6.