Under Edit > Add, there’s a textbox to input the path of the executable that is to be run with DxWnd (the "Path:" box), and next to the box is a button to browse the directory tree to locate the executable. This button works for me only for the very first program I add to DxWnd, but not for subsequent programs. This also happens in the Edit > Modify window of an already added program. When I click on the button anytime after I have added the first program, the mouse pointer turns into an hourglass for a brief moment and then reverts back to the arrow, and the directory browser does not come up. The button for the “Launch:“ box just underneath has the same bug. I can type the paths into both boxes manually but it’s an inconvenience. My OS is Windows XP Professional SP3 32-bit.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I tested the bug, but that doesn't happen on my pc with Win7.
Some DxWnd users also run it on WinXP, but nobody ever reported such a bug.
When you say first program, do you mean the first in a DxWnd run (so that the problem could be workarounded but exiting and starting DxWnd again) or just the game in the first position?
Is it possible that the problem depends on some directory access, antivirus protection or some other external cause. Have you set the DxWnd.exe with administrator's privileges?
I'll try to do some testing on XP, provided that I can still find a XP machine....
Thank you for the bug report, anyway. Maybe some other DxWnd user may help us.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
By first program I mean the game in the first position: When a new build of DxWnd comes out, I extract it to a new directory. Then I go to Edit > Add to add my games from scratch. Until I add any games at all, I can click these buttons as much as I want and the directory browser will come up. As soon as I’ve used the Path: button to add the very first executable, i.e. as soon as the executable’s path has filled the box, I can not use the Path: button or the Launch: button anymore.
I noticed something after I wrote the above. When I add an executable’s path, the program creates a file called dxwnd.ini in its own directory. In that file is a line starting with “exepath”. As long as that line is there, the buttons won’t work. As soon as I delete that line and save the file, or instead delete the file, the buttons start working again. They stop working again when DxWnd adds exepath lines for the second, third, etc. programs.
I don’t think there’s a problem with directory access because there is nothing in this system that would restrict it. Nevertheless I tried this on two other drives and the problem persists.I have no antivirus programs running in the background and I’m running DxWnd under an account with administrator privileges. I’ve also tried running DxWnd in a virtual machine with a Windows XP guest OS, but the same thing happens there as well. Perhaps this has something to do with the fact that my Windows CD was customized with nLite.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for clarifying the scenario. In effect, I missed the part about the upgrade from a previous release reusing the old dxwnd.ini configuration file: it's something I don't have the habit to do usually, so likely I never realized the problem.
I also already noticed that DxWnd has this bad habit of dropping a copy of the dxwnd.ini file everywhere (i.e. when you export a game configuration, it likely writes there...).
I'll try to fix both problems. In the meantime, a good workaround (with the advantage of having an extra backup copy of the configuration) is to export all entries, do the upgrade with a fresh new dxwnd.ini file and reimport all entries. Stay tuned for an update ....
P.s. if it's not a problem for you, could you post here a copy of the dxwnd.ini file when the problem occours? I'd like to have a look inside ....
Last edit: gho 2015-10-12
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for spending the time to solve this uncommon problem. I may have misunderstood your post but I hope you don’t think that I upgrade from old releases using an old dxwnd.ini file, because I don’t. I extract every new release to a fresh, empty directory that WinRAR creates upon extraction and I don’t have a dxwnd.ini file until DxWnd has created one in the new directory. I apologize if I've been unclear about this.
I’ve attached the file as it appears immediately after the path for the first executable populates the Path: box. The two lines in the file are enough to break the buttons. You will see that I added the DxWnd executable itself as the first program so that the problem would be easily reproducible, but it happens with other executables as well. Also attached is dxwnd.ini.1, which is the state of the file after I’ve saved the task list and exited DxWnd. This file breaks the buttons as well.
EDIT: The original file doesn't get renamed dxwnd.ini.1 by DxWnd, I renamed it to prevent confusion with the other file I attached.
I think I understood you more clearly now, but I confirm that I never experienced this problem before. Trying your experiment step by step, it is absolutely normal that the dxwnd.ini gets created and then finally saved as in the two samples you posted.
The "exepath" value is used to store a folder to be proposed as a starting point for next time you add a new game. My best guess, so far, is that the folder has some capability problems (Microsoft is quite good at messing things up by assignign "special" capabilities), such as being a reserved folder like "Document and Settings".
This doesn't obviously mean this is not a bug and I'll try to fix it anyway, but if my guess is right, adding a game path in a different folder (like "Program files", maybe... I keep installing all my stuff under "D:\Games" to avoid such problems) may work ok.
By the way, look at what happened when I tried to replicate your experiment exactly by adding something under "C:\Documents and Settings":
I realize that some folders of Windows are problematic, but when I wrote in my second post that I tried this on two other drives without success, I meant that the game path as well as the DxWnd folder were on drives other than C, naturally in folders other than “Documents and Settings”. In fact, this problem first manifested in my D drive; I conducted further tests on the desktop only because it was more convenient. In any case, seeing as nobody else is experiencing the same problem, it is most likely that there’s a problem on my end; I hope I can find and fix it. Thanks for your efforts and for a great program, and for providing these free of charge.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2015-10-13
Hey Retronomicon, you may want to try this method:
Remove the current dxwnd.ini on Dxwnd main folder
Run Dxwnd so it will create a new dxwnd.ini file, then exit. Remember don't add a new application!
Open dxwnd.ini > add updatepaths=0 into [window] section, so it will look like this:
[window]
updatepaths=0
That's it, the textbox should fully functional and you can add a new application since now. Hope it help ;)
Last edit: Anonymous 2015-10-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What a shame: I created that personalization flag just for this purpose, then I forgot ....
Even quicker, edit and copy dxwnd0.ini to dxwnd.ini, it will provide a clean fresh empty file to copy overeach time you want to reset the configuation, but preserving some general settings you may like. For instance, you can place there the key settings for the used special keys.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Maybe it is a WinXP-only bug? I have some difficulty to replicate ...
let's summarize (did I do anything wrong?)
DxWnd with Global Settings / Save paths checked (the default)
Mount a virtual CD (with MagicISO for instance)
Add a game from the virtual CD to DxWnd using the FileOpen dialog (the drag & drop operation doesn't update the exepath value)
Save (just to be sure ...)
Unmount the virtual CD
Add a new game with th FileOpen dialog
In Win7 the FileOpen can't find the target folder, so it returns to propose the DxWnd own folder. If WinXP is different (I can check later) maybe I can make a fix.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, the bug is replicable here (XP only !!), though I'm not sure if it's a DxWnd bug or a MFC bug.
I'll have to check if the failed dialog operation is returning some sort of error code that would let me (at least) clear the poisonous folder value ...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello. I want to report a bug.
Under Edit > Add, there’s a textbox to input the path of the executable that is to be run with DxWnd (the "Path:" box), and next to the box is a button to browse the directory tree to locate the executable. This button works for me only for the very first program I add to DxWnd, but not for subsequent programs. This also happens in the Edit > Modify window of an already added program. When I click on the button anytime after I have added the first program, the mouse pointer turns into an hourglass for a brief moment and then reverts back to the arrow, and the directory browser does not come up. The button for the “Launch:“ box just underneath has the same bug. I can type the paths into both boxes manually but it’s an inconvenience. My OS is Windows XP Professional SP3 32-bit.
I tested the bug, but that doesn't happen on my pc with Win7.
Some DxWnd users also run it on WinXP, but nobody ever reported such a bug.
When you say first program, do you mean the first in a DxWnd run (so that the problem could be workarounded but exiting and starting DxWnd again) or just the game in the first position?
Is it possible that the problem depends on some directory access, antivirus protection or some other external cause. Have you set the DxWnd.exe with administrator's privileges?
I'll try to do some testing on XP, provided that I can still find a XP machine....
Thank you for the bug report, anyway. Maybe some other DxWnd user may help us.
By first program I mean the game in the first position: When a new build of DxWnd comes out, I extract it to a new directory. Then I go to Edit > Add to add my games from scratch. Until I add any games at all, I can click these buttons as much as I want and the directory browser will come up. As soon as I’ve used the Path: button to add the very first executable, i.e. as soon as the executable’s path has filled the box, I can not use the Path: button or the Launch: button anymore.
I noticed something after I wrote the above. When I add an executable’s path, the program creates a file called dxwnd.ini in its own directory. In that file is a line starting with “exepath”. As long as that line is there, the buttons won’t work. As soon as I delete that line and save the file, or instead delete the file, the buttons start working again. They stop working again when DxWnd adds exepath lines for the second, third, etc. programs.
I don’t think there’s a problem with directory access because there is nothing in this system that would restrict it. Nevertheless I tried this on two other drives and the problem persists.I have no antivirus programs running in the background and I’m running DxWnd under an account with administrator privileges. I’ve also tried running DxWnd in a virtual machine with a Windows XP guest OS, but the same thing happens there as well. Perhaps this has something to do with the fact that my Windows CD was customized with nLite.
Thank you for clarifying the scenario. In effect, I missed the part about the upgrade from a previous release reusing the old dxwnd.ini configuration file: it's something I don't have the habit to do usually, so likely I never realized the problem.
I also already noticed that DxWnd has this bad habit of dropping a copy of the dxwnd.ini file everywhere (i.e. when you export a game configuration, it likely writes there...).
I'll try to fix both problems. In the meantime, a good workaround (with the advantage of having an extra backup copy of the configuration) is to export all entries, do the upgrade with a fresh new dxwnd.ini file and reimport all entries. Stay tuned for an update ....
P.s. if it's not a problem for you, could you post here a copy of the dxwnd.ini file when the problem occours? I'd like to have a look inside ....
Last edit: gho 2015-10-12
Thank you for spending the time to solve this uncommon problem. I may have misunderstood your post but I hope you don’t think that I upgrade from old releases using an old dxwnd.ini file, because I don’t. I extract every new release to a fresh, empty directory that WinRAR creates upon extraction and I don’t have a dxwnd.ini file until DxWnd has created one in the new directory. I apologize if I've been unclear about this.
I’ve attached the file as it appears immediately after the path for the first executable populates the Path: box. The two lines in the file are enough to break the buttons. You will see that I added the DxWnd executable itself as the first program so that the problem would be easily reproducible, but it happens with other executables as well. Also attached is dxwnd.ini.1, which is the state of the file after I’ve saved the task list and exited DxWnd. This file breaks the buttons as well.
EDIT: The original file doesn't get renamed dxwnd.ini.1 by DxWnd, I renamed it to prevent confusion with the other file I attached.
Last edit: Retronomicon 2015-10-12
I think I understood you more clearly now, but I confirm that I never experienced this problem before. Trying your experiment step by step, it is absolutely normal that the dxwnd.ini gets created and then finally saved as in the two samples you posted.
The "exepath" value is used to store a folder to be proposed as a starting point for next time you add a new game. My best guess, so far, is that the folder has some capability problems (Microsoft is quite good at messing things up by assignign "special" capabilities), such as being a reserved folder like "Document and Settings".
This doesn't obviously mean this is not a bug and I'll try to fix it anyway, but if my guess is right, adding a game path in a different folder (like "Program files", maybe... I keep installing all my stuff under "D:\Games" to avoid such problems) may work ok.
By the way, look at what happened when I tried to replicate your experiment exactly by adding something under "C:\Documents and Settings":
I realize that some folders of Windows are problematic, but when I wrote in my second post that I tried this on two other drives without success, I meant that the game path as well as the DxWnd folder were on drives other than C, naturally in folders other than “Documents and Settings”. In fact, this problem first manifested in my D drive; I conducted further tests on the desktop only because it was more convenient. In any case, seeing as nobody else is experiencing the same problem, it is most likely that there’s a problem on my end; I hope I can find and fix it. Thanks for your efforts and for a great program, and for providing these free of charge.
Hey Retronomicon, you may want to try this method:
[window]
updatepaths=0
That's it, the textbox should fully functional and you can add a new application since now. Hope it help ;)
Last edit: Anonymous 2015-10-13
What a shame: I created that personalization flag just for this purpose, then I forgot ....
Even quicker, edit and copy dxwnd0.ini to dxwnd.ini, it will provide a clean fresh empty file to copy overeach time you want to reset the configuation, but preserving some general settings you may like. For instance, you can place there the key settings for the used special keys.
cloudstr, your method solved my problem.
gho, I will keep that in mind.
Thank you both.
Last edit: vpn20 2020-10-15
Maybe it is a WinXP-only bug? I have some difficulty to replicate ...
let's summarize (did I do anything wrong?)
In Win7 the FileOpen can't find the target folder, so it returns to propose the DxWnd own folder. If WinXP is different (I can check later) maybe I can make a fix.
Last edit: vpn20 2020-10-15
Yes, the bug is replicable here (XP only !!), though I'm not sure if it's a DxWnd bug or a MFC bug.
I'll have to check if the failed dialog operation is returning some sort of error code that would let me (at least) clear the poisonous folder value ...