|
This is common practice. Good applications are written by good developers who don't need graphical agents. I rarely use the forms designer - especially when working with localized applications - because the designer assumes far too much and likes to initialize everything up front.
As a good example, try designing a simple test form. Set the Localized property in the prop grid to true, and watch the designer add every localizable property to your .cs and .resx files...and the size of your assembly double! Now try removing some of those and moving the ResourceManager instance off into the class as a private field or something to reuse elsewhere in the class...and watch the designer complain and break!
The most important thing to remember is that the designer doesn't use magic - everything you do in the designer is either serialized as code in the source file or is added to the ResX files (like images in an ImageList, which are simply base64-encoded).
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
Can you recommend any ways to learn this form of windows form programming? All the books I have or seen use the designer to make programs.
Thanks in advance
xarx
|
|
|
|
|
Forget the books - the best education is trial and experience. Read through the .NET Framework SDK. Scan the namespaces and the classes contained within. Start trying things. If you've just been using the designer and have never looked at the code - you're lost. The concepts are simple - you have a form. Instantiate it, put some controls on it, and show it. The biggest mistake so many people make is that they don't read the documentation. What do you think the books are written from? The documentation, trial, and experience. Don't waste the money.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
The first thing I catch when reading posts like these is the "I'm better than you 'cause I do it all in code" hard-ass attitude. What a bunch of bunk. If a tool is there and increases your productivity, use it.
Don't fall into that programmer elitism bull sh*t. Productivity takes first place to optimizing the assembly size hands down.
The graveyards are filled with indispensible men.
|
|
|
|
|
I have a TextBox on a Form and I want to implement autoscroll on the TextBox...any ideas of how to do that?
Thanks,
mweiss
|
|
|
|
|
I've spent some time looking around for wrapper classes etc which will enable me to build an MP3 player w/ .NET
For VS 6.0 there are plenty of controls out there to do this .. However, I have not been able to find any controls, dlls etc etc that will do this for .NET ..
I did try using the MM control(Interop) and it the MP3 didn't sound right.
What gives ?? Does anyone know of any good components for MP3 ?
|
|
|
|
|
|
|
|
Thread.Sleep(XX);
This is the simplest solution to making your thread pause. Unless you are required to have 100% time accuracy I don't see it worth your time to invest in alternatives.
Progress Bar delays:
This is common. There is alot that goes on in your application when you update the GUI. Even if they are in different threads it has to pause find the proper method to send data via and send the data. If there isn't many things going on this normally isn't visible however, when you are doing hundreds of thousands of microsecond loops those tiny delays do add up. Could you speed it up? Possibly but then again it is up to how much time you want to commit to it.
A simple quick fix for process bars updates is to only send update calls every X loops. Sometimes helps, sometimes hurts. Consider it the poor mans fix.
|
|
|
|
|
nice progress bar tip. i'll try it out.
thanks.
/\ |_ E X E GG
|
|
|
|
|
Hi,
I have a strange behavior when using an installer class to register a com+ server (Using the RegistrationHelper class). When the installer perform a new install there is no problem, the behavior appear when doing an upgrade, the old version is registered, not the new one (the Installer package is configured to remove the previous version before reinstalling a new one. "RemovePrevious Version=True").
Here is the symptom :
When installing a new version of the com+ server, the installer class first uninstall the previous version, remove the files and copy the new ones.
then, the following procedure is run :
public override void Install(System.Collections.IDictionary stateSaver)<br />
{<br />
base.Install(stateSaver);<br />
<br />
string appID = null;<br />
string typeLib = null;<br />
string assembly = GetType().Assembly.Location;<br />
<br />
RegistrationHelper regHelper = new RegistrationHelper ();<br />
regHelper.InstallAssembly (assembly, ref appID, ref typeLib,<br />
InstallationFlags.FindOrCreateTargetApplication);<br />
<br />
stateSaver.Add ("AppID", appID);<br />
stateSaver.Add ("Assembly", assembly);<br />
}
Theoritically the new com+ server must be reinstalled.
BUT, the version registered is the previous...
Because of that, the server can't provide com object access because of a mismatch in assembly effective version and declared version in registry.
I don't understand why because the assembly property refer to the new assembly with the correct version number !!!
Does anyone have an explanation for this problem or it is a bug ?
Pietro
|
|
|
|
|
Well, InstallationFlags.FindOrCreateTargetApplication tells the reg helper to install a previous version first - the installer is clearly not removing the previous version.
Look in your Add/Remove Programs control panel. Do you see two entries for your product there?
First, always make sure to NEVER change the UpgradeCode. Simply changing the installer version will prompt you to change the ProductCode and PackageCode (which is appropriate for Windows Installer, someting I've consulted on for several years).
The problem is that VS.NET's installer project sucks! It does almost everything wrong. If you choose to install the previous application on a per-machine basis (the default is per-user), the new install (remember, having the default set to per-user) won't see the prevoius version! This is because the Upgrade table is handled wrong.
If this is indeed causing the problems you are experiencing, you'll have to download the Platform SDK from MSDN for the Windows Installer SDK (the core is required). In that, there's an installer for a utility called Orca. Install that, open your .msi file and find the Property table. Add the property ALLUSERS with the value 1.
The VS.NET installer is also stupid because you can't do this before compiling the package (or much of anything else, for that matter).
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
Thank you for your answer,
looking in add/remove program show only one entrie after an upgrade, and as it was recommended, i never changed the upgrade code.
I don't think it is an upgrade detection problem. When I look at what is appening during the upgrade process, uninstall of the previous com+ application and deletion of previous file version occur correctly !
Finally, to workaround the problem, I have created a custom action wich call Regsvc.exe to make the registration. (It's not very nice looking but it works !)
Pietro
|
|
|
|
|
I've written a very small remoting app, a server that exposes one method from a dll, and a client that connects and calls that method. Most of the time this works fine. But if the client crashes, and I restart it, any subsequent connections to the server cause an exception. If I restart the server everything is fine. It seems to me that if the clients' connection to the server channel is disconnected improperly, the server is hosed. Is there any way to periodically check to see if a channel is 'stuck'? Otherwise I'll have to set up some kind of schedule of periodically unmarshalling/disconnecting and then re-marshalling/connecting, just in case the server is stuck. That just seems inelegant to me.
Thanks for any suggestions,
jt
|
|
|
|
|
What calling convention are you using for the remoting type? (i.e., client-activated / server-activated, single-call / singeton, etc.)
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
It's a single call, no server config file, it's all in the code
|
|
|
|
|
The only thing that I can think of is that the server is in the middle of doing something with the client and either throws an unhandled exception (that can't get passed to the client because it doesn't exist, so instead the remoting host must catch it) or tries to handle an exception and does something even more nasty.
Since it is a singleton and Remoting is supposed to be (:P) smart enough to handle disconnect situations, the remoting object itself must be doing something to screw up it's host (i.e., IIS, Windows Service, et. al.).
Since you said you're setting up the remoting object via code, check to make sure that any unhandled exceptions don't cause your entry point to continue and exit, causing your app to quit - or worse, cause the CLR to unload (like any calls to Environment.Exit(int)).
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
I think it's fixed. I wasn't checking the validity of the server name in the client app (which was throwing an exception and generally causing problems), and since then I haven't been able to duplicate the problem, but I'm still curious as to if it's possible to check the 'status'-so to speak- of a remoting session
|
|
|
|
|
Shortly after I posted my possible problem, I got to thinking: have you ever checked after this "crash" if the service was still responding? If the host for the remoting object was hosed, it shouldn't respond. This indicates an error with the host, such as the remoting object throwing an exception that could be unhandled in the host and would effectively kill the host. If so, you shouldn't get a service response.
I'm glad it's fixed, but should ever anything like this happen again, check to see if the service itself is responding (i.e., ping the service using a non-activation client like soapsuds.exe or wsdl.exe (depending on the host)). That would most definitely be interesting to know and might help you figure out who to blame (i.e., the remote object vs. remoting infrastructure vs. the host).
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
OK, it happened again when I changed some of the code, here is the relevant exception info
Error: System.Runtime.Remoting.RemotingException: Server encountered an internal error. For more information, turn on customErrors in the server's .config file
.
Server stack trace:
Exception rethrown at [0]: at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage req Msg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
It seems to me the server is throwing back the exception (HandleReturnMessage). Again a restart of the server fixes the problem (no changes in the code just restarting clears it up). The problem is the server still responds locally (i.e. other parts of it still work), just the remoting is hosed.
|
|
|
|
|
Did you try using soapsuds.exe or something to see if the object still responds at all? (Or are you already sure that it doesn't.)
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
|
I'm not sure what to think, then. Either you've uncovered a major bug in the Remoting infrastructure or (no offense meant) you've put one there. The only thing I can think of is something I've stated before. The Remoting object is throwing an exception that the host isn't gracefully handling and the host, as a result, dies.
When you say "other parts of the app" - is this all in a single executable, this "app" you mention? I could be wrong if the app still lives, but still maybe not. If the exception causes the message pump to quit or die, the app will terminate. We had this happen with a Windows Service-hosted remoting object I wrote sometime back (since fixed by existing...er, better exception handling).
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
Let me elaborate:
I have three projects, server, client, dll
The server is a single windows app that just exports the methods in the dll through remoting. It also creates a local instance of the dll.
The dll is just two methods that both call Shell(), with different parameters.
the client is a console app that connects to the server to access the remoted methods, and calls one or the other.
When the client can't connect without an exception being thrown, the server is still running, and the local instance still functions. I have exception handling in the dll (which is where the error says it's originating), but it doesn't catch anything.
The code is extremely simple (less than 10 lines per piece) maybe it would be easier if I sent it to you and we can continue this discussion off list.
thanks for the help, btw
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
