Magic code issues

[ETFVoyageur]

I am having several issues with the magic code that gets generated at the end of my indicator source file:

1) Annoying, but not critical -- whenever I make a change the magic code region gets flagged as changed/saved (green bar) and expanded. Since I did not change it, marking it with the green bar seems inappropriate. Since I am not supposed to pay attention to the magic code please stop expanding it. That serves no useful purpose and is just plain annoying

2) Serious problem -- the magic code is being generated inappropriately. My "indicator" is really just my base class for all of my indicators. As such, I declare it "abstract". It is not really an indicator by itself, and so no magic code should be getting generated at all (NT7 refrained from generating magic code in this case). This came to my attention because the magic code is wrong -- it tries to instantiate the abstract class and so gets a compiler error. Please refrain from generating the magic code for my abstract base class.

The inability to make it abstract appears to be causing another problem as well -- it is showing up on the Indicators list, available to be added to a chart. That is nonsense. NT7 got it right -- I declared it abstract, no magic code got generated, and nothing tried to make it available to be added to a chart.

--EV

[koganam]

I am having several issues with the magic code that gets generated at the end of my indicator source file:

1) Annoying, but not critical -- whenever I make a change the magic code region gets flagged as changed/saved (green bar) and expanded. Since I did not change it, marking it with the green bar seems inappropriate. Since I am not supposed to pay attention to the magic code please stop expanding it. That serves no useful purpose and is just plain annoying

2) Serious problem -- the magic code is being generated inappropriately. My "indicator" is really just my base class for all of my indicators. As such, I declare it "abstract". It is not really an indicator by itself, and so no magic code should be getting generated at all (NT7 refrained from generating magic code in this case). This came to my attention because the magic code is wrong -- it tries to instantiate the abstract class and so gets a compiler error. Please refrain from generating the magic code for my abstract base class.

The inability to make it abstract appears to be causing another problem as well -- it is showing up on the Indicators list, available to be added to a chart. That is nonsense. NT7 got it right -- I declared it abstract, no magic code got generated, and nothing tried to make it available to be added to a chart.

--EV

Place such classes in the AddOns folder.

[ETFVoyageur]

Place such classes in the AddOns folder.

I just tried to move my class to the AddOns folder. That gets an error message saying "You cannot move a [sic] indicator to a [sic] Add on folder."

I just generated a default AddOn and there is nothing indicator about it. My class needs to be in the same namespace and be a subclass of Indicator. Judging by the error I got when trying to move my class, NT8 takes exception to that (in the AddOn folder).

--EV

[ETFVoyageur]

A further example of the same problem -- NT8 thinking my indicator base class is itself an indicator (WRONG!).

I made the constructor protected -- after all the only ones who should be calling it are its children. Well, the protection level did its job -- it causes a compiler error when the magic code tries to instantiate it directly.

What I really need is to find out how I I can have an indicator base class that NT8 will not think is itself an indicator. How do I do that?

--EV

[ETFVoyageur]

I forced my base class into AddOns -- it compiles without magic code ... let's hope that is the answer.

--EV

[ETFVoyageur]

I spoke too quickly. Now when I recompile the code in AddOns it still gets the unwanted magic code added. I do not know what is different from the first time I tried compiling it.

Back to Square One -- I need to find out how to convince NT8 that my base class is not an indicator in its own right. How do I do that?

--EV

[ETFVoyageur]

It's compiling OK now -- no magic code. I do not know what makes the magic code come and go -- undoubtedly something I am doing, but I do not know what..

Anyway, it seems OK for now, so I am cautiously proceeding.

--EV

[koganam]

I spoke too quickly. Now when I recompile the code in AddOns it still gets the unwanted magic code added. I do not know what is different from the first time I tried compiling it.

Back to Square One -- I need to find out how to convince NT8 that my base class is not an indicator in its own right. How do I do that?

--EV

You write the class and place the file physically in the AddOns folder, using the file system, not by trying to move it in the NinjaScript editor. The NS editor is not displaying physical folders: it is displaying a namespace heirarchy, and may be completely different from the physical folder structure.

[ETFVoyageur]

You write the class and place the file physically in the AddOns folder, using the file system, not by trying to move it in the NinjaScript editor. The NS editor is not displaying physical folders: it is displaying a namespace heirarchy, and may be completely different from the physical folder structure.

As I subsequently noted, I got the job done by completely overwriting a trivial AddOn generated by the wizard. (I do not understand why I got the magic code once that way, but it has not happened again so I must have done something wrong that once.)

As the the folder / file system mapping -- I saw a previous post saying they were unrelated, too. I note that there is a file system folder corresponding to each of those top-level items in the editor, so I expect they are intended to match up. In any case, my two files do match up -- the add-on is in the AddOns folder and the indicator is in the Indicators folder. Is the issue that dragging in the editor GUI does not do the corresponding move in the file system? If so, is that a bug?

--EV

[koganam]

...
As the the folder / file system mapping -- I saw a previous post saying they were unrelated, too. I note that there is a file system folder corresponding to each of those top-level items in the editor, so I expect they are intended to match up. In any case, my two files do match up -- the add-on is in the AddOns folder and the indicator is in the Indicators folder. Is the issue that dragging in the editor GUI does not do the corresponding move in the file system? If so, is that a bug?

--EV

Many of us expected a matching schema between the NS Editor display and the physical file system. However, the current design is what they have decided on, and they apparently want to keep it that way. I would have called it a bug, but as that is the conscious design, "bug" may not be quite the correct word to describe it.

We simply have to be cognizant of the matter, and remember that file actions in the NS editor GUI do not necessarily correspond to actions in the physical file system.

[ETFVoyageur]

So what can you do in the editor GUI tree? Obviously not drag an indicator file to the AddOns location.

Also, just to help me understand, what is their mental model? I'll have some sympathy if they have a clean mental model of what is going on, but absent such a model I'd declare a bug (perhaps a design bug).

--EV

[koganam]

So what can you do in the editor GUI tree? Obviously not drag an indicator file to the AddOns location.

Also, just to help me understand, what is their mental model? I'll have some sympathy if they have a clean mental model of what is going on, but absent such a model I'd declare a bug (perhaps a design bug).

--EV

As I said, it is a "namespace tree" display/organizer. If you create a subfolder in the GUI tree, it creates a new namespace, not a physical folder. All other seeming fie operations are also handled relative to namespace semantics rather than to file system semantics.

[ETFVoyageur]

As I said, it is a "namespace tree" display/organizer. If you create a subfolder in the GUI tree, it creates a new namespace, not a physical folder. All other seeming fie operations are also handled relative to namespace semantics rather than to file system semantics.

Interesting ... I wonder what the ramifications are. For example, how do I know where any source file is? there is no "Properties" menu choice for the individual files, and the editor has no "Save As...", so you cannot find out that way.

Before anyone says I do not need to know where the files are, I certainly do -- I need to be able to point VS to them. Fortunately in my case there has been no guesswork. The "namespace tree" (which really is not one when I do things like put my indicator base class in AddOns) matches the physical tree. Another reason to know where things are is MR. K's earlier suggestion of operating in the file system to set up my base class in AddOns.

--EV

[koganam]

Interesting ... I wonder what the ramifications are. For example, how do I know where any source file is? there is no "Properties" menu choice for the individual files, and the editor has no "Save As...", so you cannot find out that way.

The editor does have "Save As..." in the right-click menu.

Before anyone says I do not need to know where the files are, I certainly do -- I need to be able to point VS to them. Fortunately in my case there has been no guesswork. The "namespace tree" (which really is not one when I do things like put my indicator base class in AddOns) matches the physical tree. Another reason to know where things are is MR. K's earlier suggestion of operating in the file system to set up my base class in AddOns.

--EV

We just have to keep it in mind I guess. Honestly, as namespaces are essentially random access, by reference, I really do not have much use for a namespace tree as a forced paradigm. I would prefer that the tree in the editor match the file-system tree, but that is just my preference.

[ETFVoyageur]

The editor does have "Save As..." in the right-click menu.

I stand corrected. That means there is one way to find out where files live on the disk. Good.

We just have to keep it in mind I guess. Honestly, as namespaces are essentially random access, by reference, I really do not have much use for a namespace tree as a forced paradigm. I would prefer that the tree in the editor match the file-system tree, but that is just my preference.

I agree with your preference. One further reason is that the "namespace tree" is not in fact always organized by namespace. My base class is under AddOns, both in the GUI and on the disk. It is completely unrelated to that namespace, however. It is in the Indicators namespace. It is only in AddOns because of two things: (1) that's the only way I know to suppress unwanted magic code generation, and (2) a well-respected authority (Mr. K.) told me that is where it belongs.

--EV