URGENT: VFP app .exe: What is in one?

I have a problem with my app. I sent it down to operations. It
has knocked out printing. I suspect what the error is, and it is most
likely connected with a bad build. (I just changed the procedure a
bit, and it might not have been generated the new way.)

How do I tell what is in a VFP app .exe file? I suspect a couple
of files may be missing. I want to know if they are in the build.

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

Cy
Thu Apr 05 01:53:41 CDT 2007

Isn't that what testing is supposed to catch before you send the product
on to the users? Refox can show you the contents of the exe without
actually unpacking them if you want. But other than that if it were an
app I believe you can open it as a table (I think?) although I have
never tried. I do know that the components are actually in a table in
the app or exe but I don't know if VFP can see them as that.

Cy Welch
Senior Programmer
MetSYS Inc
http://www.metsysinc.com


Gene Wirchenko wrote:
> I have a problem with my app. I sent it down to operations. It
> has knocked out printing. I suspect what the error is, and it is most
> likely connected with a bad build. (I just changed the procedure a
> bit, and it might not have been generated the new way.)
>
> How do I tell what is in a VFP app .exe file? I suspect a couple
> of files may be missing. I want to know if they are in the build.
>
> Sincerely,
>
> Gene Wirchenko
>
> Computerese Irregular Verb Conjugation:
> I have preferences.
> You have biases.
> He/She has prejudices.

Ook
Thu Apr 05 09:42:26 CDT 2007

You cannot open an EXE or APP as a table. However, if you have ever
browsed through the exe and compared it to some of the files embedded
in it, it appears that some content does indeed exist in a table
format. If it's a small exe, then you could look into it to see what
is and what is not there, but it would probably be easier to look at
the project to see what got included and rebuild it if necessary. I've
*never* had to go looking into an exe to find out why something
doesn't work.

What does "It has knocked out printing." mean? It killed the printers?
Deleted printers? Or just doesn't print? Need more information....

On Apr 4, 11:53 pm, Cy Welch <cywe...@yahoo.com> wrote:
> Isn't that what testing is supposed to catch before you send the product
> on to the users? Refox can show you the contents of the exe without
> actually unpacking them if you want. But other than that if it were an
> app I believe you can open it as a table (I think?) although I have
> never tried. I do know that the components are actually in a table in
> the app or exe but I don't know if VFP can see them as that.
>
> Cy Welch
> Senior Programmer
> MetSYS Inchttp://www.metsysinc.com
>
> Gene Wirchenko wrote:
> > I have a problem with my app. I sent it down to operations. It
> > has knocked out printing. I suspect what the error is, and it is most
> > likely connected with a bad build. (I just changed the procedure a
> > bit, and it might not have been generated the new way.)
>
> > How do I tell what is in a VFP app .exe file? I suspect a couple
> > of files may be missing. I want to know if they are in the build.
>
> > Sincerely,
>
> > Gene Wirchenko
>
> > Computerese Irregular Verb Conjugation:
> > I have preferences.
> > You have biases.
> > He/She has prejudices.

Dan
Thu Apr 05 11:06:50 CDT 2007

I agree.

The project will give a full and complete list of everything that's included
in an exe. If a file isn't in the project it isn't in the exe.

"Knocking out printing" sounds suspiciously of a Windows Update thing I've
heard about in the last couple of days.

Dan


"Ook" <zootal@gmail.com> wrote in message
news:1175784146.310899.307300@w1g2000hsg.googlegroups.com...
> You cannot open an EXE or APP as a table. However, if you have ever
> browsed through the exe and compared it to some of the files embedded
> in it, it appears that some content does indeed exist in a table
> format. If it's a small exe, then you could look into it to see what
> is and what is not there, but it would probably be easier to look at
> the project to see what got included and rebuild it if necessary. I've
> *never* had to go looking into an exe to find out why something
> doesn't work.
>
> What does "It has knocked out printing." mean? It killed the printers?
> Deleted printers? Or just doesn't print? Need more information....
>
> On Apr 4, 11:53 pm, Cy Welch <cywe...@yahoo.com> wrote:
>> Isn't that what testing is supposed to catch before you send the product
>> on to the users? Refox can show you the contents of the exe without
>> actually unpacking them if you want. But other than that if it were an
>> app I believe you can open it as a table (I think?) although I have
>> never tried. I do know that the components are actually in a table in
>> the app or exe but I don't know if VFP can see them as that.
>>
>> Cy Welch
>> Senior Programmer
>> MetSYS Inchttp://www.metsysinc.com
>>
>> Gene Wirchenko wrote:
>> > I have a problem with my app. I sent it down to operations. It
>> > has knocked out printing. I suspect what the error is, and it is most
>> > likely connected with a bad build. (I just changed the procedure a
>> > bit, and it might not have been generated the new way.)
>>
>> > How do I tell what is in a VFP app .exe file? I suspect a couple
>> > of files may be missing. I want to know if they are in the build.
>>
>> > Sincerely,
>>
>> > Gene Wirchenko
>>
>> > Computerese Irregular Verb Conjugation:
>> > I have preferences.
>> > You have biases.
>> > He/She has prejudices.
>
>

Gene
Thu Apr 05 12:35:13 CDT 2007

Cy Welch <cywelch@yahoo.com> wrote:

>Isn't that what testing is supposed to catch before you send the product
>on to the users? Refox can show you the contents of the exe without

No. Testing can show the presence of bugs, but it can not show
their absence.

In addition, my user often recompiles though we are moving away
from that slowly.

>actually unpacking them if you want. But other than that if it were an
>app I believe you can open it as a table (I think?) although I have
>never tried. I do know that the components are actually in a table in
>the app or exe but I don't know if VFP can see them as that.

I tried, but did not see anything allowing me to figure out what
was in the .exe.

The problem was due to a difference between running off separate
files and having a .exe. copy file does not work with files included
in the project. Instead, I opened the report with use and copied it
with copy to.

[snip]

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

Gene
Thu Apr 05 12:37:06 CDT 2007

"Dan Freeman" <spam@microsoft.com> wrote:

>I agree.
>
>The project will give a full and complete list of everything that's included
>in an exe. If a file isn't in the project it isn't in the exe.

I could not rely on the project accurately reflecting the .exe.

>"Knocking out printing" sounds suspiciously of a Windows Update thing I've
>heard about in the last couple of days.

Unrelated. My app simply quit printing, because of a bug: a
difference between running the app as separate files and as a .exe.

[snip]

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

Ook
Thu Apr 05 12:58:16 CDT 2007

> Unrelated. My app simply quit printing, because of a bug: a
> difference between running the app as separate files and as a .exe.
>

Running as an APP versus running as an EXE does not cause printing
problems. Environment issues can. Missing files can. Deployment issues
can. I'm not aware of any actual bug that has to do with printing
problems that exist when running the exe versus the APP.

An EXE file is simply an app file with the appropriate header tacked
on to it to make it an executable. That is why it takes so long to
build an APP for a large application, but to go from the APP to the
EXE just takes seconds. And, when you build an EXE, VFP will first
build the APP, and then convert it to an EXE by tacking on the header
and a few bytes of footer. The contents of the APP remain inside the
EXE, unchanged.

Dan
Thu Apr 05 13:09:17 CDT 2007

"Gene Wirchenko" <genew@ocis.net> wrote in message
news:oqca131d4lmo13jnj2bi8ufn6tgbvcopok@4ax.com...
> "Dan Freeman" <spam@microsoft.com> wrote:
>
>>I agree.
>>
>>The project will give a full and complete list of everything that's
>>included
>>in an exe. If a file isn't in the project it isn't in the exe.
>
> I could not rely on the project accurately reflecting the .exe.

That's incorrect. Since an exe CANNOT be built any way except from a
project, the project always reflects the contents of the exe.


>>"Knocking out printing" sounds suspiciously of a Windows Update thing I've
>>heard about in the last couple of days.
>
> Unrelated. My app simply quit printing, because of a bug: a
> difference between running the app as separate files and as a .exe.

You said elsewhere it was a problem copying files. That will depend on the
type of file. "Executable" files (prg, etc.) never go into the exe -- the
compiled code does. TXT files, though, can be copied out of an EXE.

In your case, reports, VFP can be a bit hinky. We distribute reports in a
dbf inside the exe with one memo field for FRX and another for FRT. We copy
those to disk to let the user fiddle with them and still have the internal
"oh my god I've ruined it!" copy. <g>

Dan

Gene
Thu Apr 05 16:46:20 CDT 2007

"Ook" <zootal@gmail.com> wrote:

>> Unrelated. My app simply quit printing, because of a bug: a
>> difference between running the app as separate files and as a .exe.

>Running as an APP versus running as an EXE does not cause printing
>problems. Environment issues can. Missing files can. Deployment issues
>can. I'm not aware of any actual bug that has to do with printing
>problems that exist when running the exe versus the APP.

I was using the term "app" in the general sense, not as in a
.app.

Yes, there was a printing problem. It was because using copy
file on a project member does not work. That caused an error to be
thrown. That meant that the printing did not work.

[snip]

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

Gene
Thu Apr 05 16:52:39 CDT 2007

"Dan Freeman" <spam@microsoft.com> wrote:

>"Gene Wirchenko" <genew@ocis.net> wrote in message
>news:oqca131d4lmo13jnj2bi8ufn6tgbvcopok@4ax.com...
>> "Dan Freeman" <spam@microsoft.com> wrote:
>>
>>>I agree.
>>>
>>>The project will give a full and complete list of everything that's
>>>included
>>>in an exe. If a file isn't in the project it isn't in the exe.
>>
>> I could not rely on the project accurately reflecting the .exe.
>
>That's incorrect. Since an exe CANNOT be built any way except from a
>project, the project always reflects the contents of the exe.

No, it is perfectly correct. I do not control the files.
Operator error at the other end was the most likely possibility when I
first heard of the problem. I could not trust that things had been
done right. I wanted data that I could be sure of.

(Suppose that someone adds files to a project and does not
regenerate the .exe. Would the project reflect the .exe? I think
that the answer is a rather obvious no.)

>>>"Knocking out printing" sounds suspiciously of a Windows Update thing I've
>>>heard about in the last couple of days.
>>
>> Unrelated. My app simply quit printing, because of a bug: a
>> difference between running the app as separate files and as a .exe.
>
>You said elsewhere it was a problem copying files. That will depend on the
>type of file. "Executable" files (prg, etc.) never go into the exe -- the
>compiled code does. TXT files, though, can be copied out of an EXE.

It did not work for me. I was copying report files. The error
thrown was that the file (and a full path was given) could not be
found. No path was specified in the code, and the full path was of
the directory that I was testing in.

>In your case, reports, VFP can be a bit hinky. We distribute reports in a
>dbf inside the exe with one memo field for FRX and another for FRT. We copy
>those to disk to let the user fiddle with them and still have the internal
>"oh my god I've ruined it!" copy. <g>

It did not work for me. I changed my code to use <report>, copy
to . . ., use.

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

Cy
Fri Apr 06 02:14:34 CDT 2007

Gene Wirchenko wrote:

>> Isn't that what testing is supposed to catch before you send the product
>> on to the users? Refox can show you the contents of the exe without
>
> No. Testing can show the presence of bugs, but it can not show
> their absence.

Exactly my point. If you have changed the way the program is being run,
it is YOUR responsibility as the developer to test the application in
the configuration is it expected to run before passing it on to your
users. Frankly every time I have NOT made sure to test the way it will
be run, there has been at LEAST one problem I didn't anticipate that
simply running through the functions just once would have caught and
prevented.

>
> In addition, my user often recompiles though we are moving away
> from that slowly.
>

Having users recompile is IMHO always a bad idea. As a rule of thumb
the user shouldn't even have access to the code, as it just provides to
much chance for them to screw it up. And if there is one thing I have
heard from my/our customers over the years is "don't let us screw it
up". Our customers need to be able to create their own screens. Did we
give them access to the screen builder? No! We took the time to build
our own screen builder and rendering engine. Does it do everything the
VFP does? Of course not, but it also doesn't let them do something that
they shouldn't.

>> actually unpacking them if you want. But other than that if it were an
>> app I believe you can open it as a table (I think?) although I have
>> never tried. I do know that the components are actually in a table in
>> the app or exe but I don't know if VFP can see them as that.
>
> I tried, but did not see anything allowing me to figure out what
> was in the .exe.

If I want to see what's in the EXE I use Refox to open the EXE, it shows
me exactly what actually got into the EXE, no matter what the project
contains or claims.

>
> The problem was due to a difference between running off separate
> files and having a .exe. copy file does not work with files included
> in the project. Instead, I opened the report with use and copied it
> with copy to.
>
[snip]

As I said, exactly the kind of issue that good testing would have caught
before you turned it over. It took me years, but I have finally gotten
my boss to understand that we can spend the time to test it before it
goes out, or spend many times as much time on TA and bug fixes. It's
far more efficient to spend the time on properly testing the code in a
simulated production environment before release than just toss it from
the development machines to the users. Any time we shortcut the process
it comes back to bite us (just like it does every time MS rushes
something out).

Cy Welch
Senior Programmer
MetSYS Inc
http://www.metsysinc.com

Gene
Fri Apr 06 11:43:15 CDT 2007

Cy Welch <cywelch@yahoo.com> wrote:

>Gene Wirchenko wrote:
>
>>> Isn't that what testing is supposed to catch before you send the product
>>> on to the users? Refox can show you the contents of the exe without
>>
>> No. Testing can show the presence of bugs, but it can not show
>> their absence.
>
>Exactly my point. If you have changed the way the program is being run,
>it is YOUR responsibility as the developer to test the application in
>the configuration is it expected to run before passing it on to your
>users. Frankly every time I have NOT made sure to test the way it will
>be run, there has been at LEAST one problem I didn't anticipate that
>simply running through the functions just once would have caught and
>prevented.

My testing did not show that problem. I had no reason to suppose
that it would not work. Exhaustive testing is not practical if one
wants a program completed before the heat death of the universe.

The problem is not anything that I have ever seen documented.
Live and learn.

>> In addition, my user often recompiles though we are moving away
>> from that slowly.

>Having users recompile is IMHO always a bad idea. As a rule of thumb
>the user shouldn't even have access to the code, as it just provides to
>much chance for them to screw it up. And if there is one thing I have
>heard from my/our customers over the years is "don't let us screw it
>up". Our customers need to be able to create their own screens. Did we
>give them access to the screen builder? No! We took the time to build
>our own screen builder and rendering engine. Does it do everything the
>VFP does? Of course not, but it also doesn't let them do something that
>they shouldn't.

The "user" is my boss. He has a right to the code.

>>> actually unpacking them if you want. But other than that if it were an
>>> app I believe you can open it as a table (I think?) although I have
>>> never tried. I do know that the components are actually in a table in
>>> the app or exe but I don't know if VFP can see them as that.
>>
>> I tried, but did not see anything allowing me to figure out what
>> was in the .exe.
>
>If I want to see what's in the EXE I use Refox to open the EXE, it shows
>me exactly what actually got into the EXE, no matter what the project
>contains or claims.

I doubt that my boss will pony up for that. Fortunately, this
was an edge case that is unlikely to happen again.

>> The problem was due to a difference between running off separate
>> files and having a .exe. copy file does not work with files included
>> in the project. Instead, I opened the report with use and copied it
>> with copy to.
>>
>[snip]
>
>As I said, exactly the kind of issue that good testing would have caught
>before you turned it over. It took me years, but I have finally gotten
>my boss to understand that we can spend the time to test it before it
>goes out, or spend many times as much time on TA and bug fixes. It's
>far more efficient to spend the time on properly testing the code in a
>simulated production environment before release than just toss it from
>the development machines to the users. Any time we shortcut the process
>it comes back to bite us (just like it does every time MS rushes
>something out).

Actually, with my system, we do fairly well. The things that I
get caught on are usually 1) those where my boss and I miscommunicated
or 2) where VFP works differently than expected, either because it is
documented poorly or not at all.

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

swdev2
Sun Apr 08 22:10:42 CDT 2007

Heya G Man -
there is a chance your boss can tell you where it failed, though,

Only a chance, not 100 percent, not foolproof , not guaranteed.

Load up vfp
load up debugger
launch the application from debugger

when it blows, click 'suspend'
you can MAYBE see the code in the debugger where it fails.
maybe....

Mondo Regards [Bill]

--
===================
William Sanders / EFG VFP / mySql / MS-SQL
www.efgroup.net/vfpwebhosting
www.terrafox.net www.viasqlserver.net

"Gene Wirchenko" <genew@ocis.net> wrote in message
news:hbb813thehnstbot21s6gjn49u6pevh3jm@4ax.com...
> I have a problem with my app. I sent it down to operations. It
> has knocked out printing. I suspect what the error is, and it is most
> likely connected with a bad build. (I just changed the procedure a
> bit, and it might not have been generated the new way.)
>
> How do I tell what is in a VFP app .exe file? I suspect a couple
> of files may be missing. I want to know if they are in the build.
>
> Sincerely,
>
> Gene Wirchenko
>
> Computerese Irregular Verb Conjugation:
> I have preferences.
> You have biases.
> He/She has prejudices.