Getting started.
Robinson
Posts: 751
I've got the SDK and I'm wondering two things: (1) I have VS 2019, not 2010. I've switched out the platform toolset and the .dll builds OK but I'm wondering if there's anything I need be wary of related to this (presumably it won't work unless I build against the 2010 platform toolset?). Secondly, with respect to getting started debugging, what do people generally do? Is there a way to get Daz to load a plugin from a directory other than Plugins, or should I make a copy of Daz somewhere I can set the solution output to without having to elevate to admin? Otherwise, how do I go about debugging my code in this respect?
Any advice you can give would be great, thanks.
Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
Alright. I made a copy of the public build, copied the SDK into my SVN folder and set the public build \plugins as the target location. I can now build the plugin to the actual directory to save faffing about with copies/admin etc. Local debug set to launch Daz from its public build copy. Plugin fails to load (red plug icon in list of plugins).
Decide to go with 2010 SDK but I can't install it. It doesn't like my .NET 4.0 version. Can't edit the registry without removing SYSTEM permissions from some keys and changing the version number to "trick" Microsoft's installer, etc. etc. Somehow I'm sure I don't need to for a .dll that doesn't expose anything other than basic types (or does it?)... I knew this wouldn't be easy.
Alright. Finally got the plugin built and deployed from Visual Studio 2010 after much ******* about. It's a red plug though:
I have no idea what to do next. This is the "A First Plugin" from SDK samples. So the question is: what are the definitive versions of (a) Visual Studio, (b) Daz and (c) Platform SDK I need in order to build a 64 bit plugin? My Daz version is the 64 bit public beta.
OK, 32 bit worked so I downloaded 32 bit 4.10. I can see the plugin loaded (green) but I can't find it anywhere in the UI, i.e. the Window -> Panes UI. I'm talking to myself here I know.... :p
I hit a breakpoint in DzAFirstPluginAction constructor. The class factory DzTClassFactory<T> appears to be working correctly. Can't see the plugin on the menu though. What am I missing?
Hi Robinson! I ran into the same issues when I started, here's what I found out.
-- For one, you need to match 32 vs. 64 bits between your plugin and your version of Daz Studio. If the plugin doesn't load, you've probably built a 32-bit DLL for a 64-bit Daz Studio or vice versa. You can check the Daz application log (Help -> troubleshooting -> View log file) and search for your DLL name if an error message popped up. Also check Help -> About installed plugin whether your plugin DLL is loaded. In VisualStudio, there's a drop-down at the top for Debug vs. Release builds and Win32 vs. x64 builds.
-- About copyingthe DLL to the plugins dir, I have gone brute force and modified the access permissions of the Daz Studio /plugins/ subdirectory in Windows Explorer so that all system users can write to it (right-click on the plugins folder, "Security" tab, "Users" group). Then I changed the project settings so that the final DLL gets built in Daz Studio's plugins folder instead of somewhere in the project tree. That way I can just press "Build" and my new build is active in Daz Studio. (You have to close Daz Studio while building, or else the DLL file is locked.)
-- Regarding the menu items, I'm still a bit loss myself. What should happen depends on which sample you are building. The DzAction classes seem to check whether a menu item needs to be added (e.g under "Edit" for DzEditAction), but I'm not sure under what conditions that check is done. I have tried doing a brand new installation of Daz Studio, and when I gave that my test plugin DLL which was supposed to have a menu item under "Edit", it did show up by itself. But when I tried modifying my class to change where the menu item should be or which menu it should be in, that didn't seem to get triggered. Changing the plugin's GUIDs didn' seem to affect that so maybe the check is based on DLL name or version number? I'm not sure.
In any case, if your plugin adds an action, you should be able to see your menu action in Daz's "Customize" dialog (F3 by default). So the constructor for DzAFirstPluginAction should show up as "Hello" in the left pane, and you can drag it to the Main menu under the "Menu" tab on the right if it's not visible otherwise.
Thanks very much for replying. I was getting lonely here :p. I'll give your ideas a go later on this evening and get back with the results.
Aha! I did what you suggested and added permissions to plugins in Program Files. I built for 64 bit with VS 2010. The plugin appears to have loaded correctly and after hunting through the actions menu I finally found Hello! It'll be smooth sailing from here. Thanks ManFriday.
If you find out any rules under wha conditions the menu items get added, I‘d be curious to know.
My guess would be it's getDefaultMenuPath() on DzAction (override the virtual function to supply the path you want the menu item to default to). However I've overridden it and my item's path doesn't seem to have changed. The function never gets called. I wonder if it's something to do with window layout loading...
A regression maybe? Someone here had similar trouble...
getDefaultMenuPath() does work in principle. For my plugin I have derived my class from DzAction directly and overrode that method to add an item to a menu that's not "Edit" (DzEditAction is just a convenience class that provides that override already). So the first time my plugin was loaded, the menu item got added. However, if I change my mind or want to add another menu item, I'm not sure how to signal to Daz to force a check again.
You can force a menu rebuild with "Window" -> "Workspace" -> "Update and merge menus", but that is also likely to destroy my other custom menu items I think.
Yes, it's not a regerssion. Rob also says run Update and Merge Menus. In older versions this would lose customisations but now DS will log changes before resetting everything to default, with user settings or layout settings overriding.