I’ve added a method to the String class in the Sugar library. Its signature is: method IndexOf(Value: String; StartIndex: Int32): Int32;. I cloned RemObjects repo. You can find it here: https://github.com/michael-taylor/sugar
Anyway, it works for Java and Android, however, for .Net I get the following error when calling the new method like versionStr.IndexOf(".", begin).
error E486: Parameter 2 is “Int32”, should be “Sugar.String”, in call to static Int32 Sugar.String.IndexOf(Sugar.String self, Sugar.String Value)
If I call the method like this: Sugar.String.IndexOf(versionStr, ".", begin) I get the following error:
error E318: No overloaded method “IndexOf” with 3 parameters on type “Sugar.String”
Using the object browser, I can see that the method is there. It’s like the extension method is conflicting with some other method.
PMFJI - Could it be something to do with your references in the .NET project ? As you say, it looks as if the compiler simply isn’t finding your new overload, which would of course be the case if it was still using the original Sugar library, rather than your fork with the new method.
I don’t think your example code for the second error can be right. It appears to be calling a constructor, with no reference to IndexOf() at all so I don’t see how/why any error here could involve that new method.
Thank you for your insight! ( Also, I enjoy your blog )
Yeah, I originally thought my references weren’t updated properly, but I removed and re-added the reference multiple times and checked the timestamp each time (to make sure it was being recompiled). It’s properly referenced. Also, when I view the library in the object viewer, it shows the method I created.
If someone has some extra time, I’d love it if they could clone the fork linked above and try using the String.IndexOf(String, Int32) method.
You are right about the second example above, I mis-typed it. I’ll edit the comment.
Are you using fire? If so, there’s s known mono bug where it will, always pick up the installed copy of Sugar, not your local one, even if you have. A hint path. Check the build log to see where this finding the fine, then delete it. Repeat until it picks the right one that you built yourself.
Ps: thanx a lot for contributing to Sugar. Looking forward to your pull requests.
I’m using Visual Studio, not Fire, but that sounds a lot like what must be happening. I’ll open the project file and look at the hint-paths and turn on verbose build output. I won’t be able to test this until later today, but I’ll post back the results.
It works for the Java and Android projects, just not the .Net one.
Regarding contributing to Sugar, I haven’t submitted a pull request for this change only because I don’t have access to a Mac to test it on Nougut. (Well, and also because of the issue in this thread.) I posted a topic yesterday asking about using MacInCloud.com so I can compile and run unit-tests for the Nougut platform. I’m comparing that option to just getting a headless Mac Mini to use as a build server. I’d like to make sure the changes I make to Sugar are bug-free before I submit a pull request. You’re welcome, I hope any contributions I can make to Sugar are helpful.
That’s the problem! I’m using Visual Studio, but it’s the same problem you mention. It is referencing the system Sugar library and not the one I’ve selected. I’m attaching a screenshot to show the location of my chosen copy of Sugar and the build.log to show that it’s using the system one (line 831).
Visual Studio is being very persistent about using the system-wide Sugar library. I renamed my copy to Sugar1.dll and removed/re-added it as a reference and the reference renames itself Sugar. I’m guessing that is because VS is getting the DLL name from some internal property instead of the filename, though.
)