Java application that calls Windows API methods - Programmer

This is a discussion on Java application that calls Windows API methods - Programmer ; I currently have a simple MFC C++ dialog program that uses the Windows API SendMessage() method to send a message to another third-party application (call this "Application X") and I want to recreate that program in Java. The program contains ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Java application that calls Windows API methods

  1. Java application that calls Windows API methods

    I currently have a simple MFC C++ dialog program that uses the Windows API
    SendMessage() method to send a message to another third-party application
    (call this "Application X") and I want to recreate that program in Java. The
    program contains some fairly complicated stuff that handles the
    SendMessage() calls. It also uses the WindowProc() method to handle the
    response message sent back from the Application X.

    I think I have two options to allow me to achieve my goal:

    1) Re-write the applicaton in Java and compile my C++ message handling code
    into a DLL file, then call those methods in the DLL from the Java
    application using JNI. This has the advantage that I already have the
    message handling code written in C++.

    2) Re-write the application enitrely in Java and do all the message sending
    Windows API stuff directly in Java. This may be a more stable long-term
    solution but I'm not entirely sure whether it is possible or how it is done.

    Does anyone have any opinions on how I should go ahead and do this? Should I
    use option 1 or 2? Or any other approach I should consider? Any recommended
    reading material on this area?

    One other thing that concerns me is the WindowProc() method - does this work
    in a DLL (i.e. how do Windows DLLs send messages to and receive messages
    from other applications?)?

    Thanks in advance.



  2. Re: Java application that calls Windows API methods

    * Si:
    > I currently have a simple MFC C++ dialog program that uses the Windows API
    > SendMessage() method to send a message to another third-party application
    > (call this "Application X")


    It's generally not a good idea to send window messages across process
    boundaries. Instead consider using a mailslot, a COM object, even raw
    RPC, a socket, or in the other direction, SOAP, or whatever. I'd use a
    mailslot or, if more complicated data than simple text is required, a
    COM object, since that's simple and efficient within a single machine.


    > and I want to recreate that program in Java. The
    > program contains some fairly complicated stuff that handles the
    > SendMessage() calls. It also uses the WindowProc() method to handle the
    > response message sent back from the Application X.


    A response message? Then a COM object seems to be indicated, that takes
    care of synchronization and marshaling, almost automatically. I.e.,
    make that "Application X" a COM object server.


    > I think I have two options to allow me to achieve my goal:
    >
    > 1) Re-write the applicaton in Java and compile my C++ message handling code
    > into a DLL file, then call those methods in the DLL from the Java
    > application using JNI. This has the advantage that I already have the
    > message handling code written in C++.


    Yes, you can do that.


    > 2) Re-write the application enitrely in Java and do all the message sending
    > Windows API stuff directly in Java. This may be a more stable long-term
    > solution but I'm not entirely sure whether it is possible or how it is done.


    AFAIK it's not possible with Sun's Java, and the days of Microsofts
    what-was-it-called version of Java is over. But you can use a COM
    bridge (more commonly called an ActiveX bridge) to use a COM object from
    Java. Only note that at least as of a few years ago, Sun's ActiveX
    bridge had lots of bugs and a tendency to eat memory.


    > Does anyone have any opinions on how I should go ahead and do this? Should I
    > use option 1 or 2? Or any other approach I should consider? Any recommended
    > reading material on this area?


    COM object. See above. Or, use one of the other solutions mentioned above.


    > One other thing that concerns me is the WindowProc() method - does this work
    > in a DLL (i.e. how do Windows DLLs send messages to and receive messages
    > from other applications?)?


    A DLL simply becomes part of the program it's loaded in; it's no
    different from other code in that program, except for initialization and
    uninitialization, which can be somewhat difficult to do correctly.

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?

  3. Re: Java application that calls Windows API methods

    "Alf P. Steinbach" wrote in message
    news:45rul3F874qsU1@individual.net...
    >* Si:
    >> I currently have a simple MFC C++ dialog program that uses the Windows
    >> API SendMessage() method to send a message to another third-party
    >> application (call this "Application X")

    >
    > It's generally not a good idea to send window messages across process
    > boundaries. Instead consider using a mailslot, a COM object, even raw
    > RPC, a socket, or in the other direction, SOAP, or whatever. I'd use a
    > mailslot or, if more complicated data than simple text is required, a COM
    > object, since that's simple and efficient within a single machine.


    Unfortunately I *have* to communicate with Application X using SendMessage()
    as it provides a text-based API which uses this method.

    >> and I want to recreate that program in Java. The program contains some
    >> fairly complicated stuff that handles the SendMessage() calls. It also
    >> uses the WindowProc() method to handle the response message sent back
    >> from the Application X.

    >
    > A response message? Then a COM object seems to be indicated, that takes
    > care of synchronization and marshaling, almost automatically. I.e., make
    > that "Application X" a COM object server.


    Sorry I don't know what you mean here. I can't make any changes to App X at
    all.

    >> I think I have two options to allow me to achieve my goal:
    >>
    >> 1) Re-write the applicaton in Java and compile my C++ message handling
    >> code into a DLL file, then call those methods in the DLL from the Java
    >> application using JNI. This has the advantage that I already have the
    >> message handling code written in C++.

    >
    > Yes, you can do that.


    .... and SendMessage() and WindowProc() will both work correctly to send
    messages to and from the DLL to App X?

    >> 2) Re-write the application enitrely in Java and do all the message
    >> sending Windows API stuff directly in Java. This may be a more stable
    >> long-term solution but I'm not entirely sure whether it is possible or
    >> how it is done.

    >
    > AFAIK it's not possible with Sun's Java, and the days of Microsofts
    > what-was-it-called version of Java is over. But you can use a COM bridge
    > (more commonly called an ActiveX bridge) to use a COM object from Java.
    > Only note that at least as of a few years ago, Sun's ActiveX bridge had
    > lots of bugs and a tendency to eat memory.
    >
    >
    >> Does anyone have any opinions on how I should go ahead and do this?
    >> Should I use option 1 or 2? Or any other approach I should consider? Any
    >> recommended reading material on this area?

    >
    > COM object. See above. Or, use one of the other solutions mentioned
    > above.


    What advantage would creating a COM object have over writing a DLL and
    loading it in my Java program? Can I use my existing C++ code with the COM
    object? What is the difference between a COM object and a DLL?

    >> One other thing that concerns me is the WindowProc() method - does this
    >> work in a DLL (i.e. how do Windows DLLs send messages to and receive
    >> messages from other applications?)?

    >
    > A DLL simply becomes part of the program it's loaded in; it's no different
    > from other code in that program, except for initialization and
    > uninitialization, which can be somewhat difficult to do correctly.


    In this case the DLL will be part of javaw.exe and will function correctly
    within that I presume...

    Thanks for the suggestions.



  4. Re: Java application that calls Windows API methods

    * Si:
    > * Alf P. Steinbach:
    >> [snip]

    >
    > Unfortunately I *have* to communicate with Application X using SendMessage()
    > as it provides a text-based API which uses this method.


    Ah, "third-party". Sorry I didn't notice.


    [snip]
    >>> I think I have two options to allow me to achieve my goal:
    >>>
    >>> 1) Re-write the applicaton in Java and compile my C++ message handling
    >>> code into a DLL file, then call those methods in the DLL from the Java
    >>> application using JNI. This has the advantage that I already have the
    >>> message handling code written in C++.

    >>
    >> Yes, you can do that.

    >
    > ... and SendMessage() and WindowProc() will both work correctly to send
    > messages to and from the DLL to App X?


    SendMessage will, certainly. As for WindowProc, that's presumably your
    own window procedure (there's no Windows API function called
    WindowProc). Now that's a different kettle of fish altogether, because
    a window procedure is called for messages to the window it's serving.

    If you have the option of informing Application X which window handle it
    should send its responses back to, then the simplest is probably to
    create an invisible receiver window in the DLL code, but I haven't done
    that: it's possible that you'll end up with some thread issue (the
    window needs to be created on a thread with a message loop).

    Otherwise you may have to intercept window messages for the Java-side
    main window, and that's a bit complicated, but as I recall Sun has a
    special JNI-thing called someting-AWT or AWT-something (that's not the
    AWT but a JNI binding for AWT) that would help, and otherwise, but you'd
    probably not ask here if you knew that, you can subclass the Java main
    window from the C++ code. On second thoughts, that's probably the
    simplest. _If_ you have have to use the application's main window.


    [snip]
    > What advantage would creating a COM object have over writing a DLL and
    > loading it in my Java program?


    As long you _have_ to send and receive window messages using a third
    party protocol, not much. It can free you from synchronization issues,
    but that can also be done very simply in Java code. Please just forget
    that I mentioned COM -- I didn't see that you have the constraint of
    absolutely having to use window messages.


    > Can I use my existing C++ code with the COM object?


    Probably, but that's impossible to know.


    > What is the difference between a COM object and a DLL?


    A DLL is a library of functions and variables used directly by your
    program. A COM object is a collection of functions (grouped into
    intefaces), that operate on a state you cannot access directly. A COM
    object can be implemented in terms of a DLL, or as an EXE, but from the
    client code point of view you don't need to know how it's implemented;
    you use it the same way anyhow. The COM infrastructure takes care of
    marshaling your calls across process boundaries, and even across machine
    boundaries (over the network), if necessary.

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?

  5. Re: Java application that calls Windows API methods

    "Alf P. Steinbach" wrote in message
    news:45s3i4F89q7vU1@individual.net...


    Thanks Alf.



+ Reply to Thread