Sorry I didn't know where to post this as there's no thread for help with Rainmeter api and plugin development.
So, I'm learning C# and using plugins to help me learn.
I have an issue with section variables which I don't know how to get around, and if it's actually a bug.
So, I've created this test function:
It does nothing, it simply returns the input back.
So far so good, it works fine, however there's a special case when the input contains parenthesis and brackets.
If I do this:
[&testing:Test((test))]
There's no problem, it correctly returns (test)
If I do this:
[&testing:Test([test])]
There's no problem, it correctly returns [test] or value depending on if the measure exists or not, so if it doesn't exist, it returns the literal [test], it the measure exist it returns its value.
The problem however, is when I used both, so if I do this:
[&testing:Test((test)[test])]
I get this: (test)]
When I should get this: (test)[test]
it doesn't matter if the measure exists or not, the result is the same.
It's like if it was actually returning simply (test with the missing parenthesis at the end, and adding )] which is the end of it, to finally get (test)]
According to me, myself and I, those parenthesis\brackets should not cause issues as they're correctly closed.
Other way to visualize it is to add anything after the closing parenthesis, for example
this: [&testing:Test((test)and[test])]
also returns this: (test)]
![Confused :???:]()
I'm inclined to think there's a logic issue on the api, where it is ignoring opening parenthesis and closing them earlier.
Basically it is recognizing this: [&testing:Test((test)and[test] and then simply adding )] like if it was a left over string, Ignoring everything that’s in red or something like that.
Something interesting is that this: [&testing:Test((test)[])] correctly returns (test)[]. So it only affects if something is enclosed in the brackets.
So, I'm learning C# and using plugins to help me learn.
I have an issue with section variables which I don't know how to get around, and if it's actually a bug.
So, I've created this test function:
Code:
[DllExport]public static IntPtr Test(IntPtr data, int argc, [MarshalAs(UnmanagedType.LPArray, ArraySubType = UnmanagedType.LPWStr, SizeParamIndex = 1)] string[] argv){ Measure measure = (Measure)GCHandle.FromIntPtr(data).Target; if (measure.buffer != IntPtr.Zero) { Marshal.FreeHGlobal(measure.buffer); measure.buffer = IntPtr.Zero; } if (argv == null || argv.Length == 0) { measure.buffer = IntPtr.Zero; } else { measure.buffer = Marshal.StringToHGlobalUni(argv[0]); } return measure.buffer;}
So far so good, it works fine, however there's a special case when the input contains parenthesis and brackets.
If I do this:
[&testing:Test((test))]
There's no problem, it correctly returns (test)
If I do this:
[&testing:Test([test])]
There's no problem, it correctly returns [test] or value depending on if the measure exists or not, so if it doesn't exist, it returns the literal [test], it the measure exist it returns its value.
The problem however, is when I used both, so if I do this:
[&testing:Test((test)[test])]
I get this: (test)]
When I should get this: (test)[test]
it doesn't matter if the measure exists or not, the result is the same.
It's like if it was actually returning simply (test with the missing parenthesis at the end, and adding )] which is the end of it, to finally get (test)]
According to me, myself and I, those parenthesis\brackets should not cause issues as they're correctly closed.
Other way to visualize it is to add anything after the closing parenthesis, for example
this: [&testing:Test((test)and[test])]
also returns this: (test)]



I'm inclined to think there's a logic issue on the api, where it is ignoring opening parenthesis and closing them earlier.
Basically it is recognizing this: [&testing:Test((test)and[test] and then simply adding )] like if it was a left over string, Ignoring everything that’s in red or something like that.
Something interesting is that this: [&testing:Test((test)[])] correctly returns (test)[]. So it only affects if something is enclosed in the brackets.
Statistics: Posted by RicardoTM — 25 minutes ago — Replies 0 — Views 13