#if defined(...) #else #endif in ObjectPAL ?

#if defined(...) #else #endif in ObjectPAL ?

Post by Volker Kuhnl » Wed, 14 Feb 2001 00:58:50



Hi group,

I wonder if there is a posibility to code with compiler options like C/C++.
I am using Paradox 9

e.g. :

#define _test_
[...]
#if defined ( _test )
some ObjectPal code to do only in test mode
#else
ObjectPal code
#endif
ObjectPal code
[...]

any ideas / sugestions highly apreciated.

regards,
Volker

 
 
 

#if defined(...) #else #endif in ObjectPAL ?

Post by Dennis Santor » Wed, 14 Feb 2001 01:54:27


Well you can turn breakpoints on and run it through the de* stepping
through or over whatever you want. You could also set some sort of a logical
flag variable and test for it.

Denn Santoro
President
Resource Development Associates
http://www.veryComputer.com/
375 High Street
Rochester, MA 02770
(508) 295-7350
and
Waldweg 5
83512 Reitmehring
Germany
08071 924271
Providing solutions to health care, business, governments and non-profits since
1982


> Hi group,

> I wonder if there is a posibility to code with compiler options like C/C++.
> I am using Paradox 9

> e.g. :

> #define _test_
> [...]
> #if defined ( _test )
> some ObjectPal code to do only in test mode
> #else
> ObjectPal code
> #endif
> ObjectPal code
> [...]

> any ideas / sugestions highly apreciated.

> regards,
> Volker


 
 
 

#if defined(...) #else #endif in ObjectPAL ?

Post by Liz » Wed, 14 Feb 2001 02:31:42


Volker,

I know a developer who often throws in code for test purposes
only inside an if statement like...

if 1=1 then
  ...
endIf

...and when he's done testing, he changes it to...

if 1 <> 1 then
  ...
endIf

...that way the code stays put, but has no impact...  I think a
better way would be to have a constant at the form level which
you could change:

if myConst = "Testing" then
  ...
endIf

...then you just change the constant in one place for the session
and re-set it when you're done testing...  (rather than searching
for multiple occurrences of 1=1).  I've also seen such code based
on the contents of a text file on the HDD or on the computer name
or login name (so the code only runs on the developer's
computer).

Liz


> Hi group,

> I wonder if there is a posibility to code with compiler options like C/C++.
> I am using Paradox 9

> e.g. :

> #define _test_
> [...]
> #if defined ( _test )
> some ObjectPal code to do only in test mode
> #else
> ObjectPal code
> #endif
> ObjectPal code
> [...]

> any ideas / sugestions highly apreciated.

> regards,
> Volker

 
 
 

#if defined(...) #else #endif in ObjectPAL ?

Post by Joseph Misk » Wed, 14 Feb 2001 05:32:13


ObjectPAL is an interpreted language, so there are no compiler options
comparable to C.  I have never used the following technique in ObjectPAL,
since it has a de*, but I used to use it on mainframes, when there were
no de*s.  It works exceptionally well.  At a global level, declare an
integer constant and a procedure (shown below).  These would often be best
implemented in a library, unless your application is small.  Then,
throughout your code you can trigger different levels of debug activity,
depending on the constant value.  Like compiler options, once the debug code
you want is in place, you set the switch in one place (the const
declaration), but this method is more flexible.  Set the constant to a
higher value to get more information.  For doing conditional code, you could
use the debug constant to trigger the correct section or procedure call.

; declare this in your form or library
const
    ; global debug constant
    ; could be longint also (change procedure below to match)
    ; zero turns debugging off
    ; otherwise higher numbers give more information
    kiDebug = SmallInt(25)
endconst

proc showDebug(const iDebugLevel SmallInt, const sDebugMsg String)
    ; if kiDebug is set to zero, debugging is disabled
    if kiDebug > 0 then
        ; check if debug constant covers requested level of info
        if iDebugLevel <= kiDebug then
            msgInfo("DEBUG", sDebugMsg)
        endif
    endif
endproc

; This is an example for using showDebug
proc testDebug()
    showDebug(1, "Entered proc testDebug") ; always show enter if debugging
on
    { some code here }
    showDebug(150, "Only show me if debugging level is >= 150")
    { some code here }
    showDebug(5, "Show me a lot, whenever debugging level is >= 5")
    { some code here }
    showDebug(10, "Exiting proc testDebug")
endproc

 
 
 

1. FPD 2.6 #DEFINE inside an #IF...#ENDIF block

I'm trying to write something like:

#IF ( "VISUAL" $ UPPER(VERSION()) )
  #DEFINE MEMO_SIZE 4
  * and other #defines
#ELSE
  #DEFINE MEMO_SIZE 10
  * and other #defines
#ENDIF

But this code generates a "mismatched #if/#elif/#else/#endif." error
when I try to compile it in FPD 2.6, with or without the #ELSE clause.

Does anyone know whether this should be happening, and if so, how
to work around it to do #DEFINEs conditionally?

                     Mind you, moose bites can be pretty nasty...

2. WindowsCE/PalmOS Databases

3. Setting order in Param in If..endif

4. Using T-SQL to remove HTML from a field

5. Help With If..else..endif

6. VFP6 : Menus outside form

7. help with adding more in IF...ENDIF

8. Stack Trace

9. Leaving If..endif's too soon

10. Two Questions/Report Var Prnting/#IF & #ENDIF

11. IF-ELSE-ENDIF vs IIF()

12. DB4 endif problems

13. &IF and &ENDIF for V6