I'm using the Visual Studio UML designer to create some class diagrams. Since I would like to generate code from the diagrams it need to be accurate.
Now I'm trying to define the type of some properties of my classes, but I can't find a way to give them a type different from bool, string, int and UmlimitedNatural (and my own types of course). I found a tutorials that claims I would have to create custom stereotypes. Really? I mean it's VS, I'm just asking for some build in reference/value types like byte or GUID.
Do I overlook a hidden switch or if there is really now way to tell VS to bring up some commonly used types does anyone know a source for UML profiles that provide it? And how I can define more complex types like generics?
UML is implementation language neutral. Since types differ by platforms it is necessary to define an implementation language profile for any UML tool. Most UML CASE tools include the option to choose the language and apply a built in profile, which should make them available.
Related
I am learning MFC. If I am not wrong, the names of all the MFC classes start with the capital letter "C" (e.g. CFrameWnd, CFile, CMenu, etc.)
I found that the code generated by the Visual Studio wizard for MFC based project gives similar names to the user-defined classes. For example, if I name my project as "Shapes" then, the classes generated for the project contains classes such as CShapesApp, CMainFrame, CChildView, etc.
In the end, you would have several classes in your project, which may look like CShapesApp, CFrameWnd, CMainFrame, CWinApp, CWnd, etc.
QUESTIONS: For me, the names of the classes (user-defined and MFC library) seem quite similar and hard to differentiate if it is a user-defined class or an MFC library class.
Why MFC based projects choose such naming conventions (i.e. why to put "C" in front of the user-defined classes)?
How can I easily differentiate between MFC library classes and user-defined classes?
UPDATE: I know that I can change the names and I have already tried that. But the general convention is to start the class names with "C" even for the user-defined classes and my question is why? and how can I differentiate easily?
Why MFC based projects choose such naming conventions (i.e. why to put "C" in front of the user-defined classes)?
That's impossible to answer. At a guess, that was just the common thing to do, back in the early 90's. Namespaces were added to C++ in 1995, i.e. years after work on MFC had started, so MFC wound up in the global namespace. Using a C prefix for classes reduces the chance for symbols to clash with the Windows API and SDK headers.
How can I easily differentiate between MFC library classes and user-defined classes?
MFC classes are user-defined classes. It is not immediately clear, why you need to differentiate between user-defined classes provided by MFC and user-defined classes provided by your code. If you find this useful, there's no shortcut. You just have to memorize which ones belong to MFC.
There are, however, 2 sets of classes in MFC, for which it is helpful to know, which set they are in: The 'original' classes, and the classes introduced with Visual Studio 2008 (I believe), that offer a wider set of functionality. You can distinguish between those sets by looking at the prefix: The 'original' classes start with C (like CButton), and the updated classes have a CMFC prefix (like CMFCButton).
The "C" prefix convention is a question of your taste. But remind, all MFC-derived classes "are" in fact MFC classes - in the sense of inheritance meaning a derived class "is" also the ancestor. So don't forget your CWnd-derived CMyWnd has everything a CWnd also has.
My personal approach for naming (which I introduced in several dev teams) is to use the "C" prefix for all MFC-derived classes and use another one (or even none) on non-MFC-derived classes.
I have a VS 2013 solution with one VB.NET ASP.NET project which references several c# class library projects (not DLLs) within the same solution. I made lots of changes to logic within some of the method overloads in one of the c# projects. Since the VB.NET project uses these overloads extensively, I want to see how many places these methods are referenced. I go to the c# project that contains the changes, right-click the overload I want, and select Find All References, but it only shows me the references in the c# projects. However, when I go to one of those methods in the VB.NET project, it finds all the references within the VB.NET project as well as the method declarations in the c# project.
I could do a solution-wide text search for the method name, but this method name is used multiple times because it's overloaded. Therefore, I want to search for a particular overloaded method signature, not the method name.
Is this a known shortcoming of VS 2013? Something else I've also noticed that I've noticed is that selecting Go To Reference from within a VB.NET project on a method that's declared in a c# project will take you to the object browser rather than directly to the method definition in the source project itself.
This is an old problem, there are many bug feedback reports for it on Microsoft's feedback site. The canonical one is probably this one. Quoting Dustin Campbell's response:
The general problem is that C# and Visual Basic do not share any common infrastructure with regard to the symbol tables that are used for features like Find All References, Go to Definition or Rename. So, such features don't work between multiple languages. That said, we are looking at ways to change this in the future, but the work required is very substantial.
Annotating a bit, the C# and VB.NET IDEs look similar at the surface but they are very different under the hood. Part of that is them being supported by distinct groups within Microsoft, a survival strategy for any software company, big groups don't work. But above all history plays a strong role in this, Visual Basic had strong IDE support for a very long time. They did not throw away that work when they moved to VB.NET, not in the least because they had to support all previous IDE features so not to alienate their existing customer base. The C# team got a fresh start without that baggage, they started from scratch. Inevitably the internals between them, like the IntelliSense symbol tables, are drastically different.
Tackling the "common infrastructure" problem was not forgotten, the Roslyn project was the instrumental step. It took a very long time to get finished but it is ready to go today. Integrated into VS2015. Whether it actually solves this problem is something I don't know yet, I will in a couple of months. Maybe somebody that has the RC version can confirm. They did create two versions of Roslyn, one for C# and another for VB.NET. Uh-oh.
I already get hold of a IVsHierarchy object, the information I want is the project type (WinForm, WPF, ASP, etc.), language (C#, VB, F#, etc.) and debug configuration (debug, release, x86, amd64, etc.). What the reliable way to get this information?
I can get an EnvDTE.Project from the IVsHierarchy, and it contains properties like CodeModel.Language, Kind, and ConfigurationManager.ActiveConfiguration, but I’m not sure those are the right properties to check against. For example, the possible language values are as following
vsCMLanguageCSharp Visual C# constant.
vsCMLanguageIDL Microsoft IDL constant.
vsCMLanguageMC Visual C++ constant.
vsCMLanguageVB Visual Basic constant.
vsCMLanguageVC Visual C++ constant.
This seems to be a very limited list, where are the languages like F#?
It’s even worse for project kind, the only possible values are prjKindCSharpProject, prjKindVBProject, prjKindVSAProject. Is it possible to get more detailed information like C# ASP, VB WPF etc.?
Well, http://www.mztools.com/articles/2008/mz2008017.aspx and How to Get Project Type Guid of selected project in the Solution Explorer by using VS Package gave me a fairly good idea of how to get the project type, and I can also figure out the language type from it. CodeModel seems to be the wrong approach to get it.
In this related question, I noted that Visual Studio's debugger is able to enumerate the properties of System.__ComObject references, which is "a hidden type used when the wrapper type is ambiguous" -- e.g., the type of object you get when you obtain it from another COM object and don't instantiate it yourself:
Additionally, if you simply write a COM object's identifier into the Immediate Window, its properties and values are similarly dumped:
Note that this is separate from VS2010's "Dynamic View", which I believe uses IDispatch and COM reflection to enumerate the properties of COM objects without the use of PIAs and .NET reflection. The objects I am working with do not implement IDispatch (nor do they implement IProvideClassInfo for that matter), and as such, "Dynamic View" is not able to obtain any information about them:
Interestingly, SharpDevelop's debugger is not able to list the members of System.__Comobjects (e.g. point.Envelope), only strongly-typed RCWs (e.g. point).
So how is Visual Studio able to do it?
I believe in this case, it is because Primary Interop Assemblies exist with definitions for the interfaces supported by these objects, and Visual Studio is likely using reflection to enumerate the supported interfaces and properties. Is that accurate? And if so, how does it work?
For starters, how does it access the PIAs? Does it only look at currently loaded PIAs or does it dynamically load them (and if so, how)? How does it determine which interface, of which there can be many, to enumerate the properties of? It only seems to use one, and not necessarily the first. From the documentation of the API I'm working with (ArcObjects), the default interface for these objects is IUnknown, so it's not just using the default interface either.
In the example in the screenshots, the interface it is enumerating the members of is the IEnvelope interface, which inherits from the IGeometry interface. How does VS2010 know not to enumerate the members of IGeometry instead, which, in my testing, appears first if you just enumerate all the interface types in the PIA? Something very clever going on or perhaps I am missing something obvious?
The reason I'm asking is that the developer of LINQPad appears willing to implement the same functionality if he knew how VS does it. So a good answer here could go a long ways to helping improve that very popular tool.
This is how to do it:
obtain COM object's IDispatch (alternative possible path is IDispatchEx)
obtain a reference to type library -- IDispatch::GetTypeInfo
load type library and enumerate properties
query real object for values for discovered properties
Additional enhancement oipions apply: query IPersist* family of interfaces or IProvideClassInfo to alternatively obtain a reference to typelibrary for the object and discover properties.
A word or two about project I have to make.
I have a list of products (XML formatted), and I have to make a bar code of that list.
Here are the requirements:
Technology has to be MFC, VS 2005 or VS2008
All functionality must be in one dll
Same solution should have a simple tester for the dll
I will use pdf417. http://en.wikipedia.org/wiki/PDF417 http://sourceforge.net/projects/pdf417lib/
Also, I would like to provide an interface, so that different bar codes can be implemented in future.
For example, my dll has "Write" method which is implemented in a separate file for pdf417 and in a separate file for some other bar code, so that user can choose which bar code to use.
Since I have no knowledge of mfc, I really don't know how to even start. I read some tutorials, created the dll with some dummy method, and then tried to use it in tester application, but no luck.
I know that this is a "needle in a haystack" type of a question, but if someone could help me how to setup/architect this project I would be very grateful.
Thanks,
Marko
I don't see how you benefit from using MFC if your DLL's client is not an MFC app. You are better off using a standard C interface in your exported functions if you want to support non-MFC clients. Just create a Win32 project and choose the project type as DLL, then the wizard will generate some example exported function for you. Follow the examples to create your own export functions.