I understand this as a new requirement. You wish to have a new Moritz command like this:
@MRTZ_backGroundColor 12FFCD0
Where 12FFD0 defines the background-color of an activity-block or a nassi-shneidermann line.
Please agree or correct me and give me some time to think about how to realize it. If I understood you right, it should be not a great thing. But since Moritz supports currently 4 languages (C/C++, Python, Pascal and Matlab) I have to implement it 8 times (uml-activity and nassi-shneiderman).
Thus please check if I understood you right and post a comment about. Once I have a first version available I come back.
Best regards,
Eckard Klotz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A Moritz command is at least valid for one complete source-element, what means in your case for the complete if-command including its else-part and and its child-commands. The Moritz commands beginBlock and endBlock can be used only to extend the command for more than one source-element but not to reduce it to parts of one.
The reason is, that the source-parser converts the active-code into a tree-structure where every source-element is a node or a part-tree. After that the comments will be merged in. Moritz commands will be always placed before the root-node of a source-element-tree.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Attached you will find a zip-file that contains the implementation of @MRTZ_backGroundColor. As parameter it expects a 6 digit hex-value
This is an example that shows how to use it.
TYPE command_NSD__function_backGroundColor(TYPE Parameter)
// this is the modell of a function
// with comments behind of the commands
{
// @MRTZ_backGroundColor 0088FF
// @MRTZ_beginBlock
TYPE ReturnValue; //comment ReturnValue
TYPE_A LokalVariable_1 = Value1; //variable-comment 1
TYPE_A LokalVariable_2; //variable-comment 2
TYPE_Z LokalVariable_N = ValueN; //variable-comment N
//@MRTZ_endBlock
operation_1( & LokalVariable_1,Parameter); //operation-comment 1
LokalVariable_2 = operation_2(LokalVariable_N);
//operation-comment 2
// @MRTZ_backGroundColor 12FFCD0
if(LokalVariable_1 == LokalVariable_2)
//statement-comment for true
{
ReturnValue = DefaultValue; //operation-comment for true
}
else //statement-comment for false
{
// @MRTZ_backGroundColor FF8800
while(ParameterStatment) //loop-comment
ReturnValue = operation_3(); //operation-comment 3
};
return(ReturnValue);
}
As already mentioned this command behaves like all other Moritz commands. It influences the following source-element and its child-elements. To change the colour for the child-elements back the command has to be there again with the colour used before (FFFFFF for white) perhaps together with MRTZ_beginBlock and MRTZ_endBlock for a group of child-elements.
To install the content of the zip-file rename the sub-folder with the same name in the folder LangPack of your distribution and copy the content of the zip-file into this folder LangPack.
Please note for some reasons oder graphviz-packages (for example 2.28) seem to have a problem with nested sub-graphs (used for the implementation). Please ensure that you use the newest graphviz-package (currently 2.38)
Best regards,
Eckard Klotz
PS. Since I currently rework the source-parser to speed-up the process and to be independent from boost I have not the time to for a detailed development or test of this new Moritz command. Parallel to the parser I currently work on providing message sequence charts what I need for my own work. Thus please excuse if I'm currently not able to provide you a more sophisticated solution.
Please find attached a newer version of the zip-file I provided before. To install the content of the zip-file rename the sub-folder with the same name in the folder LangPack of your distribution and copy the content of the zip-file into this folder LangPack.
Please note that I provide this zip-file not to solve the bug you reported but since I recognized that the older zip-file based on an older configuration and contains not the patch I provided you 2015-03-06 to solve your bug-report "$" is replaced by "__" by xml2abc during xml to dot conversion.
You will see that your current example still not works. Furthermore I will not spent more effort to solve this since I came to the conclusion that the implementation of a command like backGroundColor makes no sense.
Don't take me wrong. It is not that I can not understand your wish to influence the diagram-properties. But doing this with single Moritz commands has a deep impact to the source, you don't want to have. Today we discuss only to change the background-colour of an activity. But others may wish to change its foreground colour, the font or properties of the edges also. The result would be a source-code like this:
If every possible property has its own command your source may contain more Moritz commands than active code.
Somehow the user has to define a set of properties somewhere else for example in the xml configuration and than he has to use a command like changeProperty with a key word as parameter the user has associated with a special property-set. This makes it necessary to change the binary also (until now I just changed some configuration-files). But this is something I can't do in the moment, since I currently rework the parser binary (abc2xml) what takes some more time. Furthermore I have to think about what this means for the other output-formats. Today Moritz creates not only dot-files to display uml like activity-diagrams but also html-files to display nassi-shneiderman diagrams, files for MscGen to display message-sequence charts and real source-code derivatives to support software-tests.
This means I have to check very carefully the influence of implementing a new Moritz command to all this features.
I will come back to this once I rework the generator-tool (xml2abc) again. But this will not be this year. If I'm able to do this some when next year I can not promise. This depends on my professional work-load and my own requirements, since I started this hobby project to support my professional work and provide just the result for the common use. What not means that I'm not interested in requirements of the community but since an open source programmer need some body who pays him he has to prioritize his professional needs. I hope you understand this.
then your patches in this topic is absolutely useless and really makes no sense.
Anyway, thanks for at least trying to make a working implementation of MRTZ_backGroundColor.
What you call the "simplest possible case" is actually the most difficult case.
With your example you point out the current problem, what means you will have always a failure if you use the command for the last active statement of a function.
How ever as I already wrote currently I don't have the time to finish this and I will not follow the currently started implementation any more, since it leads into wrong direction. Thus I cancelled the work and provide the the result as it is.
If it is not satisfying you even in those cases where it works, than don't use it and step back to the configuration you used before.
I think in this discussion we are currently on the point we stand at the end of our discussion about your post Switch statement's dot graph is missing some parts from 2015-03-07. As somebody who programs in C/C++ since nearly 20 years and is using this tool for documenting the sources I wonder what is your original intention. I would never use a kind of highlighting in such small functions you use as example-code. To be honest today I avoid using other colours in the automated generation of code documentation because this is something you have to maintain frequently or it starts to become misleading over the time. Furthermore since a Moritz command is not commenting the code but is an add-on comment to control an external tool, your source code it self may become for a third person (code-review) unclear. Thus please keep always in mind a beautiful diagram is helps you not if your source-code is not understandable any-more.
Best regards,
Eckard Klotz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Of course I must have to rollback your failed attempt to implement MRTZ_backGroundColor as it useless for anybody.
Regarding the post about "Switch statement's dot graph is missing some parts from 2015-03-07",
I have never used goto statement in my code at all but there are legacy codebases which still with us. You better ask the people who are involved in C++ language development why they support it. But it's not the excuse for your inability to support C/C++ standards. If it were easy, you would already have done it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
... But it's not the excuse for your inability to support C/C++ standards. ...
If we are talking about C/C++ standards, what standards are we talking about? Over the decades this programming language was frequently redefined and every some years a new standard will be defined. Furthermore depending on the domain you are working for additional restrictions will be defined . For example I work in the automotive industry and using goto in today's applications is strictly forbidden even it is done by using legacy-code.
Have you ever thought about that the support of the command goto while generating UML like activity diagrams or nassi-shneiderman diagrams is actually a contradiction in terms since this diagrams were established to avoid spaghetti-code.
Even C/C++ contains still some historical ballast, it is definitely not my goal to support everything.
Best regards,
Eckard Klotz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Something like @MRTZ_pointOut but without "extra-title" param, only background-color.
Hello Mr. Nelson
I understand this as a new requirement. You wish to have a new Moritz command like this:
@MRTZ_backGroundColor 12FFCD0
Where 12FFD0 defines the background-color of an activity-block or a nassi-shneidermann line.
Please agree or correct me and give me some time to think about how to realize it. If I understood you right, it should be not a great thing. But since Moritz supports currently 4 languages (C/C++, Python, Pascal and Matlab) I have to implement it 8 times (uml-activity and nassi-shneiderman).
Thus please check if I understood you right and post a comment about. Once I have a first version available I come back.
Best regards,
Eckard Klotz
To define background color of next generated node in dot diagram.
More detailed example:
main() {
// @MRTZ_backGroundColor 00ff00
if (cond1) {
// @MRTZ_backGroundColor ffcc33
puts("cond1");
} else {
puts("other");
}
getchar();
// @MRTZ_backGroundColor ee0000
return 1;
}
Hello Mr. Nelson.
Please note that a Moritz command is always influencing not only the following source-element but its child-elements also.
Thus your would lead to the diagram attached as "SampleEgo2.gif"
This means for your diagram attached in your comment above you need an additional command like in this extended example source:
main()
{
// @MRTZ_backGroundColor 00ff00
if (cond1)
{
// @MRTZ_backGroundColor ffcc33
puts("cond1");
}
else
{
// @MRTZ_backGroundColor ffffff
puts("other");
}
getchar();
// @MRTZ_backGroundColor ee0000
return 1;
}
Even this will be a new Moritz command it will be my goal to implement it with the same behaviour like the others.
Best regards,
Eckard Klotz
Last edit: Eckard Klotz 2015-04-19
Ok. In such a case I expect it will be possible to use @MRTZ_beginBlock/@MRTZ_endBlock to limit the scope of @MRTZ_backGroundColor.
Example:
Last edit: Benito C. Nelson 2015-04-19
No sorry, this is not possible.
A Moritz command is at least valid for one complete source-element, what means in your case for the complete if-command including its else-part and and its child-commands. The Moritz commands beginBlock and endBlock can be used only to extend the command for more than one source-element but not to reduce it to parts of one.
The reason is, that the source-parser converts the active-code into a tree-structure where every source-element is a node or a part-tree. After that the comments will be merged in. Moritz commands will be always placed before the root-node of a source-element-tree.
Hello Mr. Nelson.
Attached you will find a zip-file that contains the implementation of @MRTZ_backGroundColor. As parameter it expects a 6 digit hex-value
This is an example that shows how to use it.
As already mentioned this command behaves like all other Moritz commands. It influences the following source-element and its child-elements. To change the colour for the child-elements back the command has to be there again with the colour used before (FFFFFF for white) perhaps together with MRTZ_beginBlock and MRTZ_endBlock for a group of child-elements.
To install the content of the zip-file rename the sub-folder with the same name in the folder LangPack of your distribution and copy the content of the zip-file into this folder LangPack.
Please note for some reasons oder graphviz-packages (for example 2.28) seem to have a problem with nested sub-graphs (used for the implementation). Please ensure that you use the newest graphviz-package (currently 2.38)
Best regards,
Eckard Klotz
PS. Since I currently rework the source-parser to speed-up the process and to be independent from boost I have not the time to for a detailed development or test of this new Moritz command. Parallel to the parser I currently work on providing message sequence charts what I need for my own work. Thus please excuse if I'm currently not able to provide you a more sophisticated solution.
Just have installed ansi_c.zip and graphviz-2.38 but getting a broken output on this simple test case.
Please have a look at it.
Input:
Output:
Hello Mr. Nelson.
Since I'm too busy this week I will come back later to this with adetailed answer.
Please excuse.
Best regards,
Eckard Klotz
Hello Mr. Nelson.
Please find attached a newer version of the zip-file I provided before. To install the content of the zip-file rename the sub-folder with the same name in the folder LangPack of your distribution and copy the content of the zip-file into this folder LangPack.
Please note that I provide this zip-file not to solve the bug you reported but since I recognized that the older zip-file based on an older configuration and contains not the patch I provided you 2015-03-06 to solve your bug-report "$" is replaced by "__" by xml2abc during xml to dot conversion.
You will see that your current example still not works. Furthermore I will not spent more effort to solve this since I came to the conclusion that the implementation of a command like backGroundColor makes no sense.
Don't take me wrong. It is not that I can not understand your wish to influence the diagram-properties. But doing this with single Moritz commands has a deep impact to the source, you don't want to have. Today we discuss only to change the background-colour of an activity. But others may wish to change its foreground colour, the font or properties of the edges also. The result would be a source-code like this:
If every possible property has its own command your source may contain more Moritz commands than active code.
Somehow the user has to define a set of properties somewhere else for example in the xml configuration and than he has to use a command like changeProperty with a key word as parameter the user has associated with a special property-set. This makes it necessary to change the binary also (until now I just changed some configuration-files). But this is something I can't do in the moment, since I currently rework the parser binary (abc2xml) what takes some more time. Furthermore I have to think about what this means for the other output-formats. Today Moritz creates not only dot-files to display uml like activity-diagrams but also html-files to display nassi-shneiderman diagrams, files for MscGen to display message-sequence charts and real source-code derivatives to support software-tests.
This means I have to check very carefully the influence of implementing a new Moritz command to all this features.
I will come back to this once I rework the generator-tool (xml2abc) again. But this will not be this year. If I'm able to do this some when next year I can not promise. This depends on my professional work-load and my own requirements, since I started this hobby project to support my professional work and provide just the result for the common use. What not means that I'm not interested in requirements of the community but since an open source programmer need some body who pays him he has to prioritize his professional needs. I hope you understand this.
Best regards,
Eckard Klotz
if you don't be able to fix even the simplest possible case:
then your patches in this topic is absolutely useless and really makes no sense.
Anyway, thanks for at least trying to make a working implementation of MRTZ_backGroundColor.
Hello Mr. Nelson.
What you call the "simplest possible case" is actually the most difficult case.
With your example you point out the current problem, what means you will have always a failure if you use the command for the last active statement of a function.
How ever as I already wrote currently I don't have the time to finish this and I will not follow the currently started implementation any more, since it leads into wrong direction. Thus I cancelled the work and provide the the result as it is.
If it is not satisfying you even in those cases where it works, than don't use it and step back to the configuration you used before.
I think in this discussion we are currently on the point we stand at the end of our discussion about your post Switch statement's dot graph is missing some parts from 2015-03-07. As somebody who programs in C/C++ since nearly 20 years and is using this tool for documenting the sources I wonder what is your original intention. I would never use a kind of highlighting in such small functions you use as example-code. To be honest today I avoid using other colours in the automated generation of code documentation because this is something you have to maintain frequently or it starts to become misleading over the time. Furthermore since a Moritz command is not commenting the code but is an add-on comment to control an external tool, your source code it self may become for a third person (code-review) unclear. Thus please keep always in mind a beautiful diagram is helps you not if your source-code is not understandable any-more.
Best regards,
Eckard Klotz
Of course I must have to rollback your failed attempt to implement MRTZ_backGroundColor as it useless for anybody.
Regarding the post about "Switch statement's dot graph is missing some parts from 2015-03-07",
I have never used goto statement in my code at all but there are legacy codebases which still with us. You better ask the people who are involved in C++ language development why they support it. But it's not the excuse for your inability to support C/C++ standards. If it were easy, you would already have done it.
Hello Mr. Nelson.
... But it's not the excuse for your inability to support C/C++ standards. ...
If we are talking about C/C++ standards, what standards are we talking about? Over the decades this programming language was frequently redefined and every some years a new standard will be defined. Furthermore depending on the domain you are working for additional restrictions will be defined . For example I work in the automotive industry and using goto in today's applications is strictly forbidden even it is done by using legacy-code.
Have you ever thought about that the support of the command goto while generating UML like activity diagrams or nassi-shneiderman diagrams is actually a contradiction in terms since this diagrams were established to avoid spaghetti-code.
Even C/C++ contains still some historical ballast, it is definitely not my goal to support everything.
Best regards,
Eckard Klotz