TOPIC:

In quite a few VO modules we have a number of classes in one module. But even if we don't have that it is hard to find to which class a method belongs. Especially on a Xported project I expect an endless upwards browsing/searching until I find a CLASS statement somewhere and then the same direction back to find the code I was looking at.

Would it be possible to leave the CLASS xxx code in XPorted output (I would say as an option)? That would make the X# code much more readable. I know that it's officially redundant because somewhere in the code there's a class and somewhere else there's an endclass but I consider adding CLASS xxx like in VO absolutely necessary to have a little bit of overview in the mess which is called "Visual Studio".

The compiler does not seem to have any problems with CLASS xxx behind the method.

Dick

Hi,

I would also like to have this choice.... In the migration phase this would help a lot.
After that, using XIDE, usually I create a folder and distribute the various classes in different files:



Wolfgang

Guys, please check the first option in the VOXporter window at the top right

I do see a problem with this option and the XApp class though, will take care of it.

Ah yes indeed....Great!

It should be off by default

Can we also get rid of the annoying "Please this important information" window? If someone hasn't seen the !!!VERY IMPORTANT INFORMATION!!! info then it is his/her own fault. I have to click multiple times in the window before I can continue. Or did I miss a setting here too?

Dick

Dick,
If you are working in Visual Studio then the left combobox above the editor window show you in which class you are. And if you see (Global Scope) then you are inside a function, procedure or on a line with a define or global. The right combobox displays the method/function name where you are (in case you are in a very long method./function and you can't see the first line of the method.
Robert

Hi Chris,

grrrr... how could I overlook that!

Of course also XIDE shows the correct class in the toolbar, but I had changed a few times the method in the wrong class because I looked not goo enough...

Wolfgang

Dick,
go to the ini file, there's an option to set by hand

Dick, as Karl said, you can edit the VOXporter.ini file and set NOWARNINGSCREEN=1. Or you can simply delete the ReadMe.rtf file

Replying to #7/8:

Hello Chris, (& Karl)

It seems that you really have been thinking about everything! For most software (often Microsoft) annoyances are there to stay. In X# there's already a solution programmed before I noticed the annoyance.

Again X# truly deserves the extending of FoX programs I have.

Dick

Replying to #5,

Hello Robert,

You are right about the class but that I think that is also what I mean with "VS is a mess". One brief look at a method in VO and you see directly where you're working on and the use of colors emphasizes it:

METHOD Something ) CLASS MyClass

In VS you have to discover where in the screen information is hidden. Users call VS powerful because "you can do everything with it" but if so most if it is not obvious and/or it is hidden.

While in VO In can open my program and directly see which entities were left uncompiled, last time I left, I have to recompile at every start in VS because when I reopen my converting-work-in-progress it looks like it has no errors. Then the error messages do not specify in which method they occur. I have to open-click it first. There's a copy option and then what you copy looks like this:

Severity Code Description Project File Line Suppression State
Error XS9010 The function 'PCount' is only supported in functions or methods with CLIPPER calling convention (and not in ACCESS or ASSIGN methods) iConnect Library C:\XporterOutput\iConnect Library\Webteksten DHTML.prg 706

So I always have to select the real error (who on earth wants to copy "Severity Code Description Project File Line Suppression State" with an error?) in order to start searching for the cause.

I was wondering: which well hidden option or other parts of the screen did I miss here? I checked all right mouse menu's and other parts of the screen to see if the real info I was looking for was hidden somewhere else but so far I didn't find it.

Dick

Dick, what other real info are you looking for?

Dick,

Double click the error and you come to the offending line of code. Just like in the errors window of VO.
What else do you need ?

Robert

Hello Chris, Robert,

See the screenprint. VS only gives me the name of the .prg where the error occurs which is like the module in VO, I underlined this green for both. VO tells me the class and the method. VS does not.

I've right clicked which columns to show in VS but none seem to show me the class + method. Yes I can doubleclick to open it. But in VO I directly see where the error is. In VS, especially interesting in this conversion project, I have to click 154 times and search somewhere else in the screen to see where I am working in. This is one of the (many) reasons I still hate every second I work in VS.

Dick

Hi Dick,

True, this is a stepback from VO. But especially for Errors, why is it important to know in advance in which entity the error occurred? I could had easily made XIDE display this information, but I never felt the need for it, so never did it. Don't you need to go to the actual error location to fix it anyway?

Even VO does not show the code which has problem in the error information, you need to double click to go to this line and see exactly what the error is and fix it, I do not see how knowing the entity name in advance helps in any way.

(for search results this is a completely different story of course)

Chris

Hello Chris,

True, this is a stepback from VO. But especially for Errors, why is it important to know in advance in which entity the error occurred?

Almost anything is a step back in VS but sometimes I overlook something.

I find it very important to see where something went wrong especially when I am working on something like this conversion; programs where things are wrong in multiple methods. In VO I can quickly asses that e.g. 30 errors are in one specific method which are probably solved all 30 with one or 2 code changes.

In VS, in this conversion project, I would need to double click on all 154 warnings and 72 errors to open code and make notes and count and in the end I estimate I am 30 minutes and 226 double clicks and lots of scrolling further before I know more or less what I know exactly in VO at one glance in the error screen.

Another example is when I decide to change a method or function, e.g. add a parameter to a strong typed function. I can see very quickly in VO what the impact is of this change, for example the function is used like 40 times but mostly in 3 or 4 methods. Then I know I can make the change quickly because I only need to test on 35 places if it all works as expected instead of 20 very different parts of the program.

Also add the fact that on opening a VS project it does not recall the number of errors and warnings without recompiling and I still have the situation: against 1 nice VS feature (like Peek definition, actually after some really hard thinking I couldn't produce anything else I liked in Visual Studio) there are a few dozen things I consider well below what has been present in VO since years.

Dick