| Author |
 Topic  |
|
|
RickHodgin
Senior Member
44 Posts |
 Posted - Apr 11 2007 : 09:12:04 AM
|
I was thinking a good feature might be the ability to convert the tabs or white-spaces in a document to the setting for the current type of document (possibly through one of those two-key combos being added for case=5912).
To illustrate, The SemWare Editor has a built-in potpourri macro collection including one called TABUTIL. It has two opens, Entab and Detab. Based on editor settings, when converting it keeps the visual formatting of everything the same, it just removes or inserts tabs or white spaces where appropriate.
Another variation/option might be an "Auto-Replace on open?" which removes tabs or white spaces, and replaces them with the equivalent of whatever should be there based on the user's settings, whenever the file is loaded. |
|
|
RickHodgin
Senior Member
44 Posts |
Posted - Apr 11 2007 : 09:13:19 AM
|
| Also, for information, The SemWare Editor can be found at http://www.semware.com. |
 |
|
|
feline
Whole Tomato Software
United Kingdom
18940 Posts |
Posted - Apr 12 2007 : 07:49:58 AM
|
At a code formatting level I can see problems with this, since if the tab stop is set to 4, and you indent something with 6 spaces, what happens?
You can make this change currently by using the IDE's find and replace dialog. Entering spaces is easy, and for tab turn on regular expression mode and use \\t
I have just tried this in VS2003 and it works perfectly. Of course you may find some differences in how code is formatted doing it this way, but we have no current intention of getting into the whole question of code formatting:
http://docs.wholetomato.com?W147 |
zen is the art of being at one with the two'ness |
|
|
|
RickHodgin
Senior Member
44 Posts |
Posted - Apr 12 2007 : 11:17:28 AM
|
quote:
At a code formatting level I can see problems with this, since if the tab stop is set to 4, and you indent something with 6 spaces, what happens?
That would be a problem, which is why I think the buttons to entab and detab would be desirable. Whatever the IDE is setup for the current file, that's what would be used going either way.
As for the \\t thing... had no idea. The things you learn over time. |
|
|
|
feline
Whole Tomato Software
United Kingdom
18940 Posts |
Posted - Apr 12 2007 : 11:24:52 AM
|
This problem with "funny" spacing is also why I am reluctant to consider this idea, because this becomes code formatting under a different name  |
zen is the art of being at one with the two'ness |
|
|
|
RickHodgin
Senior Member
44 Posts |
Posted - Apr 12 2007 : 11:29:45 AM
|
quote:
This problem with "funny" spacing is also why I am reluctant to consider this idea, because this becomes code formatting under a different name
If it helps, we can call them Bert and Ernie abilities. We don't have to call them formatting at all. You know like this: "Hey, can you Bert that file before you send it?"  |
|
|
|
feline
Whole Tomato Software
United Kingdom
18940 Posts |
Posted - Apr 13 2007 : 12:58:36 PM
|
Not going to help, but a good try
I once spent several hours trying to make GC format code just how I wanted, and failed, and this program has a LOT of options. This is a mine field if you want to make everyone happy. |
zen is the art of being at one with the two'ness |
|
|
|
RickHodgin
Senior Member
44 Posts |
Posted - Apr 13 2007 : 2:29:22 PM
|
quote:
This is a mine field if you want to make everyone happy.
Okay, here's a rebel idea. How about exposing a set of generic API abilities which would allow 3rd party add-on software to work inside of VAX? You would include an input box for the name of the DLLs and would test the presence of the various functions required as entry points for the API. For example, if there is an API you could expose which does something when a file is launched, it would call the "VisualAssistX_LaunchFile()" function if present. If not present, then it would not do that for that DLL. You could have a whole slew of exposed API abilities which allow us to write particular things we might like to have which you do not.
If you'd like to know more about this, or see a model for test purposes, email me. :) |
|
|
|
feline
Whole Tomato Software
United Kingdom
18940 Posts |
Posted - Apr 14 2007 : 1:19:32 PM
|
If you want to go down the "write some code" route then you are better off just writing a code formatting IDE extension. Some already exist, I recall looking at them once or twice myself. VAX just asks the IDE to format the code, and we then let the IDE get on with it.
The main problem with VAX talking to something else like this is going to be compatibility. Remember we currently support:
Embedded C++4
Visual C++ 6
Visual Studio 2002
Visual Studio 2003
Visual Studio 2005, several different versions
Code inside VAX that works one way for one IDE has to work differently for a different IDE. Your idea, while interesting, would open a massive can of worms for testing, support, and finding out why the IDE is crashing. We already have some problems when two independent plugin's are running at the same time in the same IDE.
Just for code formatting this seems like a overly complex solution. |
zen is the art of being at one with the two'ness |
|
|
|
RickHodgin
Senior Member
44 Posts |
Posted - Apr 14 2007 : 4:20:53 PM
|
quote:
Just for code formatting this seems like a overly complex solution.
My thoughts were that it would provide an infinite path of expansion for VAX, making it possiby a more desirable solution. If people like me could write add-on DLLs which could be included, and they serve some useful purpose, then others could download them and use them if needed. Also, I believe once the base framework is designed and tested you'd never again have to do anything to allow these new abilities (other than possibly expose new API calls) to allow new external abilities.
The SemWare Editor has add-on macros, including the ability to call functions in 32-bit DLLs. They have a page dedicated to user-provided tools/features:
http://www.semware.com/html/tseprofilesr.php
and http://www.semware.com/html/tseprofilesd.php
I was thinking this could be something the VAX community might enjoy. |
|
|
|
feline
Whole Tomato Software
United Kingdom
18940 Posts |
Posted - Apr 16 2007 : 07:39:28 AM
|
This is an interesting idea, but I am concerned, perhaps overly so , about the possible problems it will cause. Remember I will be in the front line of the problem reports.
At a basic level you can use macro's:
http://docs.wholetomato.com?W382
Which are a good illustration of the problem here, as you move from one IDE to another you have to radically change what you do, and how you do it.
The SemWare editor provide the entire framework, they are not sneaking around behind the IDE's back, trying to make it do things it does not want to do. So they are in a much better position to provide these features, since they can design them in at a low level. |
zen is the art of being at one with the two'ness |
|
|
|
RickHodgin
Senior Member
44 Posts |
Posted - Apr 16 2007 : 4:16:38 PM
|
quote:
Which are a good illustration of the problem here, as you move from one IDE to another you have to radically change what you do, and how you do it.
If you pass a parameter to the DLL functions indicating the version, or possibly there is something as generic as "VisualAssistX_Init()" which is called at startup to let the DLL know what platform it's running on, then it could automatically adjust everything it needs to process internally. You could pass all references as void pointers and then based on the version we cast them appropriately.
Or, if you wanted it to be explicit it could be as horribly generic as: VisualAssistX_VS6_Function() for Visual Studio 6, VisualAssistX_VS2003_Function() for VS2003, and VisualAssistX_VS2005_Function() for the 2005 stuff and so on. And possibly even the very ugly 2005a, 2005b, 2005c for different versions within.
I think the Init() with an IDE version and void casts are more desirable.
Just some thoughts off the top of my head. I think the logistics are doable, and once you get past that initial framework we're talking big time fun in expansion. :) |
|
|
|
feline
Whole Tomato Software
United Kingdom
18940 Posts |
Posted - Apr 16 2007 : 5:05:17 PM
|
| I will mention the idea, but this is not something we will try and do in the short term. |
zen is the art of being at one with the two'ness |
|
|
|
RickHodgin
Senior Member
44 Posts |
Posted - Apr 16 2007 : 5:30:19 PM
|
quote:
I will mention the idea, but this is not something we will try and do in the short term.
Understood. If you'd like me to sign an NDA and let me have (even a very old) static version of VAX to develop under, I would be more than happy to write the framework for you. |
|
|
|
feline
Whole Tomato Software
United Kingdom
18940 Posts |
Posted - Apr 16 2007 : 6:01:12 PM
|
I have passed on this interesting offer.
Speaking purely from the support point of view I am not a fan, for the simple reason that any plugin inside VAX adds even more variables to finding out why something is going wrong / crashing. The more powerful the plugin inside VAX, the worse it gets.
This is one reason why I like VAX not having to many options, it limits the variables to consider when something really strange happens on someone's machine.
I have been chasing strange things for a while, you can probably tell |
zen is the art of being at one with the two'ness |
|
|
|
RickHodgin
Senior Member
44 Posts |
Posted - Apr 16 2007 : 9:53:56 PM
|
quote:
for the simple reason that any plugin inside VAX adds even more variables to finding out why something is going wrong / crashing.
All you have to do is make sure you write it in modular form with some type of generic template ability like this:
#define _WHATEVER_MODULE 1
#ifdef _WHATEVER_MODULE
class WhateverModule
{
// All code goes here for this module
}
#endif
Then if there's ever an error you can simply comment out the #define statements and recompile to see if the error is still there. If you're clever enough you can even build some MAKE scripts which copy over combinations of #define statements for whatever variable portions you'd to test, then you can auto-compile every iteration and test them individually for each version. Also if you always compile within VS you could create several Configurations and do those.
Though as someone well versed with defensive programming I'm sure you know this trick and others like it. I am an ASM programmer from way back. Some old habits die hard. :) |
|
|
|
feline
Whole Tomato Software
United Kingdom
18940 Posts |
Posted - Apr 17 2007 : 07:37:21 AM
|
We are talking about slightly different things. I am thinking of the problem that the end user is reporting "it all goes wrong". This level of detail is depressingly common on bug reports.
Finding the exact trigger for these problems can be very difficult as it is, but throw a selection of addin's sitting inside VAX into the mix, plus the fact there will be several versions of each plugin, and they may conflict, and finding, and reproducing, and fixing the problem becomes a LOT harder.
Plus the end user sees a problem in VAX, but what if the problem actually lies in their favourite addin, but is only triggered under very specific conditions, and the addin programmer has moved onto other things?
If they are using build 16a of VAX with no problems, upgrade to 16b and the problem shows up they will blame VAX, even if the problem is not caused by VAX. |
zen is the art of being at one with the two'ness |
|
|
| |
Topic |
|
Replace white-spaces or tabs
