I am trying to see if there is a way to get the contents of a datagridview that is inside a top level window using Windows API's. I am using Visual Basic for this, but could also use C.
I doubt you could use the WinAPI to drill into a .NET app's DGV to get any meaningful information. But you might be able to using Reflection which enables you to obtain information about assemblies and the types defined within them, such as classes, interfaces, and value types. The ops are contained in the System.Reflection namespace.
Its fairly slow, so it is often a last resort, and the methods and such are pretty dense (convoluted) because you are getting at the information the 'long way around' by examining the Types and then asking the type for information.
This project shows how to access information in a different executing assembly. Given enough time and work and study, it should give you an idea how to do what you are asking.
Related
As I know, it's basing on Guru for vim-go to find the implementations or usage which needs to compile the whole project as a premise. Otherwise, GoLand doesn't need to do that, but how?
While this task may look rather trivial, GoLand uses some tricks to perform it more efficiently. Let's go step by step to explore how it works.
When one opens a project for the first time, the IDE performs so-called indexing. In particular, it stores all the method and method spec names as well as the number of their parameters.
At the beginning of the search, GoLand takes method specs of the interface and finds one with the biggest number of parameters. This is a performance optimization. The idea behind it is that methods with many parameters occur less often in the code, so the IDE needs to check just a few of them.
It's time to use the index. For the chosen method spec, the IDE finds all corresponding methods. The scope is taken into account, so for a private interface, for instance, it's much smaller.
For each method, GoLand resolves its type and checks whether it implements the interface. This is the moment when all interface's method specs are taken into account.
Not only structures can implement interfaces but other interfaces, too. As the next steps, the IDE looks for all corresponding method specifications, that is, method specifications with the same name and number of parameters. There's a separate index that's responsible for this.
For each method spec, its interface is taken and checked. No resolution is involved this time as it's enough to traverse a syntax tree up to find an interface of an arbitrary method spec.
That's basically the algorithm. There are a few more implementation details to make it works faster, but they don't affect results.
GoLand relies on the IntelliJ Platform and a set of custom written tooling bundled as a custom language plugin on top of it to handle indexing, parsing, navigation and editing code.
I'm creating code for interfaces specified in IBM Rational Rhapsody. Rhapsody implicitly generates include statements for other data types used in my interfaces. But I would like to have more control over the include statements, so I specify them explicitly as text elements in the source artifacts of the component. Therefore I would like to prevent Rhapsody from generating the include statements itself. Is this possible?
If this can be done, it is mostly likely with Properties. In the feature box click on properties and filter by 'include' to see some likely candidates. Not all of the properties have descriptions of what exactly they do so good luck.
EDIT:
I spent some time looking through the properties as well an could not find any to get what you want. It seems likely you cannot do this with the basic version of Rhapsody. IBM does license an add-on to customize the code generation, called Rules Composer (I think); this would almost certainly allow you to customize the includes but at quite a cost.
There are two other possible approaches. Depending on how you are customizing the include statements you may be able to write a simple shell script, perhaps using sed, and then just run that script to update your code every time Rhapsody generates it.
The other approach would be to use the Rhapsody API to create a plugin/tool that iterates through all the interfaces and changes the source artifacts accordingly. I have not tried this method myself but I know my coworkers have used the API to do similar things.
Finally I found the properties that let Rhapsody produce the required output: GenerateImplicitDependencies for several elements and GenerateDeclarationDependency for Type elements. Disabling these will avoid the generation of implicit include statements.
I am new to Ruby, and I am currently working with an API which is unfamiliar to me. In order to use code completion, which helps me learn, I installed RadRails in Eclipse. However, I am having trouble with Content Assist: specifically, the Content Assist does not reveal the methods for objects in the API.
For example, one of my objects, ins, represents a loaded XBRL instance document. If I run ins.methods, the list contains all of the methods I want, including those in the API (such as functions that allow me to access items in the instance):
...
item
item_all
item_all_groupby_vocab
item_all_map
item_by_vocab
item_ctx_filter
...
etc.
However, if I just type ins. with Content Assist enabled, it only shows options like:
dclone
gem
gem_original_require
JSON
Pathname(path)
...
etc.
which appear to be system options. As a result, the Content Assist exposes exactly zero of the methods I actually want to use. If I know the methods ahead of time and start typing them, I can get Content Assist to give them to me, eventually, by pressing Ctrl+Space. However, that requires me to know what I want ahead of time; since I am using this to explore the API, that doesn't work for me.
Does anyone know how to get RadRails/Eclipse to show me the correct methods?
Regards,
Matt
This is a general problem inherent to dynamic languages and IDEs/editors. The IDE has to guess at the type of the variable that the code assist is being invoked upon, and from that generate the list of applicable methods.
IRB has type information at runtime, so it knows what methods apply. The IDE is trying to guess the type by analyzing your code statically (not running it).
Having said that, the IDE should often be able to guess correctly. Providing the larger context of the snippet of code that this is being invoked on would be helpful to look into whether or not we could provide helpful content assist on this object. You may want to file a ticket with the version number, and the sample code here: http://aptana.com/r/apbugs
One thing that constantly causing me headache in programming is when I don't have any naming-convention in a domain where I have to deal with a lot elements. It is clearly what is happening to me when using UI designers such as Windows Forms designer.
Everytime I start a new project I am trying to reinvent a "seem-strong" naming convention but it always fail at some points. For me there is 2 main problems compared to classic code definition for naming GUI elements:
You have to place a lot of variables (GUI elements) which can all be accessed in the same scope, so you need to have to a strong naming convention to find quickly the right element.
You often need to access to a specific type of GUI control (ex: TextBox, Label, ...), so the best solution for GUI elements is to name them after their types (Hungarian style notation), which can be sometimes confusing and not helping in finding the right element quickly.
If someone has a documentation describing a good convention or a strong convention he invented for its own project, I would really like to know it!
NB: I did not classified this question under .NET or Windows Forms tags has it seems applicable to a lot of frameworks. If not, let me know.
EDIT:
In fact the convention I most use is using a reversed hungarian notation (meaning the type comes first) followed by a path based on the UI elements hierarchy. For example, to easily access to a TextBox which belongs to the "Settings" tab of my program I would call it this way:
this.tb_settingTab_xxx
My problem using this convention is that it is not perfect and sometimes fails when you have a UI element that belongs to another which also belongs to another which also belongs to ...
I am really searching for is the unbreakable and handy naming-convention. I am quitely surprised that Microsoft never gaved any guidelines concerning this. Or am I going wrong? (ie. Mark Rushakoff comment).
There are various naming conventions described in this post. The key is to remain consistent throughout the project. I deal with a lot of controls, but find it straightforward to label them based on what they are. Textbox = tbMyControl, Label = lblMyControl. The 'MyControl' bit might be the same if they relate to similar aspects (e.g. tbUsername, lblUsername). However, there's no confusion on what I'm accessing. If you find you're getting confused, then maybe you're trying too many different notations? Keep it simple and logical.
Note: I use the following in code that covers - and sometimes mixes - "raw" Win32, ATL/WTL and MFC, so don't take it literally, only the principle. (Also, be forgiving on the m_)
I use a two-letter-shortcut for standard control types, followed by the name which resembles the functionality of the control (in most cases, Identical / close to the label). The name of related controls needs to match of course - e.g.
CStatic m_stBasePath;
CEdit m_edBasePath;
CButton m_cbBrowseBasePath;
It's not perfect for all scenarios, but generally I'd say a dialog where this isn't good enough anymore might have to many controls for the user already.
I've written three paragraphs that could be titled "details and defense" - and subsequently deleted them, since there's a very clear essence:
Consistency.
I mostly use the dialog resource itself for orientation, and have strict equivalence between resource ID's and associated members. So the "Base path" - related controls aren#t together in an alphabetic order, but I rarely see this as a problem.
The standard control type already contains very obvious information about functionaltiy of a control - a checkbox to enable / disable a group of features or for a boolean option, an edit or drop down to enter/select a value, a button to open a sub dialog, a static control for the label, etc.
I'm not sure how this style transfers if you transfer it to a platform with much more controls or when you use a lot of custom controls, as my WinForms projects have been comparedly small.
I'm looking into writing an addin (or package, if necessary) for Visual Studio 2005 that needs watch window type functionality -- evaluation of expressions and examination of the types. The automation facilities provide
Debugger::GetExpression, which is useful enough, but the information
provided is a bit crude.
From looking through the docs, it sounds like an
IDebugExpressionContext2 would be more useful. With one of these it
looks as if I can get more information from an expression -- detailed
information about the type and any members and so on and so forth, without having everything come through as strings.
I can't find any way of actually getting a IDebugExpressionContext2,
though! IDebugProgramProvider2 sort of looks relevant, in that I
could start with IDebugProgramProvider2::GetProviderProcessData and
then slowly drill down until reaching something that can supply my
expression context -- but I'll need to supply a port to this, and it's
not clear how to retrieve the port corresponding to the current debug
session. (Even if I tried every port, it's not obvious how to tell
which port is the right one...)
I'm becoming suspicious that this simply isn't a supported use case, but with any luck I've simply missed something crashingly obvious.
Can anybody help?
By using IDebugExpressionContext you'll ultamitely end up getting ahold of an instance of IDebugProperty. This interface is implemented by the Expression Evaluator service. This is, typically, a language specific service. It's designed to abstract out the language specific details of evaluating an expression. It understands much higher level commands like "Evaluate", and inspection.
I don't think you're going to get what you're looking for though because you can't get ahold of any kind of type object this way. Nearly all of the inspection methods return their results in String form. For example you won't get the type Int32 but instead the string "int". This makes type inspection next to impossible.
I don't believe what you're trying is a supported case. The type system being evaluated doesn't exist in the current process. It exists in the debuggee process and is fairly difficult to get access to.
There's a hack you could do to get more information about the type of a variable you've evaluated using Debugger::GetExpression method.
You could evaluate "AppDomain.CurrentDomain.GetAssemblies()" to get all the assemblies loaded into the debugee, and cache them in your add-in. You may also need to listen for new assemblies being loaded onto the AppDomain.
Then, run the following:
Expression myExpression = Debugger.GetExpression(...);
Expression typeRefExpression = Debugger.GetExpression("typeof(" + myExpression.Type + ").FullName"
once you have the TypeFullName, you can search inside your assemblies cache for a matching System.Type, and once you have that, you can dig into it all you want using the standart Reflection API.
Note that this will only work in C#, because of its "typeof" keyword. You'll have to use a different keyword for VB.Net, for example.