This means that if you choose to install the nightly build now, the installation will be titled “Regionerate Public Beta 2 (v0.7.3.0)”.

This seems a bit messy, in my opinion, as users might get confused and think that the nightly build is actually v0.7.3.0.

Do you have any suggestions on how to make this process more organized?

Thanks to some suggestions I came up with this solution and I wanted to share and hear your opinions on it before I dive into code.

There will be 3 different styles of symbols and every user will choose the one that works for him.

1. The default style will be the hidden dragon. (If you don’t know what this is, read the previous post) This will require no setup and will work for basic users. (Those who don’t have clashes with any other refactoring tools)

2. A prefix, the symbol we’ve grown so fond of.

3. A wrapper, which consists of a prefix and a suffix.

Symbols will be represented in an element called Configuration. (More on this coming up in another post)

Here is the symbol configuration which you will find in the default Code Layout document:

   1:  <CodeLayout>

   2:    <Configuration>

   3:      <Symbol>

   4:        <ApplyOnRegions>

   5:          <HiddenDragon />

   6:        </ApplyOnRegions>

   7:      </Symbol>

   8:    </Configuration>

   9:  </CodeLayout>

You can also choose a different symbol style, such as:

   1:  <CodeLayout>

   2:    <Configuration>

   3:      <Symbol>

   4:        <ApplyOnRegions>

   5:          <Wrapper Prefix="[" Suffix="]" />

   6:        </ApplyOnRegions>

   7:      </Symbol>

   8:    </Configuration>

   9:  </CodeLayout>

To allow easy migration for everyone, you will be able to use the Obsolete element to define one or more obsolete symbols, for example:

   1:  <CodeLayout>

   2:    <Configuration>

   3:      <Symbol>

   4:        <ApplyOnRegions>

   5:          <Wrapper Prefix="{" Suffix="}" />

   6:            </ApplyOnRegions>

   7:            <Obsolete>

   8:              <Prefix Value="[rgn]" />

   9:              <HiddenDragon />

  10:            </Obsolete>

  11:          </Symbol>

  12:    </Configuration>

  13:  </CodeLayout>

I hope most users wouldn’t even have to know this symbol hell exists, but those who have special needs will find this solution good enough. What do you think?

I’m pretty sure no-one really liked having “[rgn]” in front of Regionerated region declarations. Most users hated it but kept it, some users hated it and changed it to something minimal such as “*” while other users hated it and changed it to an empty string. (which caused trouble with comments and existing regions)

So I’ve decided to put a stop to it and kill the region symbol and allow Regionerate to operate without it. I wouldn’t have been able to do so if I wouldn’t have found this cheap trick: I just use ASCII character #255 instead of spaces.

ASCII character #255 (a.k.a. “The Hidden Dragon”) looks exactly like space and allows Regionerate to differentiate Regionerated regions from existing regions.
You can think of this as a hard-coded invisible symbol.

Take a look at this example:

   1:          #region Fields

   2:   

   3:          ... 

   4:   

   5:          #endregion

   6:   

   7:          #region My Stuff

   8:   

   9:          ... 

  10:   

  11:          #endregion

Even though these regions look the same, the first region is a Regionerated region and the latter is an existing region. How can I tell? The first one has the hidden dragon right after “#region” and “#endregion” (” “) and the second one has space (” “).

Crazy workaround, but it works. Anyway, this should be available on v0.6.6.5.

Regarding migration: New users will enjoy this the first time they Regionerate their code. However, users of versions prior to v0.6.6.5 might find this a bit annoying as Regionerate will treat symbolized regions as existing regions, causing code not to be Regionerated.

I can add some functionality to allow easier migration in v0.6.6.5 (something like a definition for “dead symbols” in the Code Layout document which will allow users to enter their old symbols, so Regionerate will automatically kill those), However this might take me some time and will delay this version.

The faster option will be to get rid of symbolized regions by a simple regular expression search & replace throughout the code. This will be a one-time task and should complete in a minute or two.

What do you think? Should I postpone this version for this one-time migration function or will you guys survive the regular expression search & replace? (I’ll post a short guide for you folks who aren’t familiar with regular expressions)

Please gimme your opinions on this before I continue. Thanks!

To do so, just specify “true” in the new IsOperator element under PutMethods. Exactly like filtering constructors.

   1:      <CreateRegion Title="Operators">

   2:        <PutMethods>

   3:          <Where>

   4:            <IsOperator Equals="true"/>

   5:          </Where>

   6:        </PutMethods>

   7:      </CreateRegion>

A new feature in v0.6.3.8 – support for delegates.

You can now easily put your delegates inside regions by using the PutDelegates statement in your Code Layout. The default Code Layout has been updated to automatically group delegates & events in the same region:

This results in the following code:

You can place your delegates by matching their name, visibility and any of their attributes. You can order your delegates by name & length. ]]> http://www.rauchy.net/regionerate/blog/2007/07/create-regions-for-delegates.html/feed 0 http://www.rauchy.net/regionerate/blog/2007/06/existing-regions-continued.html http://www.rauchy.net/regionerate/blog/2007/06/existing-regions-continued.html#comments Wed, 20 Jun 2007 22:18:00 +0000 rauchy http://www.rauchy.net/regionerate/blog/2007/06/existing-regions-continued.html After my previous post on the subject I have been doing some thinking and realized that it will be very annoying to not have any control on the symbol (the unique string that will appear at region declarations to help Regionerate distinguish between Regionerated regions and existing regions).

Here’s how I’ve solved it:

Inside the Code Layout XML file, the CodeLayout element has an optional string attribute called Symbol. You can use it to set your own symbol ( such as [*], [~] or any other kind of symbol )
If you don’t mention any symbol, it will use the default [rgn] symbol.

For example:

<CodeLayout Symbol=”[!]“>

If you do not want to distinguish Regionerate region from existing regions, all you need to do is set your symbol to an empty string as in

<CodeLayout Symbol=”">

This will make Regionerate treat existing regions the same as Regionerated regions. (since they both share the empty symbol, sort of…)

Note: Setting the symbol is possible only if you are using a custom Code Layout, the default Code Layout will use [rgn] as its symbol.