It is currently April 27th, 2024, 6:28 pm

Debugging a plugin

Get help with creating, editing & fixing problems with skins
chilio
Posts: 48
Joined: January 26th, 2018, 9:56 am

Re: Debugging a plugin

Post by chilio »

tjhrulz wrote: I also like to have a post build event to taskkill Rainmeter, export the .DLL for me, and the copy it to the Rainmeter plugins folder.

The one I use on every project is

Code: Select all

taskkill /f /fi "imagename eq Rainmeter.exe"
"$(SolutionDir)API\DllExporter.exe" "$(ConfigurationName)" "$(PlatformName)" "$(TargetDir)\" "$(TargetFileName)"
xcopy  "$(TargetDir)$(TargetFileName)" "%appdata%\Rainmeter\Plugins" /Y
That will kill rainmeter but not error if it is not running and will copy and overwrite. You may need to tweak some of it if your project layout is different but if you are using the empty one it will be the same.
I'm trying to understand this code, the first and last line seem obvious: kill rainmeter and copy the DLL. The next doesn't seem to have and commands in it so I really don't understand any of it ^^'. Do I need to insert the right paths into "SolutionDir" and the others or just leave it as is?
And is copying a file good enough to let visual studio know to use breaklines? (When I just copy your code, I get the "no symbols loaded" message at the breakline.)
User avatar
SilverAzide
Rainmeter Sage
Posts: 2613
Joined: March 23rd, 2015, 5:26 pm

Re: Debugging a plugin

Post by SilverAzide »

chilio wrote:I'm trying to understand this code, the first and last line seem obvious: kill rainmeter and copy the DLL. The next doesn't seem to have and commands in it so I really don't understand any of it ^^'. Do I need to insert the right paths into "SolutionDir" and the others or just leave it as is?
And is copying a file good enough to let visual studio know to use breaklines? (When I just copy your code, I get the "no symbols loaded" message at the breakline.)
His commands go, verbatim, into the "Post build event command line" (Build Events tab) in your project solution. (Right-click the project in the solution explorer, select Properties, select Build Events.) Things like "$(SolutionDir)" are Visual Studio macros; they will be expanded during the post-build event.
Gadgets Wiki GitHub More Gadgets...
chilio
Posts: 48
Joined: January 26th, 2018, 9:56 am

Re: Debugging a plugin

Post by chilio »

SilverAzide wrote:His commands go, verbatim, into the "Post build event command line" (Build Events tab) in your project solution. (Right-click the project in the solution explorer, select Properties, select Build Events.) Things like "$(SolutionDir)" are Visual Studio macros; they will be expanded during the post-build event.
I did put the code in the right place, so that went fine :) The problem is I don't understand it yet, so I cannot tweak it yet. I will try to find where this stuff is documented, that should get me somewhere ^^
chilio
Posts: 48
Joined: January 26th, 2018, 9:56 am

Re: Debugging a plugin

Post by chilio »

SilverAzide wrote:His commands go, verbatim, into the "Post build event command line" (Build Events tab) in your project solution. (Right-click the project in the solution explorer, select Properties, select Build Events.) Things like "$(SolutionDir)" are Visual Studio macros; they will be expanded during the post-build event.
I finally looked all of them up, but to me it still seems like the second line has no function at all: just a few strings containing paths behind eachother. How is that supposed to do something? (String parameters should go somewhere else IIRC.)
User avatar
SilverAzide
Rainmeter Sage
Posts: 2613
Joined: March 23rd, 2015, 5:26 pm

Re: Debugging a plugin

Post by SilverAzide »

chilio wrote:I finally looked all of them up, but to me it still seems like the second line has no function at all: just a few strings containing paths behind eachother. How is that supposed to do something? (String parameters should go somewhere else IIRC.)
I think you might have missed something... the first line calls taskkill.exe to kill Rainmeter, the second line is a call to DllExporter.exe to export the plugin DLL, the third line calls xcopy.exe to copy the plugin DLL to the Rainmeter plugins folder.
Gadgets Wiki GitHub More Gadgets...
chilio
Posts: 48
Joined: January 26th, 2018, 9:56 am

Re: Debugging a plugin

Post by chilio »

SilverAzide wrote:I think you might have missed something... the first line calls taskkill.exe to kill Rainmeter, the second line is a call to DllExporter.exe to export the plugin DLL, the third line calls xcopy.exe to copy the plugin DLL to the Rainmeter plugins folder.
I feel so stupid, the call to DllExporter was a thing too ^^' ("just the path to a file" can be a call too -.- )
Let's see if I can find DllExport.exe and add it to the solution (working on a seperate solution, but I assume it is somewhere inside the plugin starter-pack zip)
chilio
Posts: 48
Joined: January 26th, 2018, 9:56 am

Re: Debugging a plugin

Post by chilio »

SilverAzide wrote:I think you might have missed something... the first line calls taskkill.exe to kill Rainmeter, the second line is a call to DllExporter.exe to export the plugin DLL, the third line calls xcopy.exe to copy the plugin DLL to the Rainmeter plugins folder.
Do I need to copy the full API folder into the solution folder to let DllExporter.exe do it's work?

Anyway, after doing so, rainmeter responded to the commands from visual studio, but I'm still missing one step. I still get the 'No symbols have been loaded' message. Do I need to do something with the DllExport class?
User avatar
SilverAzide
Rainmeter Sage
Posts: 2613
Joined: March 23rd, 2015, 5:26 pm

Re: Debugging a plugin

Post by SilverAzide »

Make sure your build is set to debug mode instead of release mode. I'm not sure which symbols it is complaining about, it might be something other than your plugin (i.e., Rainmeter itself), in which case you can ignore the message. You do not need to copy any API files, the post-build event call to the DllExporter is fully qualified... assuming you have added YOUR plugin as another project in the Rainmeter SDK solution. If you've created a separate solution, then you'll need to arrange it like the SDK.
Gadgets Wiki GitHub More Gadgets...
chilio
Posts: 48
Joined: January 26th, 2018, 9:56 am

Re: Debugging a plugin

Post by chilio »

SilverAzide wrote:I'm not sure which symbols it is complaining about, it might be something other than your plugin (i.e., Rainmeter itself), in which case you can ignore the message. You do not need to copy any API files, the post-build event call to the DllExporter is fully qualified... assuming you have added YOUR plugin as another project in the Rainmeter SDK solution. If you've created a separate solution, then you'll need to arrange it like the SDK.
First of all: it is working with the empty project =D (I finally feel less stupid ^^')
The symbols it's complaining about are the symbols for my project, so that's a little problem. ("The breakpoint will not currently be hit. No symbols have been loaded for this document." and it does indeed not hit any breakpoints.)
The only differences I have noticed between the projects:
- the location of API/DllExporter.exe (in my case at $(SolutionDir) instead of 1 folder higher as for PluginEmpty, adjusted the build event),
- build platform ("Active (Any CPU)" vs "Active (x64)", I can't put my project to something other than "Active (Any CPU)" and putting PluginEmpty to it doesn't make a difference),
- Conditional compilation symbols ("" for me, "x64" for PluginEmpty)
- Output path ("bin/Debug" for me, "x64" for PluginEmpty)

So far I had my project set in a seperate solution. Importing it in the SDK solution didn't change anything. (Adjusted the build event back.)

What does "arrange it like the SDK" mean in this context? Copy the API folder to the solution and adjust path accordingly or something more than that? Any other ideas?

To solve the problem with the symbols, I tried looking into the modules window (debug > windows > modules) and Empty.dll does get loaded, CpuMerge.dll doesn't even get mentioned. It seems like my dll is not used at all anymore: I just noticed I could remove CpuMerge.dll from the plugins folder without windows screaming back rainmeter is using it, while my active skins actually do try to use it.

Sorry for the wall of text, I'm just trying to debug my plugin, and it doesn't seem to go much further for my own project, only the empty plugin wants to function it seems... (Sometimes programming is so frustrating -.-' )
Thanks for all the help though ;-)
User avatar
tjhrulz
Developer
Posts: 268
Joined: October 13th, 2016, 1:28 am
Location: Earth

Re: Debugging a plugin

Post by tjhrulz »

chilio wrote:First of all: it is working with the empty project =D (I finally feel less stupid ^^')
The symbols it's complaining about are the symbols for my project, so that's a little problem. ("The breakpoint will not currently be hit. No symbols have been loaded for this document." and it does indeed not hit any breakpoints.)
The only differences I have noticed between the projects:
- the location of API/DllExporter.exe (in my case at $(SolutionDir) instead of 1 folder higher as for PluginEmpty, adjusted the build event),
- build platform ("Active (Any CPU)" vs "Active (x64)", I can't put my project to something other than "Active (Any CPU)" and putting PluginEmpty to it doesn't make a difference),
- Conditional compilation symbols ("" for me, "x64" for PluginEmpty)
- Output path ("bin/Debug" for me, "x64" for PluginEmpty)

So far I had my project set in a seperate solution. Importing it in the SDK solution didn't change anything. (Adjusted the build event back.)

What does "arrange it like the SDK" mean in this context? Copy the API folder to the solution and adjust path accordingly or something more than that? Any other ideas?

To solve the problem with the symbols, I tried looking into the modules window (debug > windows > modules) and Empty.dll does get loaded, CpuMerge.dll doesn't even get mentioned. It seems like my dll is not used at all anymore: I just noticed I could remove CpuMerge.dll from the plugins folder without windows screaming back rainmeter is using it, while my active skins actually do try to use it.

Sorry for the wall of text, I'm just trying to debug my plugin, and it doesn't seem to go much further for my own project, only the empty plugin wants to function it seems... (Sometimes programming is so frustrating -.-' )
Thanks for all the help though ;-)
Yeah symbols not loading is about the most fun it gets :P

Normally that happens when you copy the wrong .dll but if you are using those commands that is not the cause (Also good catch modifying it for your dllexport.exe location). If you never make a skin that uses the plugin they will also never be loaded since Rainmeter will only load them in for the first time dynamically. Do you have a test skin loaded that is using the EmptyPlugin in one of its measures? If you do then that is another cause down, go to about>plugins tab and find your info is it displayed and if you change it and do a forced rebuild does it change as well?