I am writing a CodeGenerator. The string output is later on mixed with user code.
In order to be able to make changes to my generated code after the user edits the file, I have to make sure my generated parts are not editable.
I am currently not sure how to achieve this behaviour..
If I would be able to track which line correlates to which CodeDomObject and vice versa I could tell my TextEditor to mark Lines as read only.
But at this Point I have two problems.
I don't know how to keep track.
I am not sure if my solution ( which I am not able to implement... ) is
clean. There would be a lot of overhead, because I have to find out
which object is generated and which not. I could do so by comparing a
generated CodeDomTree with the actual Tree and marking the diffs as
UserObjects.
I don't know if this solution is practical in your environment but this is handled using partial classes where required in Visual Studio.
An example would be Windows Forms where the visual designer is responsible for creating source code to reproduce the form at runtime but the developer is expected to add event handling code to the class.
By having the developer's code in a separate source file it doesn't get overwritten when changes are made in the designer.
Of course, this won't help you if you need to have a single source file for your class.
Related
I am trying to make changes to the behavior of a function and print the results to a file. The ViewCfg plug-in described in the Plug-in Development Guide does something similar, but I am trying to avoid having to use Ast.get, which ViewCfg uses. I am thinking of extending Printer.extensible_printer which, according to the Frama-C API Documentation, is something I can do if I want to obtain a custom pretty-printer.
However, if I extend the pretty-printer as described in the API docs, unless I'm doing something wrong, I notice that the changes I make take place regardless of which project is set as the current project. I'm using File.create_project_from_visitor to create a new project and Project.set_current to set the new project as the current project before I use the custom pretty-printer.
Is it true that any change made by a class that extends Printer.extensible_printer applies to all projects? I happen to be using frama-c-Aluminium-20160502, which I know is not the latest version.
EDIT: Sorry, I should have made this clearer in the beginning, but I'm not actually making changes to the behavior of a function. I'm reading in the behavior of a function, then based on that, I'm trying to generate as output valid C code that's meant to be read as input by another program.
Regarding AST.get, the only reason I was avoiding it was that it sounds like it gets the entire AST, while I'm only interested in part of it, i.e. behaviors. But if I'm just making things harder for myself by avoiding it, then I'll go ahead and use it.
I would like to access the history of what have been typed in the source panel in RStudio.
I'm interested in the way we learn and type code. Three things I would like to analyse are: i) the way a single person type code, ii) how different persons type code, iii) the way a beginner improve typing.
Grabbing the history of commands is quite satisfying as first attempt in this way but I would like to reach a finer granularity and thus access the successive changes, within a single line in a way.
So, to be clear, I'm neither looking for the history of commands or for a diff between different versions of and .R file.
What I would like to access is really the successive alterations to the source panel that are visible when you recursively press Ctrl+Z. I do not know if there is a more accurate word for what I describe, but again what I'm interested in is how bits of code are added/moved/deleted/corrected/improved in the source panel but not necessary passed to the Console and thus absent from the history of command.
This must be somewhere/somehow saved by RStudio as it is accessible by the later. This may be saved in a quite hidden/private/memory/process/... way and I have a very vague idea of how a GUI works. I do not know it if would be easily accessible, then programmaticaly analyzed, typically if we could save a file from it. Timestamps would be the cherry on top but I would be happy without.
Do you have idea how to access this history?
RStudio's source panel is essentially a view to an Ace Editor. As such you'd need to access the editor session's editSession and use getDocument or getWordRange along with the undo of the editSession's undoManager instance.
I don't think you'll be doing that from within RStudio without hacking on the RStudio code unless the RStudio Addin api is made to pass-thru editor events in the future.
It might be easier to write a session recorder as changes are made rather than try to mess with the undo history. I imagine you could write an Addin that calls a javascript to communicate over the existing RStudio port using the Ace Editor's events (ie. onChange).
As #GegznaV said, RStudio saves code history to a ".RHistory" file. It's in the "Documents" folder on my computer. It's probably the same folder if you're using Windows. If you do not know the location, you can find the file by searching.
It also allows saving RStudio history to a file manually. There is a "Save" button in the History panel. So you can also get a timestamp. You can ask different users to save their code history after they have finished writing code. It may be indirectly useful to your research.
I have a small Visual studio add-in that walks down active project and insert code to every method.
My target project has web service reference and it created a bunch of auto-generated refenrece files that I do not care about.
Is there a way to detect whether a projectitem is autogen file?
The project file has tag under but ProjectItem.Properties doesn’t have it.
Thanks
Is there a way to do this 100% reliably? I don't think so. The only way I've ever been able to tell if a file is autogenerated or not is by its content or by its filename.
Often, generated code files in newer versions of (what I know) C# have a ".g." within their names. This is not written in stone or guaranteed (I think windows forms and other older generators use ".Designer."), but it can be used as an indication.
If you look through different autogenerated code, you'll see there are a number of different ways it can be marked. There is no specific way that is universal. For example, autogenerated wire-up code in WPF codebehind files (the hidden InitializeComponent() method resides there) contains a partial class definition marked with the System.CodeDom.Compiler.GeneratedCodeAttribute and the methods are all marked with the System.Diagnostics.DebuggerNonUserCodeAttribute.
The first attribute resides on the class, so it may show up when inspecting the code via EnvDTE methods. You might have to resort to reading the file in raw and looking for that attribute.
Even this isn't enough information, as different code generators mark their code differently. Type safe DataSets and EF generated code mark their generated code with a comment at the top of the file
//------------------------------------------------------------------------------
// <auto-generated>
// This code was generated by a tool.
// Runtime Version:4.0.30319.551
//
// Changes to this file may cause incorrect behavior and will be lost if
// the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------
What now?
Unless you explore all the different ways autogenerated code is marked, and handle them all, there isn't any way (unless I'm missing something!) you can guarantee skipping these files. You have to ask yourself if it is worth the effort.
I found this tool but I wonder if it still the right way nowdays with net 4.0 or is there any straight forward oob alternatives.
I just need to add columns and update excel stuff programatically. There are many ways but I need to keep the original document as a template. The link above explains exactly what the requeriments are and why they created such "ExcelPackage" library.
A quick look at the link you provided seems like it will in fact keep the original template intact and just return a populated version of that template. This is a pretty common way to create and populate Excel documents using Open XML since it helps to minimize the amount of code you have to write. If you did not specify the layout, styles, formats, etc in a template you would be forced to define those when coding and that could lead to some bloated code. Overall, a project like this or using the Open XML SDK 2.0 to create the documents is the way to go.
I'm currently pondering my options for the following problem:
I have a (relatively) simple but often changing configuration file for my application which I want users to be able to edit and change without have to "understand" xml. I do not want them to have know anything about encoding or understand that they have to close every node they opened. Here is an example of a section in the configuration file (defining facets for some arbitrary search engine):
<section name="facets">
<facet type="format" label="Format" max="4"/>
<facet type="marcfields" Label="Author" max="5">
<mfield name="df100" subfields="abcdjq"/>
</facet>
<facet type="language" max="4"/>
<facet type="pubdate" max="6" submax="8"/>
</section>
Editing this section, user should should be able to re-order the facets, delete facets, configure existing facets or add new ones. So far so good, but the xml is not completely free form and comes with a couple of restriction/structure:
Facets come from a pre-defined set of
types (forkamt, marcields, language &
pubdate above), so when people choose
to add a new one, they need to be
able to choose a type.
Each facet type comes with "parameters" - some common for all types some specific. For example in the above XML, one can edit the label & max attribute for each facet. For the "marcfields"facet, one can add sub-nodes (with two editable attributes). For the"pubdate" facet, one can edit the submax attribute.
I am looking for a way to take my configuration file and make it editable in ASP.NET web environment. All of this would be fine to program, but I except the configuration file to change often and I don't want to have to recode my site for every change. Therefore I'm looking for an open source frame work which can:
Take an XML file with a known structure and constraint (via an XML schema or anything else).
Generate a ASP.NET based editing environment , allowing people to safely manipulate the xml file.
Be very friendly where people make mistakes.
Any suggestions?
How about creating an HTML form using an XSL Transform of the XML file? This way, you can surface the parameters into form fields. Using JQuery, you would even be able to offer re-ordering and the like.
A framework may be a little heavy for this task.