3

I have a pre build event set up to generate the version/build number to embed in my exe. The event consists of a call to a batch file that does the actual work (a parameter is passed to the batch file). The batch file works as it should on all of the computers I've tried it on, including the Windows XP computers. It also runs fine as a pre build event on the 3 computers here running windows 7. The pre build event fails, however, on Windows XP. Delphi returns an error code that I can't seem to find a reference to anywhere, "20018".

I've tried a number variations to the way I call the batch file without any luck. Does anyone have an idea what's happening?

The build event is as follows:

call "..\..\Build Tools\PreBuild.bat" "$(PROJECTDIR)"

UPDATE: I've removed the source of the batch file, since it had no relevance for the actual problem.

boileau
  • 817
  • 6
  • 20
  • 5
    Jason, how can anyone possibly tell you what might be wrong with no more information than what you've provided? We don't know what the batch file contains, where the folder locations are, anything about your rights under XP (admin, power user, limited user), or anything else that might help. Any attempt to answer would simply be guesswork, and that isn't useful. You need to provide more information if you want help resolving this - remember, we can't see your screen from here, and only have the information you provide in your question. – Ken White Jun 21 '11 at 22:24
  • 4
    To answer your question Ken - someone who recognises error code 20018 in the context of a pre-build event might have some insight. So that is how someone could possibly tell the OP what might be wrong. For anyone not recognising that specific error code, yes some more information would be helpful, but I'm not so sure that a high handed and condescending critical comment is any more effective at eliciting that information than the original question would be at eliciting a helpful answer without that information. We should try to remember that our exp. (in Delphi or SO) is not universal. – Deltics Jun 21 '11 at 23:44
  • 1
    @Jason - as Ken said in a slightly different fashion, :), the lack of google hits on that error code suggests that the problem is quite specific to something in the batch file or the environment in which it is running. Have you tried running the batch file in isolation on the XP machine in question ? (it is not 100% clear that you have from your question). If so (or indeed, if not, do so and) what results does that yield ? Could you provide some more detail about what the batch file contains ? The more additional information as you can share the more likely someone may be able to help. – Deltics Jun 21 '11 at 23:47
  • 1
    Show us the batchfile, and the parameters that you provide to it. Without that it's just really difficult to help you. – Wouter van Nifterick Jun 22 '11 at 00:30
  • @Deltics: Thanks for the advice. I'll try and keep it in mind. While we're on the subject: I have a problem with my car. It's a Hyundai. The check engine light came on, and it flashes three times. I'm not going to tell you any more about the problem (not how it's behaving, not how it's running - nothing more than that the light flashes three times). Can you tell me how to fix it? Thanks in advance. :) – Ken White Jun 22 '11 at 00:45
  • @Ken Welcome to the pedestrians world, and save the planet! – Arnaud Bouchez Jun 22 '11 at 05:08
  • Have you tried running it on another XP machine? – Jaco Briers Jun 22 '11 at 08:33
  • 1
    @Ken - if that were a genuine request and if I had owned a Hyundai that had exhibited the same problem then I could share that experience and the outcome in MY case and that in turn might help you. As it is, I drive a Mazda. But I wouldn't shoot you down for *my* inability to help based on the information you've provided. Instead I might ask what the Hyundai owners manual tells you that 3 flashes means and go from there. I continue to be thankful that I wasn't "assisted" by some of the people on here and the attitude they have developed these days, back when I was finding my way in Delphi. – Deltics Jun 23 '11 at 04:28
  • @Ken - You'll notice that I didn't ask for "The Answer". I don't think that even I have enough information for anyone to come up with the final answer. I asked for ideas. You posit that guesswork would not be helpful. On the contrary, guesswork (educated guesses, if you will) would help me to know where to look next, and to know what other information I should find to aid in solving the problem. – boileau Jun 23 '11 at 12:17
  • @Jason: "Educated guesswork" means you have some information on which to base that "educated guess" on. You didn't provide enough for even a SWAG (stupid wild a&&ed guess), and that's what I (and others) were complaining about. Note that I wasn't in the first 60% to vote to close? I gave you tons of time to provide the additional info. You chose not to do so. – Ken White Jun 23 '11 at 13:59
  • @Deltics: But it would be a lot more helpful if I told you what year Hyundai, what model, and how it was behaving (other than the thrice flashing light), wouldn't it? And, since it costs nothing to post here, it wouldn't be a big deal for me to provide that info? (Or for you to ask for it, like i did of Jason?) Remember we have no info other than what's provided here to go by. I'll tell you what: Next time you're ill, call your doctor's office, say "I don't feel well. Tell me what might be wrong.", and see if you get an answer without being asked to provide a WHOLE lot more information first. – Ken White Jun 23 '11 at 14:02
  • 1
    This should be reopened now that the OP has posted additional info. – Warren P Jun 23 '11 at 15:20
  • @Ken, yes and you might expect me to politely ask for that information, not to slap you down for not providing it in the first place and then "shut you up" by simply yanking your question for not being up to your high standards. It wasn't about what you said or asked for, but the tone with which you asked for it, or rather the way you spanked the OP for not having provided it in the first place. – Deltics Jun 30 '11 at 03:51
  • @Deltics: You're absolutely right. I should absolutely ignore the fact that the question is entirely unanswerable as posted, search google for a word or two in the question, post it as an answer, and upvote it. Thanks for the advice - I'm new here, and didn't understand how this site works. I explained why the question was not asked in an answerable manner, and provided a similar example of a poorly worded question (which you couldn't answer as posted, BTW). The fact that you're still going on about it almost 10 days later is a little confusing, though. – Ken White Jul 01 '11 at 02:08
  • @Ken - Perhaps you could define "unanswerable" for me ? I have previously posted a question on SO that didn't get a single answer - seemingly a text book definition of "unanswerable". Yet it was a perfectly good and complete question. *This* question, as originally posted, was deemed by you to be unanswerable, yet it attracted at least one answer. Clearly your idea of "unanswerable" doesn't fit that of the OED. Also note that posing a question specifically designed to be unanswerable does not in any way establish the "answerability" of another question. – Deltics Jul 10 '11 at 20:43

2 Answers2

2

You gave so little information that I am tempted to vote to close. Instead I will venture a wild guess. You should post the commands in your post-build step.

If you don't know which line is failing, try the first one alone, and remove the rest, and see if that passes.

For example, I often have problems on XP machines using XCOPY commands in post-build steps, and these commands often result in really odd error codes that I am unable to diagnose or determine the meaning of. So if you have an XCOPY command, you should try the XCOPY inside and outside the build environment, and see if it works on that Windows XP box, for example.

You can copy the commands, as they are run, in their macros-expanded form, from the "Output" tab in the Rad Studio IDE, paste them into notepad, run them as a batch file, and try to figure out why they don't work on windows XP.

Here's an example of a workaround, using XCOPY. If this fails on XP, I tweak it till it works:

 XCOPY  SourceDir DestDir

I have had to fix it this way:

 XCOPY.exe  SourceDir DestDir

In another case, I found that I had to fix it this way:

 call XCOPY SourceDir DestDir

You ALSO mention you are simply running a mysterious batch file and you fail to mention what it does. So let's see, what we could do differently to run a batch file from a post build step.... When I run a batch file like this, I sometimes have problems on XP, like this:

batchfilename.cmd

But when I run it differently, I find it worked on XP, but I lose the command line output:

call batchfilename.cmd

It seemed that something strange was happening when running post-build steps in the IDE, that could be resolved by trying the commands outside the IDE, in various forms.

The number (20018) you mention is a bit of a silly thing to go googling, it's probably the ERRORLEVEL (return value to the command shell) of whatever tool you are running in your batch file. Since you told us nothing about what tools you're running, I wonder if you have even done the basic step of looking at what happens when you run that batch file OUTSIDE the IDE on that XP machine. My guess is that if it didn't come from your own batch file, that it came from deep in the guts of MSBUILD itself, which is something that very few Delphi people will know the source code to (even the Delphi team itself is using a binary from Microsoft to provide MSBUild functionality). I notice that MSBUILD's built in tasks for doing post-build and pre-build steps are an area of the IDE that need improvement, especially when it comes to debugging problems like this. You can however, simply run them outside the IDE and see if they work that way, and you can try stuff, as I have suggested above.

If this is your batch file ... I suggest that due to dependency issues, you might not want to use such a batch file technique to modify an RC file, as it might expose some strange dependency issues in MSBUILD with RAD/Delphi build tasks. I have also seen some weird BRCC32 failures, on XP that I have not been able to reproduce.

Community
  • 1
  • 1
Warren P
  • 65,725
  • 40
  • 181
  • 316
2

Ok, I finally found the answer here: http://delphi.about.com/od/devutilities/a/pre_post_build.htm

The problem was spaces in the path to the batch file being called. Apparently this isn't a problem in Windows 7.

Removing the space in the build tools directory and changing the pre build event to the following fixed the problem:

call ..\..\BuildTools\PreBuild.bat "$(PROJECTDIR)"

Here's the important bit from the link:

Command Line: This is the trickiest of them all, but after you get one working, they’re all easy. The trick here is not to use quotes on the program’s name but instead use the windows SFN (Short File Name). The reason is that, should you need to use quotes to enclose the path of your file, the IDE gets confused with too many quotes. So, these are the wrong ways of adding that command line above:

C:\Program Files\SoftwarePassport\Armadillo.exe D:\Dev\My Prog\Prot.arm /P

"C:\Program Files\SoftwarePassport\Armadillo.exe" D:\Dev\My Prog\Prot.arm /P

C:\Program Files\SoftwarePassport\Armadillo.exe "D:\Dev\My Prog\Prot.arm" /P

"C:\Program Files\SoftwarePassport\Armadillo.exe" "D:\Dev\My Prog\Prot.arm" /P

This last one should work, if it were not for the IDE to be confused with it. So, what does work is either of these: C:\Progra~1\Softwa~1\Armadillo.exe "D:\Dev\My Prog\Prot.arm" /P

C:\Progra~1\SoftwarePassport\Armadillo.exe "D:\Dev\My Prog\Prot.arm" /P

boileau
  • 817
  • 6
  • 20