Alexander!
Function CenterDOSBoxWindow centers wrong windows - same case as when restoring.
Maybe you may use GetWindowLong to retrieve application handle? (I can not check it now.) And filter 'DOSBox Status Window' - if you do not want to center it too.

Hi skatz,
I have started working on the smaller things:

4. and 6. from your first post and 1.-3. from your second post: Fixed.

4. ScummVMSettings:
- 'music_driver': Fixed. (Was a bug in profile editor; but also changed ini creation to fix the problem in old profiles on the fly without having to open them in profile editor first.)
- 'extra_path': Added.
- correct copying default ini sections: Fixed.
- Do not copy [game] section: Changed.

1. After minimizing main window and restoring it, DFR loses window position and moves to screen bottom.

Sorry, I can not reproduce this behavior yet. Can you tell me more about this ? (DFR minimizes just like any other Windows program so just minimizing and then restoring the window should not change its position.)

2., 3., 5. and 5. from your first post -> weekend

And finally the things "for the next version" are just added to my 0.7.0 todo without reading them in detail yet, because of the growing known bugs list I want to finish 0.6.0 as soon as possible.

And not to forget:
Hi sst,
this problem belongs to the already discussed long->short name problem. I hope the new way of making short names will fix this, too.

Alexander!
About restoring minimized windows. Well, bottom is irrelevant. You restore saved window position stored on every resize. Moving windows omitted. Store bounds on minimizing.

And one more: options to covert all waves to mp3/ogg in screeshots pane do not work - you forgot to add separator between directory and filename.

And may you add +/- shortcuts to video viewer too?

Hi, Alexander!
About centering DOSBox window:
Possible solution is:
- after CreateProcess get ProcessId from PROCESS_INFORMATION
- pass it to EnumWindow as second argument
- in EnumWindowProc call GetWindowThreadProcessId
- if obtained process identifier equals to second argument(lparam) then this window belongs to created process
- call GetClassName for this window, class 'SDL_app' is main window, 'ConsoleWindowClass' - console

This method work for DOSBox and ScummVM. You may center windows and hide scumm console at last.
And use WaitForInputIdle instead of Sleep.

About using batch files:
As I understand you use batches only for redirecting stdin/stdout.
You may use CreateProcess instead, specifying in STARTUPINFO handles for previously opened files/pipes for standard streams. MSDN example -
http://msdn.microsoft.com/en-us/library/ms682499
While you continue to use batch files, please, convert filename which you put in them through AnsiToOEM.
And also convert image file name that you pass to input file for mkdosfs. (it is only dos executable you use - maybe recompile it to win32 console?)

And again about text file linebreaks:
since you allow to open almost any file in text editor (quick starter and data folder) automatic conversion may break some data file.
I think that silent conversion should be done only for conf files (main and per profile configs) you maintain. For all other files show warning with explanation that file may become broken and allow user to choose way to continue (convert/not convert/cancel).

Alexander, please, put dosbox.conf passed to dosbox as '-conf' parameter in quotes.

And I recompiled mkdosfs to win32. Now it accepts ANSI filename in input file (through redirection). No need to convert to OEM.

UPDATED: little buffer protection and source added. Sorry.

Hi skatz,
you are much faster than me. I've already started working on the issues you reported but it seems I cannot keep pace with you. What I've done so far (since end of last week):

• Fixed: options to covert all waves to mp3/ogg in screeshots pane
• Added: +/- shortcuts to video viewer
• Quick Starter:
  - Added: menuitem 'open in standard ...' as in screenshots tabs.
  - Name 'run' item as 'open' for non executables.
• Data viewer: Added: menuitem 'open in standard ...' as in screenshots tabs.
• Fixed: When running ScummVM: Use game dir for savepath= instead of value from scummvm.ini if 'Use game folder' is selcted
• Added: Optional column "Notes" in games list
• Changed: Fixing line break will only work on files with text file extensions now

All other open things are still on my todo.

Hi, Alexander!
Of course, I am faster. Because, I have your nice (and working) program and very readable source code. Ahem, that was an attempt to say 'THANK YOU FOR YOUR GREAT WORK!'.

And again (don't shoot me) some more notions:
- about window classes - I found one exception: Daum Cafe build creates window 'Mainframe' instead of 'SDL_app'
- when I have said about 'WaitForInputIdle' I was wrong. I tried to use it in sample project and with DOSBox it failed. Nice idea,but it doesn't work
- possible bug: when DFR window is auto restored after closing DOSBox, main window is shown on top, but loses focus (not active). Maybe it is connected with changing window position?

Maybe it is time to change the topic title, and remove the "new" part?

Hi skatz,

first of all: Thank you. All I wanted to do was just creating some little useful frontend (for me).

I've done a lot of bug fixing the last days. The center DOSBox and ScummVM function (with GetWindowThreadProcessId on ProcessID from CreateProcess) is working very well now. And I think, I've also understood your move-window-problem now: It's not about minimizing and restoring the DFR window (just manual) but when running DOSBox. It also happens without minimizing the window and it's about changing the Windows resolution. Now I'm monitoring the WM_MOVE events and resetting the old position under some conditions.

I have also written some little long to short path name test program. It will show the way the new algorithm is working. ... And as soon as the Sourceforge shell access is up agian I will upload it so all of you can test if it's working the right way on your system.

And last but not least:
Hi MiniMax, yes, this is a good idea, I have changed the "(new frontend)" to "(DOSBox frontend)" as subject of this post. But I don't know if this changes the topic of the whole post.

Greetings
Alexander

Alexander - you need to go back to your first post and edit that.

hi there!

i've just stumbled across D-Fend Reloaded and i'm very impressed by it. i've been using D-Fend and then D.O.G., but development seems to have stopped on both, so i was looking for something new. and along came D-Fend Reloaded. i must say it's by far the coolest DOSBOX-frontend i've seen so far! great work! 😁

i have a little feature-request however:
i'm using a xbox360 controller for windows, and with it a great tool called XPADDER. in case you don't know it, XPADDER allows game-profiles for many gamepads and other controllers. with it you can match any keyspresses and mousemoves to the controller-buttons. you can do a lot with it, and this way it's also great and easy to control old dos-games. you just have to create a profile , and then load it everytime before you play the game. every profile is saved as a file, so you just have to execute that file, and xpadder is started with that profile.

now thats where my feature request comes in:
it would be great to be able to execute a file (e.g. the corresponding xpadder-profile, or any other .exe or .bat file) in windows BEFORE launching the DOSBOX-game in D-Fend Reloaded.

additionally to that, you could also include the possibility to execute a file AFTER the the exit from the game.

this feature could not only be used for XPADDER, but for many other things. with the use of .BAT-files, it would greatly extend the possibilities of D-Fend Reloaded.

if there already is such a function, and i just haven't found it yet, please tell me and forget about this post. 😉

best regards,
mandark

Hi mandark0,

this is a very good idea and no, there is no way to make D-Fend Reloaded do this at the moment. (Before someone suggests instead of calling DOSBox.exe directly calling a batch file which will run XPADDER and then DOSBox: In DFR you can only configurate paths to custom DOSBox versions, not the actual file to run. DFR will always try to find a DOSBox*.exe file in the given directory.)

I have added your request to my todo list. But because I'm trying to release D-Fend Reloaded 0.6 beta 2 by the end of the coming week (and this release will be feature complete to the final version of 0.6), it is very likely this feature won't make it to the 0.6 release. But if it won't come to 0.6 it will definitely be in the 0.7 release.

Greetings
Alexander

Hi all,

we are getting closer and closer to the second beta release of the next major release of D-Fend Reloaded.

I have already updated the beta download page with a list of all changes since beta 1, a list of all currently open todos for beta 2 and all still open feature requests. (So if you have some feature requests you can see on this page if the thing you want to have is already on my todo.)

Short path names the DOSBox way

As already widely discussed, DOSBox and Windows are not always using the same short name for a long name. The algorithm used in D-Fend Reloaded up to version 0.6b1 provided in most cases identical results to the one in DOSBox - but not in all. The second beta release will introduce a new algorithm which will hopefully always gives the same short names as DOSBox does.

On the beta download page you can already find a long to short path name tester. This program will convert a given long path name to a short name (the DOSBox way) and will output a lot of debugging information. If you are using long path names inside your DOSBox drives please test with this program if the new algorithm in D-Fend Reloaded is working the right way for you. Thank you.

Alexander wrote:

Hi mandark0, […]
Show full quote

Hi mandark0,

this is a very good idea and no, there is no way to make D-Fend Reloaded do this at the moment. (Before someone suggests instead of calling DOSBox.exe directly calling a batch file which will run XPADDER and then DOSBox: In DFR you can only configurate paths to custom DOSBox versions, not the actual file to run. DFR will always try to find a DOSBox*.exe file in the given directory.)

I have added your request to my todo list. But because I'm trying to release D-Fend Reloaded 0.6 beta 2 by the end of the coming week (and this release will be feature complete to the final version of 0.6), it is very likely this feature won't make it to the 0.6 release. But if it won't come to 0.6 it will definitely be in the 0.7 release.

Greetings
Alexander

this is absolutely great! 😁

Can anyone explain how to get Guilkoza's pixelshaders working via D-Fend reloaded? D-Fend keeps overwriting the conf, and there's no option in D-Fend Reloaded to set scaler to hardware2x (or 3x) - which the pixelshaders require, and no option to set the pixelshader option.

I've tried doing it manually but neither works. I'm even using the latest beta. Are these options going to be added to the next version of D-Fend reloaded to better increase compatibility with Guilkoza's DosboxCVS?

Thanks!

Also - D-Fend Reloaded is seriously kick ass now that I've learned how to work it properly.

I have a thumb drive that I carry around a host of games on at work and at home and DFR has made booting and playing them a BREEZE. Awesome work, thanks a lot!

Hi illuminerdi,

adding some other default values to the scaler dropdown box is very easy: Just go to the default values page in the setup dialog and add the scaler values you want to have to the dropdown box in the edit field. The format is "<Name for the user> (<value given to DOSBox)" like "Nearest neighbor upscaling with factor 2 (normal2x)". And while the setup dialog is already open, also check the page "DOSBox CVS features". On this page you can activate some setting normally invisible in the profile editor.

And last but not least: You can also add any configuration settings to the DOSBox conf file by writing them in the "User settings" box on the "DOSBox settings" page of the profile editor. (Becasue this values are added at the end of the conf file, you can also overwrite any other settings in the conf file by adding lines here.)

At the moment I'm just implementing the last features for the 0.6 release. This means the feature wish list for this version already closed. But there will be more releases after 0.6, so if you have any special CVS features you think that should get GUI elements in D-Fend Reloaded, just tell me. May be the next release then will bring them. (Of course hidden in normal mode and activateable via the "DOSBox CVS features" pages.)

Greetings
Alexander

Oh that's fantastic! I knew I could add custom resolutions, but I completely spaced about adding other options to other dropdowns. I'll just give those a quick edit and be on my merry. Thank you very much for the help!

So, I'm getting closer. I added the hardware3x value to the scaler and that functions correctly, but the pixelshader option still doesn't work, and here's why:

pixelshader=XXXXX needs to be listed under the [SDL] heading of the conf file, the custom settings box you're referencing tags onto Autoexec.bat/the end of the config file. AFAIK this doesn't work, as I tried adding it and it doesn't even recognize the command as occuring.

I did have the DosboxCVS settings already enabled, and the lack of these features if what prompted me to post, but thanks for pointing me there anyway.

So what I need at this point is some way to add a custom setting to the SDL section of the config file. Realistically the only way this will probably happen is via code support from the D-Fend Reloaded programmers, but if there is a way to add a custom variable to fall under a specific heading in a .conf file, I'm all ears. Thanks anyway for the help though!

Aha!

I did make it work using that suggestion - if in the Custom Settings box I put in

[SDL]
Pixelshader=blahblah

it DOES work at that point! So...if anyone else was wondering how to do that, there ya go. I should probably stop posting here and start spending more time trial-and-erroring stuff.

Thanks again!