Currently, the state of Dream Maker's file inclusion checkboxes will always override the state of the DME file, and will automatically revert any conflicting changes that were made to the DME as soon as you compile or close Dream Maker.
This presents a problem for any third-party tool, editor, or IDE that includes features that modify the #includes. For example, if you had a project open in Dream Maker, but you were changing the file inclusions of that same project using another program, all of your changes will be lost as soon as you close Dream Maker, and you might not even realize it! This could be an absolute nightmare if you were debugging a very large project.
I guess you could get around the problem by directly killing Dream Maker's process, but you might lose something doing that. Another option might be to drop support for #includes inside of the DME and instead use a DM file for that, which should keep your changes safe, but you would never be able to use Dream Maker's checkbox inclusions, because the only file included in the DME stub would be a #includes.dm file. Technically, you might be able to integrate some sort of fancy AutoIt script that detects Dream Maker and quite literally checks and/or unchecks all of the right boxes, but that would just be obnoxious, buggy, and unpredictable.
For these reasons, I think the behavior of Dream Maker's file inclusions needs to change. Checking or unchecking the boxes should immediately write the changes to the DME file, the DME file should also be actively monitored for changes, and the checkboxes should immediately update to reflect those changes. The goal of this would be to make sure that the checkboxes and DME #includes always correspond to one another. I think the best way to make that happen is through live or nearly live updates to both the DME file and the checkboxes, from either source.
This should effectively put a stop to any conflicts, like the one mentioned above, and make it a whole lot easier to integrate DM into third-party tools, editors, or IDEs. I have seen a lot of different projects that try to provide DM language support, but they never seem to get very far. Maybe this problem is getting in the way.
ID:2464386
 May 8 2019, 5:34 pm
|
|||||||
| |||||||
|
May 8 2019, 5:58 pm
|
|
Nadrew
  |
There was a point when hitting the 'refresh' button would update the tree to reflect the DME and not the other way around. Is that not still the case? (not in a position to test right this second)
|
Well that's a bummer, I wonder how long ago that changed/broke. Used to be my go-to method of handling manual DME changes outside of the usually allowed ones (you can edit it outside of the commented sections to do manual changes but anything inside of those commented sections won't stick)
| |
The fact that the comments are affecting the code feels like an unreliable design flaw. Maybe they should be converted into preprocessor macros. It would be a lot less confusing that way.
Apparently, placing #includes inside of the DME, but outside of those special comments, results in the same behavior as placing them inside of a regular DM file, meaning they are not seen or modified by Dream Maker's file tree, so you won't be able to use it for modifying them. Using that instead would be a waste of a good interface, not to mention confusing. You would basically have to write warnings like, "DON'T CHECK THE BOXES IN DREAM MAKER!", all over your code. | |
The DreamMaker Language Client now supports automatically adding created files and removing deleted files in the DME. As I described before, having Dream Maker open at the same time, then closing it, breaks this nice feature.
| |