FileOpen dialog on indicator

[ganamide]

so I am not alone fighting with NT support for reference problem. They try to convince me that this is expected behaviour, but I still resist My last email was about two days ago or so.

Funny thing happens if you have say proprietary indicator and vanilla system. Then you create your simple indicator, that doesn't require any external references. If you choose to export it Info.xml is added with reference to that proprietary indicator. This is clearly a bug.

In any case it's possible to find out which libraries some code requires and there should be added only those references. Looks like they search references in the same folder all indies lurk. What about simply copying needed indie and all referenced indies by that indie to tmpdir and only then wrap everything up in .zip? This is only one of possible ways to fix this. Of course there are more clever scenarios like http://stackoverflow.com/questions/4...l-dependencies, google "list dll dependencies".

I'm rather shocked as well. This is clearly not a feature any user of NinjaTrader would want. To treat it as 'expected' behavior is disingenuous. Why don't they just admit it!?! Maybe when the new version of NT comes out in 2020 it will be fixed

[raefon72]

cool I found mine at

C:\Windows\Microsoft.NET\Framework\v2.0.50727

one hurdel covered thanks

[koganam]

I am getting lost / confused with the editor. I right click add refference but the dll is not there when I add it takes me to the NT7 folder but no dll for System.Design.dll is it another dll that I am refrencing / adding.??
Thanks
raef

System.Design.dll is a System dll. It will be in the folder where .NET is installed. Mine happen to be as shown in the picture. Best reference is probably the last one.

[raefon72]

I am getting lost / confused with the editor. I right click add refference but the dll is not there when I add it takes me to the NT7 folder but no dll for System.Design.dll is it another dll that I am refrencing / adding.??
Thanks
raef

[koganam]

Hi Guys,

just wondering if anyone had solved this riddle yet.

I have found this dll that could help with the viewing of files but am unsure if its the correct thing I should be doing any pointers appreciated.

http://www.codeproject.com/Articles/3287/A-very-simple-BrowseForFolder-class

Thanks Raef

What riddle? The code for opening a selection dialog box from the indicator properties page is right in this thread. Try reading it from the top. I believe post #5 is where the actual code is posted.

[raefon72]

I also found this but my brain is drowning with information overload

//public static string Sellalert

/*{
string fileName = @"C:\mydir\myfile.ext";
string path = @"C:\mydir\";
string result;
result = Path.GetFileName(fileName);
Console.WriteLine("GetFileName('{0}') returns '{1}'", fileName, result);
result = Path.GetFileName(path);
Console.WriteLine("GetFileName('{0}') returns '{1}'",
path, result);
}
*/

[raefon72]

Hi Guys,

just wondering if anyone had solved this riddle yet.

I have found this dll that could help with the viewing of files but am unsure if its the correct thing I should be doing any pointers appreciated.

http://www.codeproject.com/Articles/3287/A-very-simple-BrowseForFolder-class

Thanks Raef

[koganam]

Thanks koganam, so you're basically saying :

a) for the source import : the dll has to be manually added before import

b) for the compiled import : the dll would be added automatically

Is that the issue you ran into?

Thanks,

When I found the problem, I just noted and reported it on the forum. As I actually supply code in the form of DLL to clients, and never source, it was not really a big issue at the time, and I was on a deadline, so I just kept going.

However, as I never had the problem with my own source code, which I never had to import, except when I tried the test on a virgin installation, I would have to surmise that manually adding the reference would probably alleviate the problem.

As I know you folks are busy, and I just rebuilt another virgin development environment, let me test that theory out and report.

[NinjaTrader_Bertrand]

Sorry Bertrand, I do not quite understand. I have quoted the relevant part here, but you may want to reread the whole post.(New emphasis mine, in red. Not shouting; just making it prominent)

IOW, an export as a dll works differently from an export as a .cs file: the dll export/import has no problem, but the source export/import does. The inconsistency is what strikes me as a bug.

Thanks koganam, so you're basically saying :

a) for the source import : the dll has to be manually added before import

b) for the compiled import : the dll would be added automatically

Is that the issue you ran into?

Thanks,

[whitmark]

A related post, fyi

http://www.ninjatrader.com/support/forum/showthread.php?t=40919

[andrius]

so I am not alone fighting with NT support for reference problem. They try to convince me that this is expected behaviour, but I still resist My last email was about two days ago or so.

Funny thing happens if you have say proprietary indicator and vanilla system. Then you create your simple indicator, that doesn't require any external references. If you choose to export it Info.xml is added with reference to that proprietary indicator. This is clearly a bug.

In any case it's possible to find out which libraries some code requires and there should be added only those references. Looks like they search references in the same folder all indies lurk. What about simply copying needed indie and all referenced indies by that indie to tmpdir and only then wrap everything up in .zip? This is only one of possible ways to fix this. Of course there are more clever scenarios like http://stackoverflow.com/questions/4...l-dependencies, google "list dll dependencies".

[koganam]

koganam, sorry for the late follow up - this is working as expected, this unfortunately how reference dll are handling in compiled assemblies, this is exactly the reason why assemblies for distribution should only be exported from a clean system without any custom references defined / set.

Sorry Bertrand, I do not quite understand. I have quoted the relevant part here, but you may want to reread the whole post.(New emphasis mine, in red. Not shouting; just making it prominent)

Here is the problem/potential bug.

If you do the same thing, except that you export the indicator, as source, rather than as a dll, when you try to import the indicator, NT returns an error: "Import failed. The NinjaScript archive may contain duplicate method names that already exist on your PC or there is a required file missing in either your PC or in the import archive." I repeat: this is on a clean system. To verify, I uninstalled NT, and reinstalled it, then tried to import the source version, and got the same error.

IOW, an export as a dll works differently from an export as a .cs file: the dll export/import has no problem, but the source export/import does. The inconsistency is what strikes me as a bug.

[NinjaTrader_Bertrand]

koganam, sorry for the late follow up - this is working as expected, this unfortunately how reference dll are handling in compiled assemblies, this is exactly the reason why assemblies for distribution should only be exported from a clean system without any custom references defined / set.

[koganam]

Bug in Assembly references handling. NT Support. I think that this issue deserves a response. Can we have one please?

[koganam]

Is this a bug then?

Here is the skinny after a whole host of experimentation that I just did on this one.

Here is how it works out.

1. Use right-click in the indicator editor to add a reference. It will be added with the fully qualified path name. Not nice.
2. Compile the indicator.
3. Export the indicator as a DLL (VERY VERY IMPORTANT!!)
4. If the DLL is imported, it will automatically add the reference to the System.Design.dll, without any path information. In other words, the correct way!

You can test this by removing the reference and renaming the file after you export the indicator. Restart NinjaTrader and verify that the reference is gone (the restart is not really required, but let us make assurance double sure). We are testing what would happen if your customer did NOT have the reference loaded, and tried to import the indicator that you just sold to her.

Import the DLL indicator, and you will find that NT tells you that you need the reference, and then creates the reference for you automatically. You can verify this by opening any indicator for editing and looking at the references using the right-click menu.

The nice thing is that if you then remove the assembly using the approved NT method, the reference to System.Design.dll stays in the references! How nice?

Here is the problem/potential bug.

If you do the same thing, except that you export the indicator, as source, rather than as a dll, when you try to import the indicator, NT returns an error: "Import failed. The NinjaScript archive may contain dupliacte method names that already exist on your PC or there is a required file missing in either your PC or in the import archive." I repeat: this is on a clean system. To verify, I uninstalled NT, and reinstalled it, then tried to import the source version, and got the same error.

I have attached 2 reference files for use in duplicating the problem. I consider it a bug related to importing indicators that need a system reference that NT does not ship with by default. IMHO, it should work for imports the same way, whether the exported indicator is exported as an assembly or as source code.

Of course, if we are not supposed to use any methods from System DLLs tthat NT does not reference out of the box, this point is moot, and this whole thread should probably be moved to the thread for unsupported tips and tricks.