locked
sending API messages to client through terminal services. RRS feed

  • Question

  • Hello all,

    I need some direction.  I am brand new to developing apps for terminal services. I have a situation where I need to be able to send a message to a client system through terminal services.  My code looks something like the following...

    Private Sub pnlTitleBar_MouseDown(ByVal sender As Object, ByVal e As System.Windows.Forms.MouseEventArgs) Handles Me.MouseDown
            If (e.Button = Forms.MouseButtons.Left) Then
                Me.Capture = False
                Me.WndProc(Message.Create(ParentForm.Handle, WM_NCLBUTTONDOWN, CType(HT_CAPTION, IntPtr), IntPtr.Zero))
            End If
        End Sub


    The experienced might recognize immediately that I have developed a custom skinned application.  Obviously, I already have the referenced constants defined. I artificially fire the forms WndProc method -- passing it my own message containing the handle to the parent form (because this is a user control) and the constants to simulate a mousedown event on my form's non-client titlebar (caption) area.  

    The app runs great locally but, when I deployed this to my Terminal Services/Citrix app server,  I discovered an unexpected behavior.  The non-client elements of an app deployed over TS/Citrix are not managed server-side and streamed to the client like a form's content.  Rather, those areas (titlebar and form borders) seem to be drawn and managed by the client system.  I determined this by writing a test app that logged API messages to a listbox while the app is running.  Deployed locally, dragging the right border and thus, resizing my form width or dragging the titlebar and thus moving the form produces the expected "WM_SIZING" and "WM_MOVING" messages in the output.

    When I run the test on the TS/Citrix app server, the same expected messages don't fire.  The test form behaves the same in either case but the API message flow is different.

    What I need to do is make my "fake" WndProc method fire on the client.  I suppose that I need to acquire the handle to the remote client window, but am not sure. 

    Can anyone advise me on how to acheive my goal?
    Friday, March 14, 2008 10:43 PM

Answers

  • Jeremy Lowery,

     

    Based on your post, you are developing the application that send the message to client from terminal services. I would like to suggest you as follows:

     

    1. Client/server applications can use the Terminal Services API to enhance their functionality when running in a Terminal Services environment. The component of a client/server application that acts as a client can call the ProcessIdToSessionId function to retrieve the identifier of its Terminal Services session. The client then uses some form of interprocess communication to pass its session identifier to the server component. The client and server components can then use the session identifier to set up a private communication channel. For example, the server can use a session identifier to access objects in the session's namespace for kernel objects. For further information, please read the article below:

     

    Terminal Services Client/Server Support

     

    2. There is the tool WinStation monitor that can help you to send the message to the client. The article can help you with using this tool to monitor Terminal Services client sessions: HOW TO: Use WinStation Monitor to Monitor Terminal Services Client Sessions

     

    3. Except the tool, you can consider to PInvoke the WTSSendMessage Function in WtsApi32.dll that displays a message box on the client desktop of a specified Terminal Services session. You can try to learn the parameters usage of this function in the link below:

     

    http://msdn2.microsoft.com/en-us/library/aa383842(VS.85).aspx

     

    4. I would like to provide you an example from Terminal Services Team Blog: Writing a Desktop Sharing Application

     

    Hope that can provide you some idea.

    Tuesday, March 18, 2008 6:02 AM

All replies

  • Jeremy Lowery,

     

    Based on your post, you are developing the application that send the message to client from terminal services. I would like to suggest you as follows:

     

    1. Client/server applications can use the Terminal Services API to enhance their functionality when running in a Terminal Services environment. The component of a client/server application that acts as a client can call the ProcessIdToSessionId function to retrieve the identifier of its Terminal Services session. The client then uses some form of interprocess communication to pass its session identifier to the server component. The client and server components can then use the session identifier to set up a private communication channel. For example, the server can use a session identifier to access objects in the session's namespace for kernel objects. For further information, please read the article below:

     

    Terminal Services Client/Server Support

     

    2. There is the tool WinStation monitor that can help you to send the message to the client. The article can help you with using this tool to monitor Terminal Services client sessions: HOW TO: Use WinStation Monitor to Monitor Terminal Services Client Sessions

     

    3. Except the tool, you can consider to PInvoke the WTSSendMessage Function in WtsApi32.dll that displays a message box on the client desktop of a specified Terminal Services session. You can try to learn the parameters usage of this function in the link below:

     

    http://msdn2.microsoft.com/en-us/library/aa383842(VS.85).aspx

     

    4. I would like to provide you an example from Terminal Services Team Blog: Writing a Desktop Sharing Application

     

    Hope that can provide you some idea.

    Tuesday, March 18, 2008 6:02 AM
  •  

    Bruno,

     

    Thank you so much for your reply.  I have been temporarily re-tasked to a time-sensitive project but will research your ideas ASAP.  I am very optimistic that one of them is the answer I need.

     

    Thanks again! 

    Wednesday, March 19, 2008 2:25 PM