When Vee won't open some files, I use Wordpad as well. Sometimes Vee forget
to put a bracket "]" in the proper place. I manually add the appropriate
character and can usually bring up the file. Sometimes however it cuts off
the file and forgets to save an entire section, then I can only go to the
backup.
Sincerely and God Bless,
Bill Fisher
Computer Marketing Services
----- Original Message -----
From: "Pat Vittorini" <pvittorini@rim.net>
To: <Bill_Karnavas@transarc.com>
Cc: "VEE Users Group (E-mail)" <vrf@lvld.agilent.com>
Sent: Friday, April 12, 2002 7:21 AM
Subject: RE: vrf VEE 6.01 Fatal Error
> Words to live by.
> On the odd time that a program becomes corrupted and won't open, I open
the
> ".bak" file in notepad or wordpad and save it as a ".vee" file. This has
> worked many times and saved me the frustration of having to redo the older
> version.
>
> -----Original Message-----
> From: Bill_Karnavas@transarc.com [mailto:Bill_Karnavas@transarc.com]
> Sent: Friday, April 12, 2002 7:37 AM
> To: vrf@lvld.agilent.com
> Subject: Re: vrf VEE 6.01 Fatal Error
>
>
>
> Just a couple comments on safe coding.
>
> I've been working with VEE for a few years now and it is not perfect,
> and will occasional eat a file.
> There are a couple practices that you can do to minimize the impact of
> these problems and generally improve your coding style.
>
> 1) Most important and already mentioned here, is to not keep saving to
> the same file. I tack a number on the end of my root file name and
> increment it as I go. I rarely work more than half an hour before
> saving to a new numbered file.
>
> 2) Going along with version numbers, I keep a notepad going in each
> file which comments on what I have been working on and is new or
> changed in each version. If a version becomes corrupted, by vee or
> disk, I can often look at the comments (using a text editor) and
> recall most of what was lost in that revision.
>
> 3) Keep code files reasonably sized. This was probably a factor in
> the original post on this, in my opinion, where the file was around
> 2MB. It is just good programming style to break large projects up
> into smaller groups of related functions, usually refered to as
> modules. There are lots of good programming reasons to do this, like
> making code reuse more practical and testing possible. In many of my
> own projects I find that there is a test as a whole that is run, but
> many times there is a need to run some part of an analysis outside of
> the whole and then taking that module and giving it a new front end
> makes for some real quick development of a new program that makes me
> look good. I try to keep modules down to 200-300K. Working on
> modules much bigger seems to bog down and the risk in code loss due to
> corrupt file goes up a lot.
>
> lBill
> ---------------------------------------------------------------------
> This is the "vrf" maillist, managed by Majordomo. To send messages to
> this maillist, just email to "vrf@lvld.agilent.com". Subscriptions and
> unsubscriptions are done through the address
"vrf-request@lvld.agilent.com".
> If you need details, just send a message containing the text "help"
> to "vrf-request@lvld.agilent.com".
> ---------------------------------------------------------------------
> ---------------------------------------------------------------------
> This is the "vrf" maillist, managed by Majordomo. To send messages to
> this maillist, just email to "vrf@lvld.agilent.com". Subscriptions and
> unsubscriptions are done through the address
"vrf-request@lvld.agilent.com".
> If you need details, just send a message containing the text "help"
> to "vrf-request@lvld.agilent.com".
> ---------------------------------------------------------------------
---------------------------------------------------------------------
This is the "vrf" maillist, managed by Majordomo. To send messages to
this maillist, just email to "vrf@lvld.agilent.com". Subscriptions and
unsubscriptions are done through the address "vrf-request@lvld.agilent.com".
If you need details, just send a message containing the text "help"
to "vrf-request@lvld.agilent.com".
---------------------------------------------------------------------
to put a bracket "]" in the proper place. I manually add the appropriate
character and can usually bring up the file. Sometimes however it cuts off
the file and forgets to save an entire section, then I can only go to the
backup.
Sincerely and God Bless,
Bill Fisher
Computer Marketing Services
----- Original Message -----
From: "Pat Vittorini" <pvittorini@rim.net>
To: <Bill_Karnavas@transarc.com>
Cc: "VEE Users Group (E-mail)" <vrf@lvld.agilent.com>
Sent: Friday, April 12, 2002 7:21 AM
Subject: RE: vrf VEE 6.01 Fatal Error
> Words to live by.
> On the odd time that a program becomes corrupted and won't open, I open
the
> ".bak" file in notepad or wordpad and save it as a ".vee" file. This has
> worked many times and saved me the frustration of having to redo the older
> version.
>
> -----Original Message-----
> From: Bill_Karnavas@transarc.com [mailto:Bill_Karnavas@transarc.com]
> Sent: Friday, April 12, 2002 7:37 AM
> To: vrf@lvld.agilent.com
> Subject: Re: vrf VEE 6.01 Fatal Error
>
>
>
> Just a couple comments on safe coding.
>
> I've been working with VEE for a few years now and it is not perfect,
> and will occasional eat a file.
> There are a couple practices that you can do to minimize the impact of
> these problems and generally improve your coding style.
>
> 1) Most important and already mentioned here, is to not keep saving to
> the same file. I tack a number on the end of my root file name and
> increment it as I go. I rarely work more than half an hour before
> saving to a new numbered file.
>
> 2) Going along with version numbers, I keep a notepad going in each
> file which comments on what I have been working on and is new or
> changed in each version. If a version becomes corrupted, by vee or
> disk, I can often look at the comments (using a text editor) and
> recall most of what was lost in that revision.
>
> 3) Keep code files reasonably sized. This was probably a factor in
> the original post on this, in my opinion, where the file was around
> 2MB. It is just good programming style to break large projects up
> into smaller groups of related functions, usually refered to as
> modules. There are lots of good programming reasons to do this, like
> making code reuse more practical and testing possible. In many of my
> own projects I find that there is a test as a whole that is run, but
> many times there is a need to run some part of an analysis outside of
> the whole and then taking that module and giving it a new front end
> makes for some real quick development of a new program that makes me
> look good. I try to keep modules down to 200-300K. Working on
> modules much bigger seems to bog down and the risk in code loss due to
> corrupt file goes up a lot.
>
> lBill
> ---------------------------------------------------------------------
> This is the "vrf" maillist, managed by Majordomo. To send messages to
> this maillist, just email to "vrf@lvld.agilent.com". Subscriptions and
> unsubscriptions are done through the address
"vrf-request@lvld.agilent.com".
> If you need details, just send a message containing the text "help"
> to "vrf-request@lvld.agilent.com".
> ---------------------------------------------------------------------
> ---------------------------------------------------------------------
> This is the "vrf" maillist, managed by Majordomo. To send messages to
> this maillist, just email to "vrf@lvld.agilent.com". Subscriptions and
> unsubscriptions are done through the address
"vrf-request@lvld.agilent.com".
> If you need details, just send a message containing the text "help"
> to "vrf-request@lvld.agilent.com".
> ---------------------------------------------------------------------
---------------------------------------------------------------------
This is the "vrf" maillist, managed by Majordomo. To send messages to
this maillist, just email to "vrf@lvld.agilent.com". Subscriptions and
unsubscriptions are done through the address "vrf-request@lvld.agilent.com".
If you need details, just send a message containing the text "help"
to "vrf-request@lvld.agilent.com".
---------------------------------------------------------------------
I've had VEE and my computer crash so many times that I now hit the save
button after every little change I make. In your case, when so many hours of
programming were at risk of being lost, I would have copied and pasted
everything into a new instance of VEE and then saved. Definitely tedious,
but it works...
Bill Drago
Test Engineer
L3 Communications - Narda Microwave East
435 Moreland Road
Hauppauge, NY 11788
William.Drago@L-3com.com
631-231-1700 Ext. 572
FAX 631-231-1480
> -----Original Message-----
> From: Eduardo Freitas [mailto:esfreitas@ptinovacao.pt]
> Sent: Thursday, April 11, 2002 8:06 AM
> To: VEE Email Reflector (E-mail)
> Subject: vrf VEE 6.01 Fatal Error
>
>
> Hi all,
>
> Last night, after working more than 5 hours on a new version
> of the program
> I am developing, when I tried to save the program, there was
> always an error
> message displayng on the screen (I dont' rememember exactly what it
> said...something "out of bounds") and didn't let me save the
> program. I
> tried to "save as" as another version, but the only solution
> was to quit the
> VEE environment. Then I checked there was a filename with the
> version I
> tried to "save as", but when I tried to open it, the
> following errors (in
> attachment) appeared and the file didn't open (I was
> completly frustrated
> looking at the blank screen). I tried to open the filename I
> was working on
> ..., no luck, the same thing happened.
>
> This is completely incredible and it's not the first time it
> happens to me.
> Who do I have to blame !? The VEE development team or me? Did
> I make any
> mistake?
>
> Is there any way to recover this files?
> I already looked at the files with a text editor, but the
> file is almost 2MB
> long and I don't have any expertize dealing with this files.
>
> I think I am going to work again on last saved project and write again
> everything, because I have to finish the program today to
> delivery my client
> Test Equipment today.
>
> I really appreciate any help
>
> Best regards
> Eduardo Freitas
> PT Inovo, S.A. - Plo de Lisboa
> Laboratrio de Calibrao e Ensaio
> Tel: +351 21 422 5732 Fax: +351 21 422 5701
> E-Mail: esfreitas@ptinovacao.pt
>
>
> ---------------------------------------------------------------------
> This is the "vrf" maillist, managed by Majordomo. To send messages to
> this maillist, just email to "vrf@lvld.agilent.com".
> Subscriptions and
> unsubscriptions are done through the address
> "vrf-request@lvld.agilent.com".
> If you need details, just send a message containing the text "help"
> to "vrf-request@lvld.agilent.com".
> ---------------------------------------------------------------------
>
---------------------------------------------------------------------
This is the "vrf" maillist, managed by Majordomo. To send messages to
this maillist, just email to "vrf@lvld.agilent.com". Subscriptions and
unsubscriptions are done through the address "vrf-request@lvld.agilent.com".
If you need details, just send a message containing the text "help"
to "vrf-request@lvld.agilent.com".
---------------------------------------------------------------------