wpw_tool_borl_95.html

VC programing

{
 DEFPUSHBUTTON "OK", 542, 102, 147, 50, 14
 PUSHBUTTON "Cancel", 341, 201, 149, 50, 14
 PUSHBUTTON "Help", 963, 201, 131, 50, 14
 COMBOBOX 521, 5, 21, 24, 130, CBS_DROPDOWNLIST | WS_TABSTOP
 COMBOBOX 522, 35, 21, 24, 130, CBS_DROPDOWNLIST | WS_TABSTOP
 COMBOBOX 523, 65, 21, 24, 130, CBS_DROPDOWNLIST | WS_TABSTOP
 COMBOBOX 524, 103, 21, 24, 33, CBS_DROPDOWNLIST | WS_TABSTOP
 COMBOBOX 525, 141, 21, 24, 130, CBS_DROPDOWNLIST | WS_TABSTOP
 COMBOBOX 526, 174, 21, 45, 130, CBS_DROPDOWNLIST | WS_TABSTOP
 COMBOBOX 527, 228, 21, 30, 130, CBS_DROPDOWNLIST | WS_TABSTOP
 LTEXT "Hour", -1, 10, 13, 17, 8
 LTEXT "Minute", -1, 37, 13, 20, 8
 LTEXT "Second", -1, 65, 13, 25, 8
 LTEXT "AM/PM", -1, 104, 13, 23, 8
 LTEXT "Day", -1, 145, 13, 14, 8
 LTEXT "Month", -1, 184, 13, 20, 8
 LTEXT "Year", -1, 233, 13, 17, 8
 EDITTEXT 537, 6, 94, 90, 12
 EDITTEXT 539, 6, 121, 90, 12
 PUSHBUTTON "Browse...", 540, 102, 120, 50, 14
 PUSHBUTTON "Browse...", 538, 102, 93, 50, 14
 EDITTEXT 541, 6, 148, 90, 12
 LTEXT "Working Directory", -1, 7, 112, 60, 8
 LTEXT "File", -1, 7, 86, 60, 8
 LTEXT "Command Line", -1, 6, 140, 60, 8
 LTEXT "/", -1, 222, 23, 4, 8
 LTEXT "/", -1, 168, 23, 4, 8
 LTEXT ":", -1, 31, 22, 4, 8
 LTEXT ".", -1, 61, 24, 3, 8
 LTEXT "Begin cycle at...", -1, 6, 4, 60, 8
 COMBOBOX 531, 5, 61, 24, 130, CBS_DROPDOWNLIST | WS_TABSTOP
 COMBOBOX 532, 35, 61, 24, 130, CBS_DROPDOWNLIST | WS_TABSTOP
 COMBOBOX 533, 65, 61, 24, 130, CBS_DROPDOWNLIST | WS_TABSTOP
 COMBOBOX 534, 141, 61, 24, 130, CBS_DROPDOWNLIST | WS_TABSTOP
 COMBOBOX 535, 174, 61, 45, 130, CBS_DROPDOWNLIST | WS_TABSTOP
 COMBOBOX 536, 228, 61, 30, 130, CBS_DROPDOWNLIST | WS_TABSTOP
 LTEXT "Hour", -1, 10, 53, 17, 8
 LTEXT "Minute", -1, 37, 53, 20, 8
 LTEXT "Second", -1, 65, 53, 25, 8
 LTEXT "Day", -1, 145, 53, 14, 8
 LTEXT "Month", -1, 184, 53, 20, 8
 LTEXT "Year", -1, 233, 53, 17, 8
 LTEXT ":", -1, 31, 62, 4, 8
 LTEXT ".", -1, 61, 64, 3, 8
 LTEXT "Repeat every...", -1, 5, 44, 60, 8
 CONTROL "", -1, "BorShade", 2 | WS_CHILD | WS_VISIBLE, 6, 40, 251, 1
 CONTROL "", -1, "BorShade", 2 | WS_CHILD | WS_VISIBLE, 6, 80, 251, 1
}


1 VERSIONINFO 
FILEVERSION 1, 0, 0, 0
PRODUCTVERSION 1, 0, 0, 0
FILEOS VOS_DOS_WINDOWS16
FILETYPE VFT_APP
{
 BLOCK "StringFileInfo"
 {
  BLOCK "040904E4"
  {
   VALUE "CompanyName", "My Company\000\000"
   VALUE "FileDescription", "Description from .def file here\000"
   VALUE "FileVersion", "1.00\000\000"
   VALUE "InternalName", "Application name\000"
   VALUE "LegalCopyright", "Copyright \251 My Company 1993\000\000"
   VALUE "OriginalFilename", ".exe file name here\000"
  }

 }

 BLOCK "VarFileInfo"
 {
  VALUE "Translation", 1033, 1252
 }

}
<HR>
In article <3tju2q$[e-mail]>,
   [e-mail] (Benjamin "Quincy" Cabell V) wrote:
>Hello -
>
>I think there must be a bug in the Resource Workshop...  or else I am
>making a very very stupid mistake.  I made up these pull down menus in
>RW, assigned all the ID numbers, wrote some code to activate
>functions, and compiled the code.  When I ran it, the first of the
>three pop-up menus in the third pop-up menu was greyed.  I checked the
>ID numbers, all were fine.  I changed the ID numbers of the greyed
>item, just to see what would happen.  I recompiled.  Upon running, now
>both the first and second pop-up menu in the third pop-up menu were
>greyed.  I changed the ID number of the second item, recompiled,
>reran, and all three pop-up menus in the third pop-up menu were
>greyed.  I am including a resource header file in the main CPP file
>that contains all the info in the .rc file, and I updated it each time
>to reflect the changes in ID numbers I made.  I edited the the .RC
>script and removed the popup specifier that placed all three of those
>pop-up menus in a pop-up menu, now they were just on the main pull
>down menu bar.  I recompiled, and ran the program.  Those pull downs
>were on the main bar, each one is not greyed, and all of them call
>their appropriate functions in the CPP file.  So, their IDs must be
>right.

This sounds like a 'feature' of Borland that was introduced in 4.5. The 
feature is that the popup menu item can be disabled/enabled. The ID of 
the popup menu is the ID of the first menu item - 1. You need a command 
enabler for this to enable it. If you really have a need to disable the 
popup's then this is useful, but having a default state of disabled is 
not a good design.

This seems to have been corrected in the 4.51 release of the compiler.

Later
  Tandy Penn


-----------------------------------------------------------------
Opinions expressed here are mine and mine alone, and not those of
Texas Instruments, or anybody else.
-----------------------------------------------------------------
Tandy Penn                      TI MSG TPEN
Texas Instruments, Dallas TX.   Inet: [e-mail]
Voice [phone]             Fax [phone]
"Beware of programmers that carry screwdrivers."
                            \|/
                            @ @
------------------------oOO-(_)-OOo------------------------------
<HR>

It is a known bug in OWL2.5. You need to patch your compiler. The patches are
in ftp.borland.com. The patch files are bc45p?.zip. Good luck.
-- 
Hui Huang               I ain't afraid of no ghost.
[e-mail]  http://home.cc.umanitoba.ca/~umhuang4/
</PRE>

<HR><A NAME=TOOL_BORLANDC_DEBUGGER>
Return to <a href="wpw_tool_index.html#TOC">Table of Contents for this chapter</a><br>
<H4>Subject: Borland IDE debugger problems</H4><PRE>
In article <[e-mail]>,
[e-mail] (Steve Loughran) wrote:

> Yes, the latest Borland compilers do have an integrated debugger, so
> that you can debug 16 bit programs from within the IDE.
> However, it does have some weaknesses:
>         -doesn't display local variables 

Something seems to be screwy with this.  If I click the right button
on a local var to popup a menu and then select 'Inspect Object'; some-
times it works sometimes it doesn't.  When it doesn't I have to go
up to the 'Debug' menu option and select 'Inspect ...'.  Rather
bothersome at 5 am :-(

> So: dont upgrade if all you want is a better debugger: TDW is still
> more powerful than the IDE based one. 

I find I use the IDE debugger most often.  It helps me track down
my 'obvious' [hah!] logic errors.  But when the big bad bugs show
up I use TDW and/or Bounds Checker.  Potato chips help as well :-)

> Do upgrade if you want
>         -to use the OWL class libraries

Especially if you are upgrading from 3.1 and are willing to study
OWL programming.
_______________________________________________________       /--i--\   . 
|                |                                           ''''||\___/| 
| Dwayne Lee     | Long was the day             Illustration     ||o - o| 
| [e-mail] |   Spent measuring           by Martin Opitz   | /---\ \ 
|                | The weight of the clam shells.                E/^ ^ ^\W 
`------------------------------------------------------           \m___m/ 
<HR>
Daniel Hyams (dhyams) wrote:
> >>I've been using Borland C++ version 3.1, and am tired of switching to a DOS 
> >>app to debug.  Does the latest version of Borland's compiler (4.5?) allow you 
> >>to debug inside the IDE (like the DOS version of BC3.1). If not, is the 
> >>debugger at least a Windows app?
> >
> >Yes, the latest Borland compilers do have an integrated debugger, so
> >that you can debug 16 bit programs from within the IDE.
> >However, it does have some weaknesses:
> >        -doesn't display local variables 
> >         [maybe borland engineers don't use 'em]

> What???  I use Borland C++ 4.0, and I have never seen this behavior.  Any
> variable that I want to set a watch for, or use the inspector window for,
> I can see.  You might want to make sure that you have the correct symbol
> table loaded!

Yes, you can manually point to a variable and click "inspect" on it.
What I meant -and failed to express properly- is that there is no
"Locals" window, the way pretty much every other debugger has.
Frankly, I find it inconvenient to have to inspect/watch all the
variables since the debugger should be able to list them all for me.
I end up doing naughty things in my code like using single letter
variables and then putting all variables a..z in the watch window...

> Since I don't know about BCC3.1, I don't know about this suggestion.
> But, I do know that the integrated debugger has been invaluable to
> me.

What it is good for is setting abreakpoints as you write functions, so
that it's easy to have a rule of "Add a breakpoint to every function
and branch which you code". Then when you run you can step through
every bit of code as it gets executed, to check that it all works and
clear the breakpoint.

You can also see which branches of code havent been executed simply by
listing all breakpoints. Unless you set breakpoints as a way of adding
bookmarks to code in BC4.x but that's another bad habit... 

        -Steve

--
Steve Loughran 
Hewlett-Packard Laboratories, Bristol
mailto:[e-mail]
tel:[phone]
<HR>
In article <[e-mail]>,
[e-mail] (Steve Loughran) wrote:

> Frankly, I find it inconvenient to have to inspect/watch all the
> variables since the debugger should be able to list them all for me.
> I end up doing naughty things in my code like using single letter
> variables and then putting all variables a..z in the watch window...

This isn't just naughty ... it's INSANE!  Not meaning to preach, but
the consequences are gonna get you sooner or later ... probably at
4 am in the morning chasing that 'one' last bug :-)

I admit, it would be convenient to have a command to slap up all the
local vars in a watch window though.  While Borland is at this two
features I really miss are:

        1) I wish they would implement 'Until Return' in the IDE
           debugger.  They have it in the TDWin version.  Invariably
           I misclick the 'Trace Into' function once too often.  Then
           I have to search for and put my cursor on the end of the 
           function, 'Run to Cursor' and step out.  What a bother.

        2) lack of a command to be able to call functions from the
           debugger.  Currently I have a lot of code like the following:

                int DBG_DUMP_POLY = 0;
                ...
                if ( DBG_DUMP_POLY ) {  /* HACK */
                  init_dump_poly( "/tmp/dmp.pol" );
                  dump_poly_pnts( poly_p );
                  fini_dump_poly();
                }

           I set a break point at the HACK statement, set DBG_DUMP_POLY
           to non-zero, and continue.
           If I had the ability to call functions from the debugger, I
           could just put a break point at HACK and then type in the 
           functions that I want to call.  Saves me from having to 
           pollute my code with a lot of oftentimes unnecessary 
           debugging statements.

           This one debugging feature has saved me hours on my Unix
           workstation.
_______________________________________________________       /--i--\   . 
|                |                                           ''''||\___/| 
| Dwayne Lee     | Long was the day             Illustration     ||o - o| 
| [e-mail] |   Spent measuring           by Martin Opitz   | /---\ \ 
|                | The weight of the clam shells.                E/^ ^ ^\W 
`------------------------------------------------------           \m___m/ 
</PRE>

<HR><A NAME=TOOL_BORLAND_OWL_RES_BUTTON>
Return to <a href="wpw_tool_index.html#TOC">Table of Contents for this chapter</a><br>
<H4>Subject: Enable Buttons created by Resource Workshop</H4><PRE>
Angus-H.W. Chan ([e-mail]) wrote:
:       I am using OWL of Borland C++ 4.5 for Windows/DOS to develop my
:  Windows application. In it, I have utilized the Resource Workshop to
:  create a Dialog box which contains some buttons and static texts. For
:  some of the buttons, I have to disable them initially and enable them
:  after some events have happened. However, I can't find a way to enable
:  them afterwards, I am just able to discover some messages like
:  BN_DISABLE but not BN_ENABLE or anything else. As far as I know, the
:  buttons are the objects of class TButton, aren't they? But I can't find
:  any member functions of TButton to enable the button in run time.
   
   Create your class of this dialogbox and define there your buttons: 
        MyBut = new TButton(...)
   then you can call MyBut->Show(SW_HIDE); (or SW_SHOW)
        
:       Moreover, I would like to know if it is possible to change the
:  static texts of a dialog box after it is displayed.

        MySt = new TStatic(..)
        MySt->SetText("jama");


Riho
</PRE> 

</HTML>