|
You need to use the GetCustomAttributes method of the FieldInfo object. The code would look something like this (untested, modified from production code that looks for a different attribute):
public static bool HasFlagsEnum(Enum value)
{
if (value == null)
{
throw new ArgumentNullException("value");
}
bool hasFlagsAttribute = false;
FieldInfo fieldInfo = value.GetType().GetField(value.ToString());
FlagsAttribute[] attributes =
(FlagsAttribute[])fieldInfo.GetCustomAttributes(typeof(FlagsAttribute), false);
if (attributes != null && attributes.Length > 0)
{
hasFlagsAttribute = true;
}
return hasFlagsAttribute;
}Assuming an enum named Color that has the FlagsAttribute, you would call this function like this:
Color color = Color.Red | Color.Yellow;
if (HasFlagsEnum(color) == true)
{
}This should get you pointed in the right direction.
-----------------------------
In just two days, tomorrow will be yesterday.
|
|
|
|
|
It works. Thanks for the pointer.
The VB code for anyone interested:
Private Function HasFlagsAttribute(ByVal Type As System.Type) As Boolean
Return Type.GetCustomAttributes(GetType(FlagsAttribute), False).Length > 0
End Function
|
|
|
|
|
 Break your app into modules (assemblies) and get away from the monolithic exe. In short, join the era of modern software development. It's difficult to bill yourself as a 21st century company when using 20th century thinking.
only two letters away from being an asset
|
|
|
|
|
http://www.codeproject.com/cs/design/three_tier_architecture.asp[^]
This could be a start, however, if you need help in figuring out how to seperate your application into multiple assemblies while avoiding cross references, then you are missing some core software design knowledge that can't be replaced by reading a few articles.
only two letters away from being an asset
|
|
|
|
|
|
vladdy77 wrote: who do you think you are
The one not having to ask how to design my application.
only two letters away from being an asset
|
|
|
|
|
|
傻瓜将笑既使您显示它一个手指
only two letters away from being an asset
|
|
|
|
|
Mark Nischalke wrote: 瓜将笑既使您显示它一个手指
Yep. His quote made no sense to me either 
Some people have a memory and an attention span, you should try them out one day. - Jeremy Falcon
|
|
|
|
|
Mark is right. YOu've got a SERIOUS redesign of your application in front of you. You'll be rewriting about half of your code to do what you want. This should have been a design requirement from Day 1, not after you ship your app!
If you can't see how an n-tier structure gives you the modularity you're looking for, I'm afraid that just reading a couple of articles isn't going to get the point acrossed.
By splitting up your application into seperate classes, such as a Data Layer, you're actually giving yourself the .DLL's you're looking for!
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
|
vladdy77 wrote: We're trying to avoid total redesign as we're not sure customer will agree to it.
You have but one choice here - It's either do a redesign or you live with the 20MB download.
vladdy77 wrote: There is very little data access in this application as it is basically automating MapPoint with their dispatch system and that's why n-tier architecture with gui/bus/data layer is not very applicable to this project.
You're still missing the point entirely and why Mark was saying this. You have to break this application down into more discrete modules, LIKE a Data Layer, or Business Logic Layer, or this, or that. The whole point is that you MUST modularize this code.
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
|
vladdy77 wrote: Did you even take a look at this article?
I don't have to. I already know how to break my applications into modular pieces.
vladdy77 wrote: How to have one VS solution and multiple project avoiding cross-referencing between assemblies?
Create a solution and start adding the appropriate project types to it. I don't get what you mean by "avoiding cross-referencing". If you keep code self-contained, that is for instance, a Data Access layer, then there shouldn't be any "cross-referencing" if I'm guessing at your meaning correctly.
If you have a module that calculates a payment schedule, that would be it's own class and could end up in it's own .DLL. DLL's are created on a per-project basis, usually. Now, if you add to that class, another class file that deals with som other financials, then you would end up with 2 classes in the same project, probably called Financials and end up with a Financials.DLL.
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
Dave Kreskowiak wrote: vladdy77 wrote:
Did you even take a look at this article?
I don't have to. I already know how to break my applications into modular pieces.
Though I know how to break down my apps into modular pieces, the article was good for a little refresher
Some people have a memory and an attention span, you should try them out one day. - Jeremy Falcon
|
|
|
|
|
vladdy77 wrote: Article has everything in one project and that is exactly what we have here.
It's not the number of projects that is important, but how the application is logically separated into layers. If the application is properly layered, putting the layers in separate projects can be done in a matter of minutes.
It's not the contents of the layers that is important either. A three-tier-application has layers that are logical for that kind of application, but for a different kind of application the layers are different.
If your classes has a clearly defined interface, they can quite easily be put in separate projects. If the classes are only used as containers for the program components, then you have a lot of work ahead of you.
vladdy77 wrote: How to have one VS solution and multiple project avoiding cross-referencing between assemblies?
Using layering.
---
b { font-weight: normal; }
|
|
|
|
|
vladdy77 wrote: I have a design problem and that's why I came here looking for answers. Is that a crime ?!?
No it's not a crime to come looking for answers to your design issue.
vladdy77 wrote: You will also have to agree that the way he approached was totally unprofessional and uncalled for.
... Trolling won't get him anywhere.
I don't think he was out of line with his approach.
Some people have a memory and an attention span, you should try them out one day. - Jeremy Falcon
|
|
|
|
|
vladdy77 wrote: There is very little data access in this application as it is basically automating MapPoint with their dispatch system and that's why n-tier architecture with gui/bus/data layer is not very applicable to this project.
n-tier doesn't have to mean "gui/bus/data" as you put it. I look at it as separating the inputs and outputs from the business layer. The business layer is the glue that holds it all together. The GUI is an input/output layer, just like the database is another type of input/output layer. I tend to look at it as hub and spoke design rather than tiers - It happens that the most common is a hub (the business layer) with two spokes (the GUI and the Data).
In your application the GUI is a spoke, MapPoint is another spoke, if you deal with files then that's another spoke.
If you can identify each of these spokes then you can identify what can be split out to other DLLs. Just remember, for anything to communicate with another spoke, it must go through the hub as each of the spokes should be designed to be self contained.
Once you have this you can start adding more spokes in future (say you need a Web front end, or a mobile version, or you start supporting Oracle Spatial, etc.)
vladdy77 wrote: Needless to say that I came from different environment but I guess you "pro's" won't tolerate that.
I think most of us have, at one point, been in a monolithic project that was getting out of control. Those that have now have a severe dislike, even hatred, for that model (also called the Giant Ball of Mud Design Pattern/Paradigm) because it caused so much fustration. I was, for 4 years, on a monolithic project and for 3 of those 4 years I would be trying to persuade people that we really needed to split up the code in to manageable blocks.
|
|
|
|
|
Colin Angus Mackay wrote: n-tier doesn't have to mean "gui/bus/data" as you put it
Exactly. n-tier was never meant to mean this. This is just one (common) use of n-tier architecture. Ironically (speaking mathematically) all systems are n-tier.
Colin Angus Mackay wrote: I think most of us have, at one point, been in a monolithic project that was getting out of control
That brings back so many bad memories.
Arthur Dent - "That would explain it. All my life I've had this strange feeling that there's something big and sinister going on in the world."
Slartibartfast - "No. That's perfectly normal paranoia. Everybody in the universe gets that."
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Dave Kreskowiak wrote: Mark is right. YOu've got a SERIOUS redesign of your application in front of you.
I concur.
Dave Kreskowiak wrote: By splitting up your application into seperate classes, such as a Data Layer, you're actually giving yourself the .DLL's you're looking for!
Excellent point 
Some people have a memory and an attention span, you should try them out one day. - Jeremy Falcon
|
|
|
|
|
Dear friends,
I am using the reflection class in .net to write a reflector which is a simple program that show the content of a assembly.but i have a problem.
if a .dll reference another .dll and they are both in a same directory ,the LoadFrom() method solve my problem.but if they are in different directories i have to browse the referenced one and load it.
Despite of loading the referenced one in application domain,the GetTypes() function of assembly class insist on throwing exception.Why?.I don't know.
I would apprecite your helping hand.
hossein
|
|
|
|
|
What exception is it throwing? Have you wrapped it in a try/catch block and debugged it? Look at the inner exception as well as the exception.
Arthur Dent - "That would explain it. All my life I've had this strange feeling that there's something big and sinister going on in the world."
Slartibartfast - "No. That's perfectly normal paranoia. Everybody in the universe gets that."
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
hi,
thanks for your reply,
this is the message "System.Reflection.ReflectionTypeLoadException: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information."
I tried to handle the exception by try /catch. after exception i know that i have to browse the referenced dll to application domain by Assembly.LoadFile() or AssemblyLoadFrom().it loads.but when i re enter to the GetTypes() method of assembly object,it throw again an exception.I mean it does not understand that the referenced dll is in domain.
|
|
|
|
|
I'm developing a serviced component in C#, this component is configured as transaction disabled, each method will either be transactional or not - transactional methods will use SWC ServiceConfig to create a transactional context.
The problem I've found concerns use of the Inheritance property;
If I set the property to Ignore, a new context is created which is not transactional (IsInTransaction = false) and security is not enabled in the new context (which is expected).
If I set the property to Inherit, a new context is created which again is not transactional (IsInTransaction = false) but this time security is enabled in the new context (ok, inherits this from the existing context).
If I don't set the property at all, a new context is created which is transactional (IsInTransaction = true) and security is not enabled in the new context (not sure what to expect at this point  .
The documentation states that this property is defaults to "Inherit", from my experience this doesn't seem to be bourne out - is it a bug 
Environment: XP Pro SP2, VS.NET 2003 SP1, .NET v1.1.4322
I've trawled the internet and not found anything, anyone else come across this??
|
|
|
|
|
Hi,
I am developing an application using the SCSF. I want to display a logon view for users to logon before displaying the Shell form and continue to load the other modules. If the logon fails I want to exit the application and not show the Shell form at all.
I have listed in the ProfileCatalog.xml the order of the modules to be loaded. The "logon" module is the first. But how can I terminate the the application halfway through? It does not respond to "Application.Exit()". It just continues to load the other modules. I also tried to throw an exception but I do not want the exception to be displayed as it is not an error.
Does anyone have any idea on how I can achieve this?
Thanks.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
