|
elena12345 wrote:
Do you know of a way to make the compiler tell me about the resource problems?
Code better 
leppie::AllocCPArticle("Zee blog");
Seen on my Campus BBS: Linux is free...coz no-one wants to pay for it.
|
|
|
|
|
Yeah, thanks a lot 
I am just moving a bunch of code.
And a bunch of resource strings have to move from one file to another.
So I want to make sure I didn't leave anything out.
Don't tell me to architect better. I didn't architect this thing 
Elena
|
|
|
|
|
You could have an external application use reflection on your assembly to check for completeness.
You could do something like create string contants in a certain namespace and have this program use reflection on that namespace to get each string constant. It could then use reflection to make sure the resources contain something named the same thing.
You could then make this "check" part of your build.
I, for one, do not think the problem was that the band was down. I think that the problem may have been that there was a Stonehenge monument on the stage that was in danger of being crushed by a dwarf.
-David St. Hubbins
|
|
|
|
|
The compiler (csc.exe in this case) doesn't care about resource files, just like the resource compiler (resgen.exe) doesn't care about source code.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
I am trying to add a control in a panel from another thread than the on who created the panel.
So in this case I have to use the invoke method on the panel control to do that : this.Controls.Add(...).
My code is working very well on the framework, but with the same code, I have an Argument exception on the Compact Framework.
If Smbd has an id.
Thanks
|
|
|
|
|
MobileLover wrote:
If Smbd has an id.
Make sure the method you are calling via invoke is infact available on the compact framwork.
leppie::AllocCPArticle("Zee blog");
Seen on my Campus BBS: Linux is free...coz no-one wants to pay for it.
|
|
|
|
|
Yes it is a method written by me !
|
|
|
|
|
I wrote a Form that acts as a slightly more sophisicated MessageBox. The only thing I cant do is make my application wait for the user to make his selection and hit OK before continuing (sp?).
Please let me know if there is an easy way of doing this. Hopefully without sitting in a while loop waiting for a flag.
Thanks,
Matt
|
|
|
|
|
myform frm = new myfrm();
if(frm.Showdialog()==DialogResult.OK)
{
}
Mazy
"Improvisation is the touchstone of wit." - Molière
|
|
|
|
|
Looks like you beat me to it this time Mazy.
- Nick Parker
My Blog
|
|
|
|
|
Nick Parker wrote:
Looks like you beat me to it this time Mazy.
Yah, I exercise a lot to beat competitor. 
Mazy
"Improvisation is the touchstone of wit." - Molière
|
|
|
|
|
spindar wrote:
Please let me know if there is an easy way of doing this. Hopefully without sitting in a while loop waiting for a flag.
Have you looked into the DialogResult enum? You can do things like this (similar to how the MessageBox works):
Form2 fr = new Form2();
if(fr.ShowDialog().Equals(DialogResult.OK))
{
MessageBox.Show("Hey");
}
- Nick Parker
My Blog
|
|
|
|
|
Thanks for the help and the fast response
Matt
|
|
|
|
|
Sorry for the basic post, but I have looked everywhere and I can't figure out if this is possible or not. I am wondering if it is possible to check and variable to see if it is between certain ranges of numbers using a switch statement.
Ex:
switch (int){
case (between 1 and 10):
case (between 11 and 20:
and so on. Let me know if know.
Jason
|
|
|
|
|
you can preprocess the number a bit beforehand like switch(int/10)
leppie::AllocCPArticle("Zee blog");
Seen on my Campus BBS: Linux is free...coz no-one wants to pay for it.
|
|
|
|
|
Another way is to combine (encode) 2 numbers into 1 eg:
Required range: 22-63
int range = (22 << 16) + (63 & 0xFFFF);
leppie::AllocCPArticle("Zee blog");
Seen on my Campus BBS: Linux is free...coz no-one wants to pay for it.
|
|
|
|
|
This is one of those features that VB has that I wish C# supported. You can just add case statements for each of the values adding the break statement to the last case in the range
switch (value)
{
case 1:
case 2:
case 3:
case 4:
case 5:
case 6:
case 7:
case 8:
case 9:
case 10:
DoSomething ();
break;
}
not pretty but it works.
|
|
|
|
|
I am not sure if this is in the right board, but i'll post anyway. I am looking for suggestions as to the best way of implementing the system for my company. These systems are completely new so there are no backward compatibility considerations.
The company currently has 10 clients (which is likely to rise rapidly) that need to connect to a SQL Server database to get a record, edit it on screen and return the results. The connection needs to be made in such a way that no 2 clients can get the same record. What I really need are some suggestions as to the best way of implementing this. I am quite new to C# and .net as a whole, so my current solution is to use an asp.net application which uses a web service to access a stored procedure. The stored procedure has the logic in it such that it will stop multiple gets of the same record.
I have been doing a little bit of research and have found that the same desired effect may be achieved with COM+ and MTS or using .net remoting. As I have experience with neither of these technologies I would be grateful for some pointers. The web service route works in my test environment, but I need a system that will be suitable of an ever increasing client base.
Jason Pyke
|
|
|
|
|
Hey man, I can't understand why do you want to go for ASP.NEt,web service or remoting? You can easily have a windows application which connect to a databse and do what ever they want. You can isolate recored too. What do you exactly mean by 2 client get same record? You could change your databse/code design to doing something like this, not go for rmoting,WS or...
Mazy
"Improvisation is the touchstone of wit." - Molière
|
|
|
|
|
The only reason I am using ASP.net is that it is possible in the future that the application may need to span sites. When I say 2 clients can't get the same record I mean that there will be a table containing records A,B and C and if 2 clients request a record at the same time client 1 will get record A and client 2 will get record B (client 1 and 2 can't have record A at the same time). Do you think it's worth creating a winforms application on a shared directory for this type of application? My main worries with a winform approach (with no data tier) are scalability and bug fixing (I have had a situation with a previous company where I have had 50 people accessing an app I am trying to compile).
|
|
|
|
|
Unlike Mazdak, I think you'd be well-off if you went with .NET technologies. They're here to stay and are very easy to change and code (decreased development times when you have people that understand .NET already, otherwise factor in your learning curve).
As far as your design, think carefully about what you want to expose as Web Services and what you want to expose as .NET Remoting objects. Web Services provide data, where .NET Remoting provides objects. Web Services are especially handy when providing access for unknown clients (like someone using Java, .NET, or any other SOAP clients). .NET Remoting - though it can use SOAP - is a complex structure that deals with instances of objects rather than just data (even though Web Services can serialize objects into SOAP and vice versa, they don't represent instances of objects - merely copies).
As far as using a client, ASP.NET and Windows Forms are both viable technologies. It's not uncommon for ASP.NET to make use of the same Web Services that external client would, even though they might have direct access to the same data. In cases where scalability is a concern, though, you might consider abstracting that data access layer so that the ASP.NET application and the Web Service (even if hosted in the ASP.NET application) use that to access the data. If you access the Web Services from ASP.NET, you take a performance hit for the serialization and setting up the proxies.
There are plenty of examples about using COM+ (already includes transactions, which negates the need for MTS unless you're talking about something else) from Remoting, and even some topics are included in the .NET Framework SDK, which you should read through (at least the topics and familiarize yourself with what's available in the base class library). MSDN[^] also includes a lot of examples and articles on this. I believe the CodeProject even has a few as well.
This is fairly common in .NET Remoting objects, because it exposes these proprietary technologies (COM+, MSMQ, etc.) to SOAP-compatible clients.
When designed properly, this should be very scalable, especially when using ASP.NET over traditional approaches like ASP or PHP. ASP.NET uses compiled objects; even the .ASPX pages are compiled when used for the first time, and using code-behind source files that must be compiled before publishing speeds things up - including debugging - considerably.
If you use .NET Remoting and Web Services, you can also create smart client applications that can be installed or launch from a URL. We currently have an application that does the latter and uses .NET Remoting. This leads me to warn you though that exposing .NET Remoting objects using IIS as the host automatically exposes them as Web Services - thereby requiring the HttpChannel be used, though you can still use either the binary or SOAP formatter.
I hope this helps.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Thank you very much for the information. I must admit that some of it is beyond me, but I will read more information using the .net samples/topics as a basis. I am thinking of implementing my data tier as a web service for stage 1 (as that seems easier to implement) and study more on remoting to decide if that's the route I need to go for final build. What I am slightly curious about is what remoting actually is. Is it's implementation much different from a web service? If remoting deals with objects, does that mean they are transactionable? if so how would that be implemented? I will read up more on these topics, but if you could give me a few pointers that would be great. There seems to be a wealth of information out there, I am just having a problem deciding what areas I need to look at.
Jason Pyke
|
|
|
|
|
I would suggest picking up the books .NET Remoting[^] (MSPress) and/or Advanced .NET Remoting[^] (Ingo Rammer). These take you through the basics and to intermediate and advanced topics (Ingo's book).
.NET Remoting in a basic concept is like XML Web Services. Remoting can use SOAP like Web Services do, but the overall architecture is very extensible. For instance, you can use either SOAP or binary formatters provided in the base class libraries, or use your own formatter to which object graphs are serialized. An HttpChannel and a TcpChannel are also provided (HTTP has some overhead, but integrates well when hosted with IIS), or you can create your own transmission chain.
And speaking of chains, .NET Remoting use an aspect-oriented approach - allowing you to chain handlers together to act on the serialized data before transmitting it across the wire. Web Services are not without their extensibility features, but this is acheived by adding custom elements to the SOAP messages, though the WSE from Microsoft (using industry standards like WS-Encryption, WS-Signatures, WS-Routing, and more) provides some additional capabilities. To do all this is much more difficult, though, as opposed to .NET Remoting that allows you to chain sinks together programmatically or as simple as using a .config file (making it easy to change the features of the sink chain without having to recode and recompile, like adding logging capabilities for each message or different types of messages).
Finally, .NET Remoting works with .NET's serialization features to marshal instances of objects across application domains (.NET Remoting is also the prefered way for IPC between AppDomains in .NET, typically using a TcpChannel). Web Services can only send copies of an object.
So, for instance, lets say you had a Person object in your application. If you call a remote method on the Person object using .NET Remoting, if that method modifies the object, the modification will be reflected in the local Person object. With Web Services, you could only get a copy of that object back.
XML Web Services work good for many things, especially B2B, B2P, and P2P communication when dealing with data (like Microsoft Research task pane in their Office 2003 system). .NET Remoting is nice when you want to build distributed applications that work with and modify objects.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Heath, I want to clear it for myself, You mean using COM+/Web Service/Remoting to handle that database processing part and send back results to client application(for example win application) has more performance than to have one windows application which DIRECTLY connect to database and do that part itself? I think they are adding another layer , so does it cause better perfomance?
Mazy
"Improvisation is the touchstone of wit." - Molière
|
|
|
|
|
I never said it would perform better, just making the point that it works better. When architecting enterprise solutions, you have to take many things into account, like scalability, extensibility (for easy changes in the future), possible re-structing of the network (in part or in whole) and many other things. Web Services and .NET Remoting (throw COM+ in there, but I recommend sticking with .NET Remoting on that one) give you flexibility to easily change things in the future, as well as to push-out new services without breaking existing applications. Added to that is that you can make certain services available to business partners and consumers if your company were to require it.
It's not always a question of performance, but also a question of extensibility, modularity (breaking-up assemblies into logic categories, for instance), and scalability.
Always thinking in modular terms will provide you a more robust solution that can grow far into the future. Some would disagree saying, using the term KISS (keep it simple stupid), and for some solutions (say a doctor's office needs a simple scheduling system that won't likely change for many years, as they seldom do) that's fine. When dealing with large enterprise applications, thinking ahead can definitely benefit the architecture than just creating something that just performs a particular job.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
