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.
You can't modify attributes at runtime. You can, however, use an ICustomTypeDescriptor to return an array of attributes that you can create at runtime (note, this interface is only used by certain classes like the TypeDescriptor in System.ComponentModel).
See the documentation for ICustomTypeDescriptor.GetAttributes for more information.
If you use reflection instead of a TypeDescriptor to get attributes, you won't be able to change anything unless you programmatically create an attribute and add it to your array/list/collection.
Finally, if this is a custom attribute, you can give the attribute's property a set accessor as well, but this is to change only a property. This is highly NOT recommend, though, because attributes are meta-data that describe classes, etc. The attributes in the base class library don't allow such changes. If you need to modify values like this, you should consider a abstract or virtual property for a particular type that child classes can override, or using an interface for a good polymorphic design.
Yes, besides being a great music it's the situation I'm in right now.
I've searched and searched and I cannot find what I want, I'm starting to think that it's not possible.
I've developed a service using C#, and used one of the great advantages of .NET, the possibility to easily install a service, I've done everything I wanted, except for this:
Is it possible to set the name of the service during installation?
I must/want to give this option so that the user can install several instances of that service each with a different name. (Gateway I,Gateway II, etc).
See ServiceInstaller and ServiceProcessInstaller. The documentation for these two classes in the .NET Framework SDK also include samples.
Basically, you derive from Installer to create your own installer then add an instance of each of the aforementioned classes according to the documentation.
You can use the installutil.exe utility that is installed with the .NET Framework or include the assembly that includes the installer class in a Windows Installer setup project in VS.NET as a Custom Action.
If you want to set anything during installation, you'll have to use a command-line switch. You can find more information about this in the documentation for the Installer.Context property. You use some code like the following in your derived Installer class to get parameters passed to it from installutil.exe or from Windows Installer:
The first thing is to understand that the ListView class in .NET encapsulates the List-View common control in Windows, as do most controls in the System.Windows.Forms namespace, so doing things like this will typically required that you extend ListView, override WndProc, and handle notification messages. Some Windows programming background will be helpful. You'll also want to know how to P/Invoke native methods. You can find more information in the documentation for the DllImportAttribute in the .NET Framework SDK.
You'll have to handle the drawing of each subitem by handling the NM_CUSTOMDRAW notification message. That will give you a struct (which you'll have to create, namely the NMLVCUSTOMDRAW struct). From information in that you can adjust the starting location of your text (though you'll have to draw it yourself, though that's not hard) and then paint the icon you want next to it. You'll have to figure out how to store that image information, though, be it an index into an ImageList or an Image itself. You could extend ListViewSubItem although you'll have to worry about casting each time.
Note that this may sound like a lot of work (and I'll admit it's not trivial) but it sure beats making your own list view control from scratch! There's a heck of a lot more to worry about than this. In the grand scheme of things, this approach is easy.
If you reply to this, I can send you some old source that shows some examples of owner-drawing. Though not specific to your requirements, it should give you some insight.