Tweets by @Actipro
Please take some time to learn more about us and our product offerings.
As mentioned in one of our previous posts, we’ve been working on a port of our SyntaxEditor Web Languages Add-on from WinForms to the WPF version of SyntaxEditor. We’re finishing up some last features on it before it will be ready to launch alongside WPF Studio 2010.2 in the coming weeks.
The advanced XML syntax language implementation in the add-on allows you to specify XML schemas to use for validation and to drive automated IntelliPrompt for the end user. In the previous post on the subject we showed how to create an XHTML editor in a few lines of code with automated IntelliPrompt popups.
One feature we just implemented was the ability to properly support xs:any nodes defined in the XML schemas. xs:any allows a schema to indicate that elements from any, other, or specific namespaces can be included as content within another element.
Best of all, we ported this new functionality back to the WinForms Web Languages Add-on too!
Let’s see an example…
Here is the WPF SyntaxEditor showing an XSLT document loaded. The XSLT is doing a transform to HTML. In the screenshot the mouse is over the xsl:value-of element, showing a quick info tip. Now let’s start typing a new start tag… More...
We noticed this morning that FeedBurner hasn’t been publishing our blog posts in the RSS feed for the last couple weeks. The problem appears to be that our discussions on the new grammar framework were very long and created a feed size larger than 512KB. At that threshold, FeedBurner stops publishing the blog. This is good to know for anyone out there who uses FeedBurner. We resolved the issue by temporarily reducing the number of items in the feed.
Make sure you click on over to our http://blog.actiprosoftware.com and take a look at the posts we’ve made recently that may not have shown up in your RSS feed.
Here’s a quick list of recent posts that you may have missed:
We’ve been hard at work on WPF Studio 2010.2, which we should have out in September. One new product that will ship along side of it is a port of our Web Languages Add-on that we have for the WinForms SyntaxEditor.
This add-on has an advanced XML syntax language implementation that allows you to specify an XML schema set to provide validation and automated IntelliPrompt within the code editor, all with just a few lines of code. Let’s take a peek at a new HTML Editor demo we’re adding to WPF Studio to show off the add-on:
Here we have the sample that shows an XHTML document loaded. We’ve configured our advanced XML language with an XSD we downloaded from the W3C for XHTML. And with a few lines of code, voila, instant HTML editor! More...
In the previous post, we added error handling to our Simple language grammar. This allowed the grammar parser to recover from any invalid syntax in a document being parsed, and to still produce an AST.
It concluded the three basic stages in building a grammar:
Now what happens when in the middle of the grammar design and something is not parsing as intended? It can be tricky to know what the parser is “thinking” since it’s a bit of a black box.
To solve this issue, we’ve built complete debugging capabilities directly into the parser and have even enhanced the Language Designer application to have a complete debugger UI! More...
We’ve just published build 102 of Silverlight Studio. Major updates include:
Head over the announcement post for details of what’s new.
In the previous post, we saw how the grammar framework supports callbacks nearly everywhere in the EBNF terms. You are able to inject custom code before and after any term is matched. One of the most important injection points is the Error callback since that allows you to tell the parser how to handle errors.
In today’s post, we’ll examine the importance of adding error handling. We’ll enhance our Simple language grammar to properly recover from nearly any invalid syntax in a document so that it can continue parsing the rest of the document.
An error occurs when one or more terminals is expected by the parser (per the grammar) but a different token is found at the current location in the document.
By default when this scenario occurs, the parser will report a parse error if a single terminal is expected. If there is more than one terminal that could be next, and if the containing non-terminal has an error alias set, it will report a parse error instead. This behavior is described in the previous post.
Following any possible error reporting, the parser will immediately exit the current non-terminal and will continue up the non-terminal stack, exiting each one as it goes until the root non-terminal is reached and exited itself.
Thus the result is that if any invalid syntax is found in a document, parsing stops at that point and no AST will be built. That’s definitely not good since we expect code being parsed from our SyntaxEditor control editing to be invalid most of the time. End users are continuously typing in it.
As shown in the previous post, the grammar framework has a lot ways to recover from errors, and they are easy to add. More...
In the previous post, we optimized the tree construction output of our Simple language to be very concise. The next step in building a grammar is to make sure that it properly handles errors. After all, since this grammar framework is intended to be used with SyntaxEditor, our code editor control, we have to assume that most of the time the document’s code passed to our grammar parser will be in an invalid state. The user is continuously typing and modifying it.
In today’s post we will look at the various callbacks that are available to you, probably the most important of which are error handling callbacks. We’ll also dig into error handling options.
As we’ve seen in the previous posts in this series, our entire grammar is built directly in C# or VB code. We do not do code generation like a lot of other parser generators do. A benefit of this is that you can interact directly with objects in the grammar. More...
In the previous post we gave an introduction to the powerful tree construction mechanism that is built into the grammar/AST framework and talked about each of the built-in tree construction nodes that are available. We also mentioned that for very rare scenarios where advanced logic is needed to build a particular AST node, you can create and inject your own ITreeConstructionNode-based classes to handle the task.
In today’s post, we’re going to revisit the Simple language and will enhance our grammar productions so that we make the resulting AST very concise. More...
We also showed how the grammar automatically generates an AST of the parsed document for you. The generated tree generally has much more information than what is useful though. Today’s post is going to show how we can completely customize the AST output so that it focuses only on the information we care about.
Our grammar/AST framework has an extremely powerful tree construction mechanism with numerous built-in helper methods to do common tree construction tasks. You also have the ability to create completely custom tree construction nodes via C#/VB code if you like.
The default tree constructors will output nearly everything that is parsed. Each AST node that is generated automatically contains the offset range of the text that created it. More...
In the previous post we gave a detailed introduction to symbols, EBNF terms, and how you can translate a language’s EBNF specification to our grammar framework.
The first thing to do when building a Grammar for a language is to locate the language specification for the language. Nearly all programming languages have some sort of formal EBNF specification that tell parsers and compilers how to interpret their code. More...