Author |
Topic |
|
joracine
Senior Member
36 Posts |
Posted - Jun 18 2008 : 09:15:00 AM
|
Wouldn't be interesting to have variable modifiers, such as upper/lowercase, space to underscore, year of date, etc.
For example, I normally create my header files as such:
#ifndef _"namespace of file in uppercase"_"filename"_H_
#define _"namespace of file in uppercase"_"filename"_H_
namespace "namespace of file"
{
} // namespace "namespace of file"
#endif
which gives something like:
#ifndef _MYNAMESPACE_MYFILE_H_
#define _MYNAMESPACE_MYFILE_H_
namespace mynamespace
{
} // namespace mynamespace
#endif
But I have to use two different variables in my VASnippet form: $NamespaceUpper$ and $Namespace$ and right twice the same thing. Couldn't there be a "to upper" modifier? For example, one could use: $Namespace$ and then use $Namespace^$ to write it in upper base, or $upper(namespace)$...
Thanks!
|
|
feline
Whole Tomato Software
United Kingdom
19014 Posts |
Posted - Jun 18 2008 : 4:12:49 PM
|
It is an interesting idea. My main concern is simply that no one is going to use this
Depending on your IDE are you aware of the CTRL-U and CTRL-SHIFT-U keyboard shortcuts for converting selected text to upper or lower case? |
zen is the art of being at one with the two'ness |
|
|
joracine
Senior Member
36 Posts |
Posted - Jun 18 2008 : 4:28:06 PM
|
Hahaha, no one will use it? I will ;o) No, seriously, I understand where you're coming from.
I am not sure I totally agree, but you might very well be right. In any case, I suspect it would be an quick and easy feature to add.
And, yes, I know the CTRL-SHIFT-U. I also know how to open my .cpp file to get to the definition of a method, but I'd rather use VAX and do alt-o... You see my point? :)
Anyhow, thanks for taking the time to answer.
|
|
|
hotzenplotz
Senior Member
Austria
34 Posts |
Posted - Jun 18 2008 : 5:47:09 PM
|
You're not the only one :) I was looking for "toupper()" function/modifier in "surround by" snippets too. I was trying to create include-guards like
#ifndef MYNAMESPACE_MYFILENAME_HPP_INCLUDED
... Just looks wrong to me if an include-guard define isn't all upper case...
|
Use the source, Luke!
|
|
|
feline
Whole Tomato Software
United Kingdom
19014 Posts |
Posted - Jun 19 2008 : 4:43:23 PM
|
Two people looking for the same thing, perhaps this is useful after all So how can we sensibly add this to Snippets without complicating things?
I am wary of ^ as a modifier character. I like the function calls "upper" and "lower" since they are simple, I just don't want people to start thinking of snippets as a programming language.
It turns out there was already a feature request for something like this, it was just not very clear how it was supposed to work. So I have suggested the two functions "upper" and "lower"
case=2765 |
zen is the art of being at one with the two'ness |
|
|
joracine
Senior Member
36 Posts |
Posted - Jun 20 2008 : 09:19:20 AM
|
I understand why you don't want the snippets to become a programming language. But I still think snippets have enormous potential. I would agree with you, I think you should use something like upper() and lower(), since it provides greater flexibility for future expansion of the functionality and because it feels more natura to us, programmers.
So when is snippets.NET coming out? :D |
|
|
feline
Whole Tomato Software
United Kingdom
19014 Posts |
Posted - Jun 20 2008 : 10:07:07 AM
|
snippets.NET, you probably need to try the IDE's macro system if you want something that clever |
zen is the art of being at one with the two'ness |
|
|
support
Whole Tomato Software
5566 Posts |
Posted - Apr 11 2012 : 12:23:53 AM
|
case=2765 is implemented in build 1903 |
|
|
FlawedLogic
Senior Member
United Kingdom
34 Posts |
Posted - May 01 2012 : 05:42:01 AM
|
I have wanted this as well, however it seems not to have been implemented quite right.
I tried to use it on a member variable and encapsulate field (in C++) with the following definition:
$end$const $SymbolType$& Get$SymbolName$() const { return $SymbolName$; } void Set$SymbolName$(const $SymbolType$& $SymbolName_Lower$) { $SymbolName$ = $SymbolName_Lower$; }
However whereas without the _Lower suffix it will use the variable the cursor is in, or the selected text, using the _Lower suffix it *always* prompts me to enter the symbol name. Am I doing something wrong? |
|
|
feline
Whole Tomato Software
United Kingdom
19014 Posts |
Posted - May 01 2012 : 9:58:28 PM
|
Unfortunately the current form of the "_Lower" and "_Upper" modifiers only work on user variables, i.e. variables that prompt you for input. I have put in a feature request to allow these to be used on built in keywords to see what our developers make of this:
case=66480
At a guess, this was not done at first since some of the built in keywords, like $MethodName$ and $ClassName$ are inserting a case sensitive string, and it does not normally make sense to modify this. |
zen is the art of being at one with the two'ness |
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - Feb 26 2014 : 7:56:07 PM
|
Encapsulate field supports $generatedPropertyName$.
It generates the same property name as $GeneratedPropertyName$ except that first letter is lower-case. |
|
|
FlawedLogic
Senior Member
United Kingdom
34 Posts |
Posted - Sep 07 2015 : 04:28:47 AM
|
Apparently case 66480 was added to build 2047 but the example I gave above (May 1 2012) still does not work. |
|
|
accord
Whole Tomato Software
United Kingdom
3287 Posts |
Posted - Sep 07 2015 : 2:31:58 PM
|
*ah* That case was about to allow VA Snippet "_Lower" and "_Upper" work on built in keywords.
Sorry for about this misunderstanding.
I have put in a feature request to allow Upper and Lower to work on user input:
case=91884 |
|
|
FlawedLogic
Senior Member
United Kingdom
34 Posts |
Posted - Sep 08 2015 : 01:54:49 AM
|
Thanks.
In case you were wondering why, our coding standards state that stack variables (i.e. locals and parameters) should be in all lower case with underscores if necessary (to reflect their temporary nature), and members are capitalised so this would allow me to comply without any extra editing. This is actually a rule I'm quite fond of, the style gives you insight into scope, preferable in my eyes to everything being camel case as is so often the case these days. |
|
|
|
Topic |
|