I have two issues with TSaveDialog.

-
I have two issues with TSaveDialog.

1) It always appends the extension to the filename even if the filename already has the extension. Resulting in a filename with two or more extensions.

2) When I compile my project inside the IDE the TSaveDialog and TOpenDialog uses the new Windows vista style. When I compile the project via command line, using the exact same settings, the dialog paints with the old style.

Anyone with these issues?

Thanks.

Edit: using Tokyo latest release.

Comments

  1. David HeffernanJune 25, 2018 at 11:58 AM

    My save dialogs don't exhibit issue 1. And as for 2, it's because you aren't linking a manifest specifying the use of comctl32 v6. Don't use dcc32. Use msbuild. Then you will get the same build as from the IDE.

    ReplyDelete
  2. Luis MadalenoJune 25, 2018 at 2:29 PM

    David Heffernan I'm using Tokyo and when I build inside the IDE it calls dcc32.
    I even did copy of the entire command that the IDE uses, to a batch file to have the exact same settings but no luck.
    Issue 1 happens always.
    Tomorrow will check msbuild.
    Thanks.

    ReplyDelete
  3. Uwe RaabeJune 25, 2018 at 2:47 PM

    The IDE performs a call to the resource compiler before calling dcc32. Perhaps that is missing in your tool chain?

    ReplyDelete
  4. Vincent ParrettJune 25, 2018 at 3:12 PM

    finalbuilder.com - Windows Manifest Files

    ReplyDelete
  5. Luis MadalenoJune 26, 2018 at 4:18 AM

    Uwe Raabe No, I have that call in my batch file to compile my app.rc file, but my rc file was a custom copy of the VRC file that Delphi generates. That was the problem.

    ReplyDelete
  6. Luis MadalenoJune 26, 2018 at 4:19 AM

    Vincent Parrett Thanks. Creating my own manifest file instead of using the one Delphi creates solved the problem with issue #2.

    ReplyDelete
  7. Achim KalwaJune 26, 2018 at 5:13 AM

    Luis Madaleno Regarding Issue #1: Please check the value of SaveDialog.DefaultExt; it must NOT contain the period (.) of the default extension. So for a '.zip' extension use SaveDialog.DefaultExt := 'zip';

    ReplyDelete
  8. Luis MadalenoJune 26, 2018 at 6:36 AM

    Achim Kalwa Thanks. That's it!
    It's a bug in FastReport 6. I will fix it and report.

    ReplyDelete
  9. David HeffernanJune 26, 2018 at 9:47 PM

    Using msbuild is the best solution by far

    ReplyDelete
  10. Luis MadalenoJune 27, 2018 at 1:58 AM

    David Heffernan I need to test it a little more. I tried it yesterday but it creates a new rc and manifest files and I want my own.
    But after creating a new manifest and include it in my rc files everything works fine and I already have my build process automated.

    ReplyDelete
  11. David HeffernanJune 27, 2018 at 2:27 AM

    Luis Madaleno No, it's not that inflexible. You can setup your build process so that msbuild will run your scripts to customize resource generation as you please. The point is that you now have two build processes (IDE and automated). Change one and you have to duplicate the other. The point of using the msbuild approach, passing the dproj file, is that you have avoided that duplication.

    ReplyDelete
  12. Luis MadalenoJune 27, 2018 at 2:41 AM

    David Heffernan I only compile in the IDE for debug purposes. Deploy build is automated with batch files, since my app produces 38 exes (21 at 32bits and 17 at 64bits). And it works very well.
    It updates the RC files with the new app version; calls cgrc to compile it into a res files; calls fastdcc to build; calls signtool to add my digital certificate; and finally calls 7Zip to pack every exe and dll into it's own 7z file.
    The problem here with issue #2 was my RC file having an old manifest.
    But I will check msbuild better with more time.

    ReplyDelete
  13. David HeffernanJune 27, 2018 at 3:19 AM

    Debugging is important. It's crucial to know that you are debugging the same program that you are sending out to clients. Which is why a single build process is important. If you want to duplicate everything, that's your decision, but in my view it's a very wrong headed approach.

    ReplyDelete
  14. Luis MadalenoJune 27, 2018 at 7:43 AM

    David Heffernan My IDE does not use msbuild. I do not have that option active, so it uses dcc directly which is the same I do in my batch files.

    https://plus.google.com/photos/...

    ReplyDelete
  15. David HeffernanJune 27, 2018 at 8:24 AM

    No. Tokyo use msbuild. Which in turn prepares the command line for the call to dcc32 or dcc64 or the compiler matching your target. I will say no more.

    ReplyDelete
  16. Luis MadalenoJune 27, 2018 at 8:27 AM

    David Heffernan Are you saying that it uses MSBuild even if you do not check that option? And that the Build window shows a different thing than what it is actually doing?
    In that case shouldn't the Build window show a call to msbuild?

    ReplyDelete
  17. David HeffernanJune 27, 2018 at 8:36 AM

    That option allows the build process to execute in an external process. The point about using msbuild for your automated builds is that you are guaranteed to get the exact same options, pre and post build actions and so on as you do from the IDE.

    Frankly I don't really care any more. If you want to duplicate all of this build automation that is provided for you and if you want to run the risk of building with different options, paths etc., then go ahead.

    ReplyDelete

Post a Comment