Heath Stewart wrote: If you read the documentation for the property, however, it'll tell you that the initial value is always FormWindowState.Normal until the Window is shown.
So then how can I retrieve it before the window is shown? Surely the runtime must keep it somewhere so it can change the WindowState property right before showing the form. Perhaps there's a Win32 API that holds this information about a process, but I can't find it.
The runtime doesn't expose near as much as what Win32 would. Otherwise ListViews would support grouping, working areas, multiple column sorting, and filter columns. It doesn't. Forms would support drop-shadows. They don't. In these and many other cases, you have to P/Invoke code and often defines structs and enums/consts. These are wrapper classes - and early ones at that.
If you need the window state before the application window (main form) is shown in a purely .NET manner, you're sunk.
You could P/Invoke GetWindowPlacement and redefine the WINDOWPLACEMENT struct in the Windows Manager functions (see MSDN Library for this function for more information). It requires an HWND, which you can easily get from Form.Handle (inherited from Control). Something like this:
// Somewhere in your form or other class, define...
privatestaticexternbool GetWindowPlacement(IntPtr hWnd, ref WindowPlacement placement);
// Later as a nested struct or internal struct...internalstruct WindowPlacement
public POINT ptMinPosition;
public POINT ptMaxPosition;
public RECT rcNormalPosition;
// When you call the function...
WindowPlacement placement = new WindowPlacement();
placement.cbSize = Marshal.SizeOf(placement);
if (GetWindowPlacement(this.Handle, ref placement))
int nCmdShow = placement.showCmd;
// See the SW_* #defines in WinUser.h for values.
Heath Stewart wrote: The runtime doesn't expose near as much as what Win32 would. Otherwise ListViews would support grouping, working areas, multiple column sorting, and filter columns. It doesn't. Forms would support drop-shadows. They don't. In these and many other cases, you have to P/Invoke code and often defines structs and enums/consts. These are wrapper classes - and early ones at that.
What's the explanation for all these things lacking? I mean, on one hand you'd think it's because they didn't have sufficient time to include everything. While on the other, it looks like a ploy to keep our apps tied to the OS, diminishing the possibility of one day running them on other platforms.
I guess the important question is, is Microsoft planning on filling the missing pieces in future releases?
Heath Stewart wrote: You could P/Invoke GetWindowPlacement and redefine the WINDOWPLACEMENT struct in the Windows Manager functions (see MSDN Library for this function for more information). It requires an HWND, which you can easily get from Form.Handle (inherited from Control).
That did it! Thanks for taking the time to answer Heath.
Alvaro Mendez wrote: What's the explanation for all these things lacking?
Perhaps the fact that they could never wrap everything. Look at MFC - it doesn't wrap everything either. There are practically limitless possibilities and they couldn't possibly provide support for everything because there's always different ways of doing things and different reasons for using different code.
Alvaro Mendez wrote: I guess the important question is, is Microsoft planning on filling the missing pieces in future releases?
I don't know. Probably not. WinFX in Longhorn will wrap a lot of other functionality but, once again, probably not everything because it would be almost impossible to do such as I mentioned before.
The BCL includes stuff that most applications need. When you start worrying about things like Windows position or drawing a Window frame title, you're already typing an application to a particular OS because that stuff is handled different in different Windows managers like Windows, KDE, Gnome, Aqua, etc.
What, with C#? This definitely is not worth it. It requires redefining a lot of structures already defined for C++ in the Platform SDK and P/Invoking a lot of function calls. And for what? Something that's done very rarely? If nothing else, doing this in VC++ would be much faster and easier to do. Use the right tools for the right job. Now when Longhorn comes around, many of these functions and structures should already be wrapped - but for right now, you'd have to do it all and it's definitely not easy!
Just do it the old fashion way. Right-click on "My Computer", go to "Computer Name" and read the directions. In most cases, your domain administrator doesn't allow you to do this yourself so talk to your IT department.
If you're not looking to do this programmatically, you're in the wrong forum big time! This is for C# programming questions.
You could create your own class that wraps a regular array and then use the indexing property to translate your negative indexes into positive indexes in the array that you are wrapping. Something like this:
private Array myArray;
publicobject this[int i]
myArray[i+indexOffset] = value;
// You'd have to fill in the rest yourself ;)
Where indexOffset is the amount you'd have to add to your negative index to get a positive index, or to put it another way, an indexOffset of 10 would let you have an index down to -10, which would translate into the index 0 of the array you're wrapping.
You might also think about inheriting from the Array class instead of wrapping. That might actually be better.
Can't imagine why you'd need to do this though.....
Convert a STRING!!!! to a CLASS!!! I hear you scream. Pull up a pew and let me explain the problem I have.
I am creating an application that pulls various values from an XML file and then uses these values to create various pieces of text within a PDF document. Now using iTextSharp (http://itextsharp.sourceforge.net/index.html[^]) this is fairly easy.
The problem is that I want/need everything to be driven by XML parameters, as an example to set the font of a particular piece of text you would use the following code :
The Font class is also serializable, so don't forget that you can give it a serialization context and let it serialize itself (and you can bet that Microsoft will serializable about any non-default property available).
I have a picture box displaying an image. I want to be able to use 4 trackbars (one on each side) in order to draw 4 lines across the image. The end result will be to divide the image up into 9 regions graphically. I've got the image displaying, and I've got the 4 trackbars drawing the lines I want. The problem I'm running into is twofold.
1. How do I get the line to draw on top of the picture box image? Right now, the lines only appear beneath the picture box.
2. Whenever I move a trackbar slider, the line left from another trackbar is wiped out before the new one is drawn. The end result is that only one line can be displayed at a time, when I want all four to be displayed all at once.
Also... does anybody know if there's a way to change the color of the slider on the trackbar, and not just the backcolor?
as for painting the lines i think you have to override the paint event and as for drawing all at once you should use SetStyle function to the user control and modify the parameter DoubleBuffer to true and you will get good results
Did you look at the documentation for PrintDialog? Seriously - researching problems is an important development skill. If you did, the class documentation has a good example of how exactly this is done:
// Declare the PrintDocument object.private System.Drawing.Printing.PrintDocument docToPrint =
// This method will set properties on the PrintDialog object and// then display the dialog.privatevoid Button1_Click(System.Object sender,
// Allow the user to choose the page range he or she would// like to print.
PrintDialog1.AllowSomePages = true;
// Show the help button.
PrintDialog1.ShowHelp = true;
// Set the Document property to the PrintDocument for// which the PrintPage Event has been handled. To display the// dialog, either this property or the PrinterSettings property// must be set
PrintDialog1.Document = docToPrint;
DialogResult result = PrintDialog1.ShowDialog();
// If the result is OK then print the document.if (result==DialogResult.OK)
// The PrintDialog will print the document// by handling the document's PrintPage event.privatevoid document_PrintPage(object sender,
// Insert code to render the page here.// This code will be called when the control is drawn.// The following code will render a simple// message on the printed document.string text = "In document_PrintPage method.";
System.Drawing.Font printFont = new System.Drawing.Font
("Arial", 35, System.Drawing.FontStyle.Regular);
// Draw the content.
System.Drawing.Brushes.Black, 10, 10);
In order to implement events in remoting, the remoting object must NOT be "SAO-Single call"? Is this correct?
How'd you implement a chat server? Say, when a client call ChatServer.SubmitMsg(string msg) - ChatServer being remote object - ChatServer would then broadcast the message to all other client. How'd you implement or design the architecture?
I'm thinking, since it's one chatserver to many clients, it shouldn't be CAO. But it can't be SAO either. The most suitable choice would be SAO-Singleton. Since SAO-singleton is stateful, a message submitted by one client can be broadcasted to all other clients using events. ie. MsgSubmitEvent can be fired from within SubmitMsg. What do you think?
The server should be a WKO server - Singleton. It should also be thread-safe since multiple clients will be hitting the same server objects.
Look in Samples\Technologies\Remoting\Basic\RemotingEvents in your .NET Framework SDK directory. This has an example that uses a WKO server object with (a) client(s) that connects to it. This is similar to a chat application. There are also several examples of this here on CP.
So you want to instantiate and hook-up an instance for every call?! That's insane. Memory is extremely cheap and process cycles are not. 1000 users sharing one object is far better than 1000 users creating new objects I assure you! This is how most chat servers work, only they typically use raw sockets but a single application. The DirectX 9 SDK has many examples of this too, only using DirectPlay (sockets).
Having a single object also makes it easier to communicate with other connected clients. If each client connects to a separate object, that object will have to waste time persisting messages in a database (extremely inefficient and from everything I've seen - never done) and clients waste time getting it out. All current logging features are responsibilities of the client applications. They simply log what they get from the server (indirectly from the clients).
Look for the examples here on CP. They all use tried-and-true methods for chat servers and clients which are used for IRC, AIM, YM, MSN, etc.
Thanks. It make sense. Just wondering if that SAO-Singleton will become a bottom neck. You definitely don't want to launch long running method calls against the server. Broadcast message also reminds me that perhaps I should take a look at how expensive Event is.
Perhaps this may work. SAO-Singleton simply receives messages. It will pass the message to ONE (but another) SAO-Singleton on server, which will be responsible for broadcasting. Thereby, separating the listening/broadcasting stages - each handled by a different remoting object... hum...
FYI, the term is "bottleneck" - like how the neck of, say, a beer bottle gets narrower and forces larger quantities to trickle through it.
Trust me, with the proper threading, this will work. And you don't need two separate remoting objects. You really should pick up MSPress's ".NET Remoting" or Ingor Rammer's "Advanced Remoting". With a singleton, all the clients are connected to the WKO just like controls would be in the control collection of a parent control (or any collection, for that matter). The Remoting infrastructure takes care of dropping clients as they disconnect or timeout. You just need to filter the messages so that when a message is received (in the form of a struct or remotable class) you, for example, loop through the connected clients (in a collection or in a hashtable of collections or something) and send the message when appropriate. If you thread this, there won't be any problem.
Socket-based chat servers are no different. As soon as they receive a connection it spawns a new thread and passes that connection to be processed in that thread.
There are a ton of examples on the 'net (and several here on CP) that you really should take a look at. This is a basic problem that is solved almost the same way every time (sans the actual communication protocol).