Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
 All Forums
 Visual Assist
 Feature Requests
 Reverse fields

You must be registered to post a reply.
Click here to register.

Screensize:
UserName:
Password:
Format: BoldItalicizeUnderlineStrikethrough Align leftCenterAlign right Insert horizontal ruleUpload and insert imageInsert hyperlinkInsert email addressInsert codeInsert quoted textInsert listInsert Emoji
   
Message:

Forum code is on.
Html is off.

 
Check to subscribe to this topic.
   

T O P I C    R E V I E W
AdyR Posted - Aug 11 2006 : 10:51:10 AM
One feature that I think would be nice to see one day is a command to reverse the fields, eg before:

dialog.a = a;
dialog.b = b;
dialog.c = c;

then highlight the lines and use the reverse command to give:

a = dialog.a;
b = dialog.b;
c = dialog.c;

also to work with, before:

ar << a << b << c << d << e;

after:

ar >> a >> b >> c >> d >> e;

8   L A T E S T    R E P L I E S    (Newest First)
AdyR Posted - Aug 17 2006 : 07:02:37 AM
I used a plugin in VC6 called CodeWiz, which did this for me but unfortunately it is not compatible with the later environments. I believe that did cope with get / set methods but I canG??t be sure.
As I still tend to use the resource wizard to build dialog boxes and assign variables to control values (because it is quick and easy and I am lazy) my dialogs do still use direct access to the member variables and I have a lot of old code to maintain.
khb Posted - Aug 15 2006 : 02:55:51 AM
Good ones! Of course, I was just aiming at expressions like:
  variable1 = variable2;
Well, of course, the lines that came to your mind should read like this after conversion:
  dialog->setA(a);
  dialog->setB(b - 3);
  dialog->setC(*c);


Anyway, waiting for a feature is no problem at all. Every new build brings new cool features, so updating is always like christmas for me

Regards,
Marcus.
feline Posted - Aug 14 2006 : 6:10:12 PM
my concern is more about this:


    int a = dialog->getA();
    b = dialog->getB() + 3;
    *c = dialog->getC();

experience suggests that people will start with things like this, and then go on from there. i understand the appeal, it is simply that i am not sure how best to define and limit the description of the feature.

in theory you should be able to wrap up a regular expression find and replace as a macro, and then assign it a button. not ideal, i know, but it is available a lot quicker than waiting for a feature request to be implemented
khb Posted - Aug 14 2006 : 1:35:12 PM
It's C++. And, yes, I try to code as OO as possible. However, I also have to maintain a lot of legacy code. Of course, I'd like to re-implement everything, but that's not my job By the way, even some standard MFC dialogs (open file?) have no access functions. You directly access the variables. Doing a regular expression search and replace is quite unhandy in comparison to clicking a menu item called "Reverse expression". Anyway, if you are totally against this idea, then just forget about it.

Regards,
Marcus.
feline Posted - Aug 13 2006 : 2:16:03 PM
out of interest what language is this? when i am exchanging data with dialogs i often have a lot of "get this" functions, but i try to organise things so that i can populate the dialog by calling it with a single object.

thinking about my own code, often i have function calls, or accessors on objects to produce the values, which would make the code blocks harder to reverse.

it is this very "vague" nature of the idea that concerns me. what exactly are we asking VA to do here? and is this something prone to major feature creep?

i am wondering if a regular expression search and replace is the answer here. it very much depends on the details, but basically you have "leading white space" "block of characters" "equals sign" "block of characters" "semi colon"

*experiments* using VS2003 the following regular expression find and replace is *nearly* right:

find {\\b*}{.*} = {.*};
replace \\1\\3 = \\2;

the first capture block does not seem to be picking up the leading white space. i think it just needs a little fiddling to get this to work correctly. i found the following help page sort of useful:

http://msdn2.microsoft.com/en-us/library/2k3te2cs.aspx
khb Posted - Aug 13 2006 : 03:47:19 AM
For me it's the other way round: The first block is what happens more frequently to me than the second one. As indicated by Ady's example, I have it quite often when exchanging data with dialogs. I also have it in some other case.

Regards,
Marcus.
feline Posted - Aug 12 2006 : 3:53:49 PM
your two examples appear to be quite different thoughts.

how often do you need to do something like the first block?

the second block makes a bit more sense. in this case the easiest solution seems to be to select the code and use "find and replace" to change "<<" to ">>"
khb Posted - Aug 11 2006 : 12:49:28 PM
That would be really cool! I'd like to have it, too!

Regards,
Marcus.

© 2023 Whole Tomato Software, LLC Go To Top Of Page
Snitz Forums 2000