I need to get a Java application to communicate with a C# apps. What're the possible ways of doing that? References/Url would be nice. Just want to add that I'm new to Java, and been coding Windows code for the most part of my life. So, please keep in simple and treat me tender.
Depends what you want to communicate but XML would be a good way if you want to do it file/db based. Another would be some sort of Socket based communication not sure how it would go between C# and Java.
If you want to actually host .NET controls in a Java application see my article, Embedding .NET Controls in Java[^]. There are also commercial libraries available such as JAWIN and Ja.NET that generate the necessary classes at runtime.
As for one of your other questions, I suppose you could use IPC but you're going to spend a lot of time just P/Invoking the necessary functions, creating any structs, etc. The articles I mentioned should provide alternatives that can possibly decrease development time and - in some cases - use standard protocols to communicate between the two.
To make a menu transparent, you can use Menu.Handle to get an HWND for the popup window that represents that menu and use the native function SetLayeredWindowAttributes (you'll have to P/Invoke it). To draw the menu without a border, you'll have to handle the MenuItem.DrawItem event and do all the drawing yourself.
You can find several examples here on CodeProject using a search like menu draw[^] or similar. Dr. Gui on MSDN[^] also had a good example some time back at http://msdn.microsoft.com/library/en-us/dnaskdr/html/askgui11062001.asp[^]. The example's in VB.NET but it's mostly method calls (remember, the base class library - or any assembly for that matter - is available to all languages that target the CLR, or ".NET languages", in the same way; though, the syntax for making those calls may be different).
Thanks for the advice. I found several articles on CodeProject. To make it borderless they have used subclassing. It's a war out there. Some of them have used hooks, and some of them are against using hooks
By the way I went to geekcode.com, and now I know what's that first three letters mean
You may stop this individual, but you can't stop us all... after all, we're all alike. +++Mentor+++
When the scroll box is not scrolled adding panels puts each one directly below the next as I want. But if the parent is scrolled down then the position is wrong (the new panel is added too low down) by an offset.
I thought the answer would be in the AutoScrollPosition property but I haven't been succesful in making it work.
If you look at the documentation for the AutoScrollPosition property, it states that negative values are returned for the X and Y properties of the Point returned from the property if a user has scrolled away from the starting position (0,0). Make sure you negate these values before factoring them into your new position for child panels.
As Jinwah was getting at, see the System.Data.DataSet class documentation in the .NET Framework SDK, as well as System.Data.Common.DbDataAdapter - specifically, one of its derived classes depending on what database you're accessing (like System.Data.SqlClient.SqlDataAdapter for a SQL Server database).
You give the DbDataAdapter the appropriate SELECT, INSERT, UPDATE, and DELETE commands (it has properties for each), which you can either use the DataAdapter designer in VS.NET or a CommandBuilder to generate, or type them yourself but generating an example to get an idea might be a good idea.
Then, whenever you update, remove, or insert information in the DataSet, you call DbDataAdapter.Update(DataSet) which will use the change type information for each DataRow and will call the appropriate DbCommand on the DbDataAdapter. There are several examples of this on the CodeProject web site, as well as examples in the .NET Framework SDK.
addEmp.ExecuteNonQuery throws an exception witht he message:
"You must define @Document"
I copied the code almost directly from MSDN, but I can't get it to work...Any ideas ?
Oh and in my AutoConvert Catalog I have the table Documents with an image field of length 16 called Document.
First of all, if you're connecting to a SQL Server, you should be using the class in System.Data.SqlClient. These classes - including the SqlParameter (as opposed to OleDbParameter) are optimized for SQL Server.
Finally, you must define the type of your SqlParameter like so:
You can use the System.Data.OleDb classes to access SQL Server, but they are not optimized for any one database - they just use the OLE DB driver using only the common abstract implementations. As far as mixing these two collections of classes together, that's not really supported because most methods in the derived classes take specific types indicitive of their namespace (like a SqlCommand can take a SqlConnection, not a generic DbConnection).
A solution that I'm developing has a server and multiple clients. The clients access Client-Activated object on the remoting server. What would be the best way of keeping track of the connections?
I have a SQL server on the same machine and I'm thinking about doing it like this: on init - add an entry in the connection table. when the object is disposed it will remove itself from the table. However, there are a few problems.
+ if the client crashes -> when the lease runs out the connection will be unregistered. right?
+ What about if the server crashes - I'll just clean up the connection table on startup.
Your SQL-Server solution works, but there is an easier way to tracking your clients (I think):
Create an ArrayList and add each ClientObject by creation.
Use delegates to remove ClientObjects, when there lease is running out.
If the server crashes, the ArrayList will be removed automatically
Actually, this is not so good but your solution to use a lease is what I was going to recommend anyway. I originally recommend using a database as we do for our app (which is driven by a SQL Server anyway) because if your remoting object goes down for some reason, your list is lost. The database (in our case, which is replicated and stored on a RAID array) will persist this information so that when the remoting object comes back up, it can grab the information and return to its original state.
As I hinted at before, implement ILease and return that in an override for GetLifetimeService on your remoting object. If a sponser cannot be contacted or has not renewed the time on the lease, you remove the row from the RDBMS for that sponsor (a client). In an internal remoting application, your lease can ping the sponsers to determine if they still exist. If you expose your remoting object on IIS (which automatically gets exposed as a Web Service, thus using HTTP which is one-way), you'll just have to wait until the sponsor does not renew their lease and remove the row.
If the remoting object (the server) crashes, this really isn't a problem. As long as the database is still up and running, the remoting object will grab the existing information (this is the reason I mentioned you should persist connection information in a database or something) and restore its state. Clients can't really connect why the remoting object is down, so you don't have to worry about new information. Now if the server(s) that has/have both your remoting object and the database go down, the scenario isn't much different from before. Just use transacted statements to increment and decrements your client connections table and they will be logged so that they can be completed in such a case.
Actually, this is for a different but similar project.
I had everything covered the only thing was : If the activated object crashes and the client app never decides to re-activate the object. The information will remain on the server, and the admin app on the server will read the entry in the database as a live connection.
That would be a problem, then. I guess the only thing you could do in such a case is to prevent the admin application from worrying about what's in that table and instead get the remoting object and this admin app to interact instead of using a table as a sort of intermediary.