Changing the code structure




arbitrary line changes

The legibility of a source program is considerably complicated if the code lines
are either combined or split over several lines in a meaningless way.

This takes place by line joinings xxx: yyy: zzz

or line breaks xxx _
yyy _
zzz _

Here CrunchCode goes to the limits permitted by syntax.
The resulting chaotic overall impression is a deterrent and
in many cases will prevent any attempt to step through the code.

This specifications defines how often arbitrary line breaks or joinings are inserted.

0% = no line breaks / no joinings

100% = in each appropriate position

The value should normally be set to 50%.
This results in a balanced mix of line breaks and line joinings.


no line joinings after procedures

If by line coupling after a procedure–call other commands stand,
then it can come in rare cases on account of a VBA error
to problems by the execution of the affected procedures.

Should this be the case, then activating this option will
prevent the desegregation of a procedure with any subsequent commands in one source–code line.

But this reduces the camouflage effect a little.


Camouflaging of type declarations

Type declarations as for example "Dim XXX As Boolean" can give clues
on the purpose of the in each case declared object.

The camouflage effect increases if all declarations instead made
with the universal data type "Variant":

insetad of Dim XXX As Boolean
Dim YYY As String

now Dim XXX As Variant
Dim YYY As Variant

Attention!

However, the memory consumption in large projects increases thereby significantly!

Moreover, it can lead (conditioned by a higher data administration expenditure)
to a reduction of the speed.

Besides, this approach can be applied only to simple data types:

Boolean
Byte
Currency
Date
Double
Integer
Long
Single
String
Variant

Hint:
CrunchCode not simplifies data types if following conditions are given:

– user–defined types
  and all declarations within a "Type ... End Type" statement

– string types with length specification
  e.g. Dim XXX As String * 1024

– type specifications in the parameter list of event handler procedures
  e.g. UserForm_QueryClose(intCancel As Integer, intCloseMode As Integer)

– declaration of Object Types
  e.g. Dim XXX As UserForm
  activate for this the option "Object declarations camouflage"

– Public variables, if they were declared
  in class modules that are used with "Implements" within the project

– declarations combined with

Declare
WithEvents
ReDim
As <Type> *
() As <Type>
As New <Type>


Object declarations camouflage

Declarations that assign object properties such as "Dim XXX As Workbook"
reveal immediately the purpose of the declared object.

They unproblematic can be replaced by a unified "... As Object".

However, CrunchCode unifies object types NOT if the following conditions are true:

– user–defined classes

– Public variables, if they were declared
  in class modules that are used with "Implements" within the project

– declarations combined with "As New <Class>"

In exceptional cases, it can come to problems by to the late–binding ("As Object").
The concerned objects are not working properly or cause run–time errors.
You can exclude these with "Exceptions" from the object–camouflage.


Code ignore in the area
'#CC_Begin_Skip ... '#CC_End_Skip

This option allows you to exclude parts of the source code from the processing.
Excluded sections of code you must mark by two comment lines:

'#CC_Begin_Skip \
...   > two COMMENT lines!
'#CC_End_Skip /

All lines between these markers are IGNORED by CrunchCode during the processing
and inserted in their original form into the resulting project.

Attention!

* Make sure that no syntax errors or runtime errors arise by the ignoring of code lines.
   CrunchCode DOES NOT CHECK THIS CASE!

* before '#CC_Begin_Skipand '#CC_End_Skip may no instructions stand within a line.

* If  '#CC_End_Skip  is missing , then the source code will be deleted until the end of the module!

* Areas that are marked with '#CC_Begin_ ... '#CC_End_ may not overlap each other!


Code delete in the area
'#CC_Begin_Delete ... '#CC_End_Delete

With this option, you have the option to DELETE parts of the source code before processing.
These will not assumed in the finished project.
In this way you can for example delete algorithms, that were only inserted for testing purposes.

To delete sections of code you must mark by two comment lines:

'#CC_Begin_Delete \
...   > two COMMENT lines!
'#CC_End_Delete /


Example: '#CC_Begin_Delete
If lngX = lngY Then
      Debug.Print "Break at position " & lngX
      Exit Sub
End If
'#CC_End_Delete

All lines between these markers will DELETED by CrunchCode.

Attention!

* Make sure that no syntax errors or runtime errors arise by the ignoring of code lines.
   CrunchCode DOES NOT CHECK THIS CASE!

* before '#CC_Begin_Delete and '#CC_End_Delete may no instructions stand within a line.

* If  '#CC_End_Delete  is missing , then the source code will be deleted until the end of the module!

* Areas that are marked with '#CC_Begin_ ... '#CC_End_ may not overlap each other!


Writing back results as entire modules

CrunchCode usually writes the processing results line by line back into the VBA modules.
This method ensures a maximum of safety and process control.

But in some cases, it may be problems, because Excel
already starts in background the compiling of the transferred lines.

With this option you force a write–back by importing of COMPLETE VBA modules.
These problems are thereby avoided.
However, the process monitoring is suspended during this step.


Procedures randomly mix

Increase in camouflage by arbitrary rearrangement of the procedures within the module.

This concerns in particular procedures that additionally generated by CrunchCode
(e.g. for the camouflaging of strings).

These are put without activation of this option always to the end of a module
and are thereby quicker identifiable.


Line numbering

Numbering of all lines in the finished project
for the application of user defined error handlers.

The line number of an occurred error can be determined with the command "Erl".


Random comments insert

Increases the camouflage effect by inserting of random comments

These texts are generated from the contents of the already camouflaged source–code–lines
and ensure a significant visual confusion.

Frequency: Specifies how often comments are inserted

Length: Length of comments (number of characters)
The length of the resulting line
is but limited to max. 950 characters.

Comments are to be generated from:
Mixing ratio for generation of the comments

Random text: Comments only consist of random characters
Source code: Comments are derived from source code lines

Notes:
– a very large number or length of comments
  leads to a strong increase of the file size!

– within source code areas, that are by '#CC_End_Skip...'#CC_Begin_Skip
  excluded from processing, no comments are inserted

Tip: The highest optical effect achieves random comments when the option
"Frequency of line breaks" is set to 0%, i.e. is turned off.


Insert compiler constant

Inserts the following declaration of a compiler constants in each processed a VBA module:

#Const XXX = True XXX = Name of the compiler constant

This gives you the possibility to distinguish between the processed
and the unprocessed state of your project:

#If XXX Then
...
Source code, which is effective if the project was processed by CrunchCode
...
#Else
...
Source code, which is effective if the project is in his original state
...
#End If

Attention!

The constant–name may neither be identical with a VBA keyword
nor a in your project declared identifier!


Comment in each module insert

With this option, you have the possibility to insert a comment
at the beginning of each module .

This is e.g. helpful for copyright notices.

The comment–sign  '  at the beginning of each line is added automatically by CrunchCode.