Im trying to use a Confirmbox() with XBP_YESNO but the buttons I get are 
Retry and Cancel.  XBP_YESNOCANCEL results in Yes, No and Cancel 
pushbuttons.  Evidently there's something wrong with the Win32 constant 
definitions in Xbp.ch or in the Xbase++ implementation of the WinAPI for 
this function.

Joe Carrick wrote:
> Im trying to use a Confirmbox() with XBP_YESNO but the buttons I get are
> Retry and Cancel.  XBP_YESNOCANCEL results in Yes, No and Cancel
> pushbuttons.  Evidently there's something wrong with the Win32 constant
> definitions in Xbp.ch or in the Xbase++ implementation of the WinAPI for
> this function.
> 
> 
Thats odd I use that all the time without problem. Check you headers see
 if you have conflicting definitions.

Jim

Hi James,

This is from my Xbp.ch file.  It's the only place where XBPMB_YESNO is 
defined.

#ifdef __WIN32__

 Configuration of pushbuttons
#define XBPMB_OK                           0
#define XBPMB_OKCANCEL                     1
#define XBPMB_RETRYCANCEL                  5
#define XBPMB_ABORTRETRYIGNORE             2
#define XBPMB_YESNO                        4
#define XBPMB_YESNOCANCEL                  3
#define XBPMB_CANCEL                       0
#define XBPMB_ENTER                        0
#define XBPMB_ENTERCANCEL                  1
#define XBPMB_HELP                         16384

 Defines for the style
#define XBPMB_NOICON                       0
#define XBPMB_QUESTION                     32
#define XBPMB_WARNING                      48
#define XBPMB_INFORMATION                  64
#define XBPMB_CRITICAL                     16

#define XBPMB_APPMODAL                     (0 + 65536)
#define XBPMB_SYSMODAL                     (4096 + 65536)
#define XBPMB_MOVEABLE                     65536

 Defbutton
#define XBPMB_DEFBUTTON1                   0
#define XBPMB_DEFBUTTON2                   256
#define XBPMB_DEFBUTTON3                   512

 Confirm box return codes
#define XBPMB_RET_OK                       1
#define XBPMB_RET_CANCEL                   2
#define XBPMB_RET_ABORT                    3
#define XBPMB_RET_RETRY                    4
#define XBPMB_RET_IGNORE                   5
#define XBPMB_RET_YES                      6
#define XBPMB_RET_NO                       7
#define XBPMB_RET_ENTER                    9
#define XBPMB_RET_ERROR                    65535

#endif

I really don't understand how it could be wrong, but if your defines are 
not the same, let me know.

Thanks, Joe
James Loughner wrote:
> Joe Carrick wrote:
> 
>>Im trying to use a Confirmbox() with XBP_YESNO but the buttons I get are
>>Retry and Cancel.  XBP_YESNOCANCEL results in Yes, No and Cancel
>>pushbuttons.  Evidently there's something wrong with the Win32 constant
>>definitions in Xbp.ch or in the Xbase++ implementation of the WinAPI for
>>this function.
>>
>>
> 
> Thats odd I use that all the time without problem. Check you headers see
>  if you have conflicting definitions.
> 
> Jim

Odd this is mine

 Configuration of pushbuttons
#define XBPMB_OK                           0
#define XBPMB_OKCANCEL                     1
#define XBPMB_RETRYCANCEL                  2
#define XBPMB_ABORTRETRYIGNORE             3
#define XBPMB_YESNO                        4
#define XBPMB_YESNOCANCEL                  5
#define XBPMB_CANCEL                       6
#define XBPMB_ENTER                        7
#define XBPMB_ENTERCANCEL                  8



Joe Carrick wrote:
> Hi James,
> 
> This is from my Xbp.ch file.  It's the only place where XBPMB_YESNO is
> defined.
> 
> #ifdef __WIN32__
> 
>  Configuration of pushbuttons
> #define XBPMB_OK                           0
> #define XBPMB_OKCANCEL                     1
> #define XBPMB_RETRYCANCEL                  5
> #define XBPMB_ABORTRETRYIGNORE             2
> #define XBPMB_YESNO                        4
> #define XBPMB_YESNOCANCEL                  3
> #define XBPMB_CANCEL                       0
> #define XBPMB_ENTER                        0
> #define XBPMB_ENTERCANCEL                  1
> #define XBPMB_HELP                         16384
> 
>  Defines for the style
> #define XBPMB_NOICON                       0
> #define XBPMB_QUESTION                     32
> #define XBPMB_WARNING                      48
> #define XBPMB_INFORMATION                  64
> #define XBPMB_CRITICAL                     16
> 
> #define XBPMB_APPMODAL                     (0 + 65536)
> #define XBPMB_SYSMODAL                     (4096 + 65536)
> #define XBPMB_MOVEABLE                     65536
> 
>  Defbutton
> #define XBPMB_DEFBUTTON1                   0
> #define XBPMB_DEFBUTTON2                   256
> #define XBPMB_DEFBUTTON3                   512
> 
>  Confirm box return codes
> #define XBPMB_RET_OK                       1
> #define XBPMB_RET_CANCEL                   2
> #define XBPMB_RET_ABORT                    3
> #define XBPMB_RET_RETRY                    4
> #define XBPMB_RET_IGNORE                   5
> #define XBPMB_RET_YES                      6
> #define XBPMB_RET_NO                       7
> #define XBPMB_RET_ENTER                    9
> #define XBPMB_RET_ERROR                    65535
> 
> #endif
> 
> I really don't understand how it could be wrong, but if your defines are
> not the same, let me know.
> 
> Thanks, Joe
> James Loughner wrote:
>> Joe Carrick wrote:
>>
>>> Im trying to use a Confirmbox() with XBP_YESNO but the buttons I get are
>>> Retry and Cancel.  XBP_YESNOCANCEL results in Yes, No and Cancel
>>> pushbuttons.  Evidently there's something wrong with the Win32 constant
>>> definitions in Xbp.ch or in the Xbase++ implementation of the WinAPI for
>>> this function.
>>>
>>> 
>>
>> Thats odd I use that all the time without problem. Check you headers see
>>  if you have conflicting definitions.
>>
>> Jim

Hello James,

> Odd this is mine
> 
>  Configuration of pushbuttons
> #define XBPMB_OK                           0
> #define XBPMB_OKCANCEL                     1
> #define XBPMB_RETRYCANCEL                  2
> #define XBPMB_ABORTRETRYIGNORE             3
> #define XBPMB_YESNO                        4
> #define XBPMB_YESNOCANCEL                  5
> #define XBPMB_CANCEL                       6
> #define XBPMB_ENTER                        7
> #define XBPMB_ENTERCANCEL                  8

Are those in the #ifdef __OS2__ section?  My __OS2__ section appears as above, 
but the __WIN32__ section appears as Joes.

Regards,

Rodd Graham, Consultant
Graham Automation Systems, LLC

Hi Guys,

I changed my Win32 section to be the same as the OS2 section and now 
XBPMB_YESNO works properly.  Very Strange, but I'm not going to argue at 
this point.  I just commented out the old Win32 definitions and added 
the new ones, so if I ever need to go back I can.

-Joe

Rodd Graham wrote:
> Hello James,
> 
>> Odd this is mine
>>
>>  Configuration of pushbuttons
>> #define XBPMB_OK                           0
>> #define XBPMB_OKCANCEL                     1
>> #define XBPMB_RETRYCANCEL                  2
>> #define XBPMB_ABORTRETRYIGNORE             3
>> #define XBPMB_YESNO                        4
>> #define XBPMB_YESNOCANCEL                  5
>> #define XBPMB_CANCEL                       6
>> #define XBPMB_ENTER                        7
>> #define XBPMB_ENTERCANCEL                  8
> 
> Are those in the #ifdef __OS2__ section?  My __OS2__ section appears as 
> above, but the __WIN32__ section appears as Joes.
> 
> Regards,
> 
> Rodd Graham, Consultant
> Graham Automation Systems, LLC
> 
>

Well, here's what I had to do to make everything work properly in the 
Win32 section:

#ifdef __WIN32__

 Configuration of pushbuttons
#define XBPMB_OK                           0
#define XBPMB_OKCANCEL                     1
#define XBPMB_ABORTRETRYIGNORE             2
#define XBPMB_YESNOCANCEL                  3
#define XBPMB_YESNO                        4
#define XBPMB_RETRYCANCEL                  5
#define XBPMB_CANCEL                       0
#define XBPMB_ENTER                        0
#define XBPMB_ENTERCANCEL                  1
#define XBPMB_HELP                         16384

The key seems to be that these values are in ascending order, not 
random.  I have not tested the last 4 defines, but the first 6 work.

-Joe

Joe Carrick wrote:
> Hi Guys,
> 
> I changed my Win32 section to be the same as the OS2 section and now 
> XBPMB_YESNO works properly.  Very Strange, but I'm not going to argue at 
> this point.  I just commented out the old Win32 definitions and added 
> the new ones, so if I ever need to go back I can.
> 
> -Joe
> 
> Rodd Graham wrote:
>> Hello James,
>>
>>> Odd this is mine
>>>
>>>  Configuration of pushbuttons
>>> #define XBPMB_OK                           0
>>> #define XBPMB_OKCANCEL                     1
>>> #define XBPMB_RETRYCANCEL                  2
>>> #define XBPMB_ABORTRETRYIGNORE             3
>>> #define XBPMB_YESNO                        4
>>> #define XBPMB_YESNOCANCEL                  5
>>> #define XBPMB_CANCEL                       6
>>> #define XBPMB_ENTER                        7
>>> #define XBPMB_ENTERCANCEL                  8
>>
>> Are those in the #ifdef __OS2__ section?  My __OS2__ section appears 
>> as above, but the __WIN32__ section appears as Joes.
>>
>> Regards,
>>
>> Rodd Graham, Consultant
>> Graham Automation Systems, LLC
>>
>>

OK, here's the final detail on the defines for Win32.

#ifdef __WIN32__

 Configuration of pushbuttons
#define XBPMB_OK                0
#define XBPMB_OKCANCEL          1
#define XBPMB_ABORTRETRYIGNORE  2
#define XBPMB_YESNOCANCEL       3
#define XBPMB_YESNO             4
#define XBPMB_RETRYCANCEL       5
#define XBPMB_CANCEL            6    Cancel TryAgain Continue
#define XBPMB_HELP              16384

These are apparently the only possibilities in Win32 for the 
Confirmbox().  I have tested all of these except the last one.  When I 
tried anything above XBPMB_CANCEL the Confirmbox was simply not 
displayed at all.

Alaska should correct this in the next release so that we don't get a 
revised version of Xbp.ch that over-writes this change.

-Joe


Joe Carrick wrote:
> Im trying to use a Confirmbox() with XBP_YESNO but the buttons I get are 
> Retry and Cancel.  XBP_YESNOCANCEL results in Yes, No and Cancel 
> pushbuttons.  Evidently there's something wrong with the Win32 constant 
> definitions in Xbp.ch or in the Xbase++ implementation of the WinAPI for 
> this function.
> 
> 

Joe,

looks like XBPMB_* is directly taken from MB_* defines listed in winuser.h.

The #defines can be ORed in C, or ADDed in Xbase++

Try XBPMB_YESNO+XBPMB_HELP as button configuration

My 2cnts
--
Hannes

PS: Maybe a winuser32.h review helps as well

/*
 * MessageBox() Flags
 */
#define MB_OK                       0x00000000L
#define MB_OKCANCEL                 0x00000001L
#define MB_ABORTRETRYIGNORE         0x00000002L
#define MB_YESNOCANCEL              0x00000003L
#define MB_YESNO                    0x00000004L
#define MB_RETRYCANCEL              0x00000005L
#if(WINVER >= 0x0500)
#define MB_CANCELTRYCONTINUE        0x00000006L
#endif /* WINVER >= 0x0500 */


#define MB_ICONHAND                 0x00000010L
#define MB_ICONQUESTION             0x00000020L
#define MB_ICONEXCLAMATION          0x00000030L
#define MB_ICONASTERISK             0x00000040L

#if(WINVER >= 0x0400)
#define MB_USERICON                 0x00000080L
#define MB_ICONWARNING              MB_ICONEXCLAMATION
#define MB_ICONERROR                MB_ICONHAND
#endif /* WINVER >= 0x0400 */

#define MB_ICONINFORMATION          MB_ICONASTERISK
#define MB_ICONSTOP                 MB_ICONHAND

#define MB_DEFBUTTON1               0x00000000L
#define MB_DEFBUTTON2               0x00000100L
#define MB_DEFBUTTON3               0x00000200L
#if(WINVER >= 0x0400)
#define MB_DEFBUTTON4               0x00000300L
#endif /* WINVER >= 0x0400 */

#define MB_APPLMODAL                0x00000000L
#define MB_SYSTEMMODAL              0x00001000L
#define MB_TASKMODAL                0x00002000L
#if(WINVER >= 0x0400)
#define MB_HELP                     0x00004000L  Help Button
#endif /* WINVER >= 0x0400 */

#define MB_NOFOCUS                  0x00008000L
#define MB_SETFOREGROUND            0x00010000L
#define MB_DEFAULT_DESKTOP_ONLY     0x00020000L

#if(WINVER >= 0x0400)
#define MB_TOPMOST                  0x00040000L
#define MB_RIGHT                    0x00080000L
#define MB_RTLREADING               0x00100000L


#endif /* WINVER >= 0x0400 */


"Joe Carrick" <joe.carrick@dslextreme.com> schrieb im Newsbeitrag 
news:38ab45d2$56837db1$11d6b8@news.alaska-software.com...
> OK, here's the final detail on the defines for Win32.
>
> #ifdef __WIN32__
>
>  Configuration of pushbuttons
> #define XBPMB_OK                0
> #define XBPMB_OKCANCEL          1
> #define XBPMB_ABORTRETRYIGNORE  2
> #define XBPMB_YESNOCANCEL       3
> #define XBPMB_YESNO             4
> #define XBPMB_RETRYCANCEL       5
> #define XBPMB_CANCEL            6    Cancel TryAgain Continue
> #define XBPMB_HELP              16384
>
> These are apparently the only possibilities in Win32 for the Confirmbox(). 
> I have tested all of these except the last one.  When I tried anything 
> above XBPMB_CANCEL the Confirmbox was simply not displayed at all.
>
> Alaska should correct this in the next release so that we don't get a 
> revised version of Xbp.ch that over-writes this change.
>
> -Joe
>
>
> Joe Carrick wrote:
>> Im trying to use a Confirmbox() with XBP_YESNO but the buttons I get are 
>> Retry and Cancel.  XBP_YESNOCANCEL results in Yes, No and Cancel 
>> pushbuttons.  Evidently there's something wrong with the Win32 constant 
>> definitions in Xbp.ch or in the Xbase++ implementation of the WinAPI for 
>> this function.
>>
>> 

Hi Hannes,

I understand....  My point is that the existing "Xbp.ch" is incorrect. 
It is not consistent with "inuser.h for the Win32 defines.

Check it out yourself.

-Joe

Hannes Ziegler wrote:
> Joe,
> 
> looks like XBPMB_* is directly taken from MB_* defines listed in winuser.h.
> 
> The #defines can be ORed in C, or ADDed in Xbase++
> 
> Try XBPMB_YESNO+XBPMB_HELP as button configuration
> 
> My 2cnts
> --
> Hannes
> 
> PS: Maybe a winuser32.h review helps as well
> 
> /*
>  * MessageBox() Flags
>  */
> #define MB_OK                       0x00000000L
> #define MB_OKCANCEL                 0x00000001L
> #define MB_ABORTRETRYIGNORE         0x00000002L
> #define MB_YESNOCANCEL              0x00000003L
> #define MB_YESNO                    0x00000004L
> #define MB_RETRYCANCEL              0x00000005L
> #if(WINVER >= 0x0500)
> #define MB_CANCELTRYCONTINUE        0x00000006L
> #endif /* WINVER >= 0x0500 */
> 
> 
> #define MB_ICONHAND                 0x00000010L
> #define MB_ICONQUESTION             0x00000020L
> #define MB_ICONEXCLAMATION          0x00000030L
> #define MB_ICONASTERISK             0x00000040L
> 
> #if(WINVER >= 0x0400)
> #define MB_USERICON                 0x00000080L
> #define MB_ICONWARNING              MB_ICONEXCLAMATION
> #define MB_ICONERROR                MB_ICONHAND
> #endif /* WINVER >= 0x0400 */
> 
> #define MB_ICONINFORMATION          MB_ICONASTERISK
> #define MB_ICONSTOP                 MB_ICONHAND
> 
> #define MB_DEFBUTTON1               0x00000000L
> #define MB_DEFBUTTON2               0x00000100L
> #define MB_DEFBUTTON3               0x00000200L
> #if(WINVER >= 0x0400)
> #define MB_DEFBUTTON4               0x00000300L
> #endif /* WINVER >= 0x0400 */
> 
> #define MB_APPLMODAL                0x00000000L
> #define MB_SYSTEMMODAL              0x00001000L
> #define MB_TASKMODAL                0x00002000L
> #if(WINVER >= 0x0400)
> #define MB_HELP                     0x00004000L  Help Button
> #endif /* WINVER >= 0x0400 */
> 
> #define MB_NOFOCUS                  0x00008000L
> #define MB_SETFOREGROUND            0x00010000L
> #define MB_DEFAULT_DESKTOP_ONLY     0x00020000L
> 
> #if(WINVER >= 0x0400)
> #define MB_TOPMOST                  0x00040000L
> #define MB_RIGHT                    0x00080000L
> #define MB_RTLREADING               0x00100000L
> 
> 
> #endif /* WINVER >= 0x0400 */
> 
> 
> "Joe Carrick" <joe.carrick@dslextreme.com> schrieb im Newsbeitrag 
> news:38ab45d2$56837db1$11d6b8@news.alaska-software.com...
> 
>>OK, here's the final detail on the defines for Win32.
>>
>>#ifdef __WIN32__
>>
>>// Configuration of pushbuttons
>>#define XBPMB_OK                0
>>#define XBPMB_OKCANCEL          1
>>#define XBPMB_ABORTRETRYIGNORE  2
>>#define XBPMB_YESNOCANCEL       3
>>#define XBPMB_YESNO             4
>>#define XBPMB_RETRYCANCEL       5
>>#define XBPMB_CANCEL            6    Cancel TryAgain Continue
>>#define XBPMB_HELP              16384
>>
>>These are apparently the only possibilities in Win32 for the Confirmbox(). 
>>I have tested all of these except the last one.  When I tried anything 
>>above XBPMB_CANCEL the Confirmbox was simply not displayed at all.
>>
>>Alaska should correct this in the next release so that we don't get a 
>>revised version of Xbp.ch that over-writes this change.
>>
>>-Joe
>>
>>
>>Joe Carrick wrote:
>>
>>>Im trying to use a Confirmbox() with XBP_YESNO but the buttons I get are 
>>>Retry and Cancel.  XBP_YESNOCANCEL results in Yes, No and Cancel 
>>>pushbuttons.  Evidently there's something wrong with the Win32 constant 
>>>definitions in Xbp.ch or in the Xbase++ implementation of the WinAPI for 
>>>this function.
>>>
>>> 
> 
> 
>

Hi Joe,

> I understand....  My point is that the existing "Xbp.ch" is incorrect. It 
> is not consistent with "inuser.h for the Win32 defines.
>
> Check it out yourself.

For some reason I have abandoned to compare Alaska stuff with Windows SDK 
stuff.

Windows SDK stuff has higher priority and the SDK helps closing PDRs locally 
on my side.

Alaska's PDR handling takes too long time for me. I simply have stopped to 
care much about what they do.

My 2 cents
--
Hannes


> Hannes Ziegler wrote:
>> Joe,
>>
>> looks like XBPMB_* is directly taken from MB_* defines listed in 
>> winuser.h.
>>
>> The #defines can be ORed in C, or ADDed in Xbase++
>>
>> Try XBPMB_YESNO+XBPMB_HELP as button configuration
>>
>> My 2cnts
>> --
>> Hannes
>>
>> PS: Maybe a winuser32.h review helps as well
>>
>> /*
>>  * MessageBox() Flags
>>  */
>> #define MB_OK                       0x00000000L
>> #define MB_OKCANCEL                 0x00000001L
>> #define MB_ABORTRETRYIGNORE         0x00000002L
>> #define MB_YESNOCANCEL              0x00000003L
>> #define MB_YESNO                    0x00000004L
>> #define MB_RETRYCANCEL              0x00000005L
>> #if(WINVER >= 0x0500)
>> #define MB_CANCELTRYCONTINUE        0x00000006L
>> #endif /* WINVER >= 0x0500 */
>>
>>
>> #define MB_ICONHAND                 0x00000010L
>> #define MB_ICONQUESTION             0x00000020L
>> #define MB_ICONEXCLAMATION          0x00000030L
>> #define MB_ICONASTERISK             0x00000040L
>>
>> #if(WINVER >= 0x0400)
>> #define MB_USERICON                 0x00000080L
>> #define MB_ICONWARNING              MB_ICONEXCLAMATION
>> #define MB_ICONERROR                MB_ICONHAND
>> #endif /* WINVER >= 0x0400 */
>>
>> #define MB_ICONINFORMATION          MB_ICONASTERISK
>> #define MB_ICONSTOP                 MB_ICONHAND
>>
>> #define MB_DEFBUTTON1               0x00000000L
>> #define MB_DEFBUTTON2               0x00000100L
>> #define MB_DEFBUTTON3               0x00000200L
>> #if(WINVER >= 0x0400)
>> #define MB_DEFBUTTON4               0x00000300L
>> #endif /* WINVER >= 0x0400 */
>>
>> #define MB_APPLMODAL                0x00000000L
>> #define MB_SYSTEMMODAL              0x00001000L
>> #define MB_TASKMODAL                0x00002000L
>> #if(WINVER >= 0x0400)
>> #define MB_HELP                     0x00004000L  Help Button
>> #endif /* WINVER >= 0x0400 */
>>
>> #define MB_NOFOCUS                  0x00008000L
>> #define MB_SETFOREGROUND            0x00010000L
>> #define MB_DEFAULT_DESKTOP_ONLY     0x00020000L
>>
>> #if(WINVER >= 0x0400)
>> #define MB_TOPMOST                  0x00040000L
>> #define MB_RIGHT                    0x00080000L
>> #define MB_RTLREADING               0x00100000L
>>
>>
>> #endif /* WINVER >= 0x0400 */
>>
>>
>> "Joe Carrick" <joe.carrick@dslextreme.com> schrieb im Newsbeitrag 
>> news:38ab45d2$56837db1$11d6b8@news.alaska-software.com...
>>
>>>OK, here's the final detail on the defines for Win32.
>>>
>>>#ifdef __WIN32__
>>>
>>>// Configuration of pushbuttons
>>>#define XBPMB_OK                0
>>>#define XBPMB_OKCANCEL          1
>>>#define XBPMB_ABORTRETRYIGNORE  2
>>>#define XBPMB_YESNOCANCEL       3
>>>#define XBPMB_YESNO             4
>>>#define XBPMB_RETRYCANCEL       5
>>>#define XBPMB_CANCEL            6    Cancel TryAgain Continue
>>>#define XBPMB_HELP              16384
>>>
>>>These are apparently the only possibilities in Win32 for the 
>>>Confirmbox(). I have tested all of these except the last one.  When I 
>>>tried anything above XBPMB_CANCEL the Confirmbox was simply not displayed 
>>>at all.
>>>
>>>Alaska should correct this in the next release so that we don't get a 
>>>revised version of Xbp.ch that over-writes this change.
>>>
>>>-Joe
>>>
>>>
>>>Joe Carrick wrote:
>>>
>>>>Im trying to use a Confirmbox() with XBP_YESNO but the buttons I get are 
>>>>Retry and Cancel.  XBP_YESNOCANCEL results in Yes, No and Cancel 
>>>>pushbuttons.  Evidently there's something wrong with the Win32 constant 
>>>>definitions in Xbp.ch or in the Xbase++ implementation of the WinAPI for 
>>>>this function.
>>>>
>>>>
>>
>>

Joe,

>OK, here's the final detail on the defines for Win32.

I'm not sure what this thread is all about, as your final detail list more 
or less simply sorts the existing define constants in numerical order, and 
removes the two unsupported XBPMB_ENTER and XBPMB_ENTERCANCEL constants 
(which were mapped to the similar XBPMB_OK and XBPMB_OKCANCEL by Alaska) 
and also adds a value for XBPMB_CANCEL (which should actually be a new 
constant named XBPMB_CANCELTRYAGAINCONTINUE, instead).

Your original problem was that:
>>Im trying to use a Confirmbox() with XBP_YESNO but the buttons I get are 
>>Retry and Cancel. XBP_YESNOCANCEL results in Yes, No and Cancel 
>>pushbuttons. Evidently there's something wrong with the Win32 constant 
>>definitions in Xbp.ch or in the Xbase++ implementation of the WinAPI for 
>>this function.

But you didn't change the values of either XBP_YESNO or XBP_YESNOCANCEL!
So, what happened to your original problem? Your define constants have 
obviously not been changed, but how was it fixed? Just curious. 

-- Andreas

---                                                                      ---
  Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
  415 Gute Street                     or: Andreas@DDPSoftware.com
  Owosso, MI 48867-4410               or: Andreas@Aerospace-History.net
  Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
---                                                                      ---

Sorting the values was the key to fixing the original problem.  At least 
that's what happened on my systems.

-Joe

Andreas Gehrs-Pahl wrote:
> Joe,
> 
> 
>>OK, here's the final detail on the defines for Win32.
> 
> 
> I'm not sure what this thread is all about, as your final detail list more 
> or less simply sorts the existing define constants in numerical order, and 
> removes the two unsupported XBPMB_ENTER and XBPMB_ENTERCANCEL constants 
> (which were mapped to the similar XBPMB_OK and XBPMB_OKCANCEL by Alaska) 
> and also adds a value for XBPMB_CANCEL (which should actually be a new 
> constant named XBPMB_CANCELTRYAGAINCONTINUE, instead).
> 
> Your original problem was that:
> 
>>>Im trying to use a Confirmbox() with XBP_YESNO but the buttons I get are 
>>>Retry and Cancel. XBP_YESNOCANCEL results in Yes, No and Cancel 
>>>pushbuttons. Evidently there's something wrong with the Win32 constant 
>>>definitions in Xbp.ch or in the Xbase++ implementation of the WinAPI for 
>>>this function.
> 
> 
> But you didn't change the values of either XBP_YESNO or XBP_YESNOCANCEL!
> So, what happened to your original problem? Your define constants have 
> obviously not been changed, but how was it fixed? Just curious. 
> 
> -- Andreas
> 
> ---                                                                      ---
>   Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
>   415 Gute Street                     or: Andreas@DDPSoftware.com
>   Owosso, MI 48867-4410               or: Andreas@Aerospace-History.net
>   Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
> ---                                                                      ---

Joe,

>Sorting the values was the key to fixing the original problem. At least 
>that's what happened on my systems.

If I understand you correctly, then you are telling me that simply changing 
the order of the define statements in the header file fixed the problem? 
This sounds very strange to me! As those are all distinct define constants, 
and no re-define takes place, I wonder how changing the order could have any 
effect whatsoever on the pre-processor! That is of course unless you blame 
it on non-deterministic quantum effects -- but then you shouldn't be able to 
reproduce the behavior. 

BTW, I did a quick test, and it worked fine for me with the unmodified 
"Xbp.ch" file in all Xbase Versions (1.20.178 through 1.90.331) on all 
Operating Systems that I had on hand. The new "XBPMB_CANCELTRYAGAINCONTINUE" 
option ("6") doesn't work on Windows 9x, though, where it will show only a 
[Help] button, with no way to close the dialog!

The "XBPMB_HELP" constant can be added to any of the other button constants 
to add a Help button, but this button doesn't seem to have any effect at 
all. This works even with Xbase++ versions prior to 1.9, even though it is 
not defined in those versions' "Xbp.ch" files.

Also, the documentation of ConfirmBox() shows that the following three 
constants are only supported on OS/2: "XBPMB_CANCEL", "XBPMB_ENTER", and 
"XBPMB_ENTERCANCEL". But even the Xbase++ 1.9 documentation doesn't mention 
the new "XBPMB_HELP" constant at all, and how this feature could be used.

And even though OS/2 is no longer supported by Xbase++, if you wanted to 
compile a program in OS/2 and Windows, which uses one of those constants, 
like "XBPMB_ENTER", then this constant must also exist under Windows, even 
though it will result in an "OK" button rather than in an "Enter" button.

So, Alaska should update the documentation (with regards to the "XBPMB_HELP" 
constant), and they might want to "officially" drop OS/2 compatibility all 
together. They might also want to add the new "XBPMB_CANCELTRYAGAINCONTINUE" 
constant and document that it won't work on Windows 9x.

Anyway, I don't think that changing the order of the define statements or 
removing the OS/2 (only) constants should make any difference at all! If it 
does, you should be able to write a small demo program that shows this.

-- Andreas

---                                                                      ---
  Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
  415 Gute Street                     or: Andreas@DDPSoftware.com
  Owosso, MI 48867-4410               or: Andreas@Aerospace-History.net
  Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
---                                                                      ---

Hi Andreas,

I did some more testing and can no longer create the problem.  I can 
only suspect that there was a problem with the defines within an 
intermediate file that did not get recompiled until I edited "Xbp.ch"

This would imply an incorrect date stamp someplace.  I use VX, and when 
I build a project only changed files result in a recompile.  Do you know 
how include files are dealt with?  Could it be that those files are not 
even recompiled on a total rebuild unless an edit has been preformed on 
them?

-Joe

Andreas Gehrs-Pahl wrote:
> Joe,
> 
> BTW, I did a quick test, and it worked fine for me with the unmodified 
> "Xbp.ch" file in all Xbase Versions (1.20.178 through 1.90.331) on all 
> Operating Systems that I had on hand. The new "XBPMB_CANCELTRYAGAINCONTINUE" 
> option ("6") doesn't work on Windows 9x, though, where it will show only a 
> [Help] button, with no way to close the dialog!
> 
> Anyway, I don't think that changing the order of the define statements or 
> removing the OS/2 (only) constants should make any difference at all! If it 
> does, you should be able to write a small demo program that shows this.
> 
> -- Andreas
>

VX uses a generated slightly enhanced pbuild file to compile. So any
change in a header should force a full rebuild.

Jim


Joe Carrick wrote:
> Hi Andreas,
> 
> I did some more testing and can no longer create the problem.  I can
> only suspect that there was a problem with the defines within an
> intermediate file that did not get recompiled until I edited "Xbp.ch"
> 
> This would imply an incorrect date stamp someplace.  I use VX, and when
> I build a project only changed files result in a recompile.  Do you know
> how include files are dealt with?  Could it be that those files are not
> even recompiled on a total rebuild unless an edit has been preformed on
> them?
> 
> -Joe
> 
> Andreas Gehrs-Pahl wrote:
>> Joe,
>>
>> BTW, I did a quick test, and it worked fine for me with the unmodified
>> "Xbp.ch" file in all Xbase Versions (1.20.178 through 1.90.331) on all
>> Operating Systems that I had on hand. The new
>> "XBPMB_CANCELTRYAGAINCONTINUE" option ("6") doesn't work on Windows
>> 9x, though, where it will show only a [Help] button, with no way to
>> close the dialog!
>>
>> Anyway, I don't think that changing the order of the define statements
>> or removing the OS/2 (only) constants should make any difference at
>> all! If it does, you should be able to write a small demo program that
>> shows this.
>>
>> -- Andreas
>>

Joe,

>Do you know how include files are dealt with? Could it be that 
>those files are not even recompiled on a total rebuild unless 
>an edit has been preformed on them?

Header files (with extension ".CH") are actually never compiled. The 
Xbase++ Pre-Processor and Compiler (XPP.exe) will read them to create 
the "*.PPO" (Pre-Processor-Output) files from the Program source code 
"*.PRG" files, before it creates the "*.OBJ" (Object Code) and "*.LIB" 
(Library) files. The same is true for "*.ARC" (Alaska Resource Code) 
files, from which the Alaska Resource Compiler (ARC.exe) creates the 
"*.RES" (Resource) files. After that, the Alaska Linker (ALink.exe) 
will create the "*.EXE" and "*.DLL" from the "*.OBJ", "*.LIB", and 
"*.RES" files.

The Project Builder (PBuild.exe) decides which files need to be compiled 
(and pre-processed), before the linker is called. This is based on two 
different pieces of information: a) the files listed in the [Target] 
section(s) of your Xbase++ Project "*.XPJ" file and b) the file(s) that 
are actually #included in each of the listed source files, which might 
include cascading #includes of files within files. The main criterion is 
the date-time-stamp of the resulting compiled file (like an "*.OBJ" file) 
compared with its source file. Of course, if the target file is simply 
missing, then there is no need to compare date-time-stamps.

The Alaska Project Builder uses the "Auto-Depend" part of your "[Target]" 
sections in your Project "*.XPJ" file to determine which files depend on 
which sources. Those Auto-Depend sections are identified by the following
two text markers: "// $START-AUTODEPEND" and "// $STOP-AUTODEPEND". All 
files between those two markers are considered intermediate files that 
are needed for the linker to create the [Target] file. The Alaska Project 
Builder bases those relations on file names and different extensions. For 
example, all "*.PRG" files are related to the corresponding "*.OBJ" files, 
and all "*.ARC" files are related to corresponding "*.RES" files. The 
opposite is not true, though, as there can be "*.OBJ" and "*.RES" files 
that are only linked in, without any corresponding source files.

For these reasons, changing the date-time-stamp of any file listed AFTER 
those two markers will result in the re-creation of the corresponding 
file listed in the Auto-Depend section. The same is true, if a file that 
is listed in the Auto-Depend section could not be found. As "*.CH" files 
are not directly related to any specific source file in Alaska Project 
files, any missing or updated "*.CH" file that is listed in the Auto-
Depend section will result in a complete re-build of the target!

On the other hand, listing the "*.CH" files after the Auto-Depend section 
together with the other Source files (like your "*.PRG" files), will also 
result in a complete re-build of the target, if one of them is changed, 
as Header files do not have a corresponding target file in the Auto-Depend 
section, which means that PBuild seems to consider the target file missing.

Anyway, in your specific case I would suspect that an old "*.OBJ" file, 
probably compiled with a previous Xbase++ version, was linked into your 
target. Changing the date-time-stamp of the "Xbp.ch" file then resulted 
in a complete re-build of your Target, including this old "*.OBJ" file. 
And voila, the program runs again as expected. If it wasn't compiled with 
a different Xbase++ version, it should have worked regardless, as those 
define constants have actually never changed!

-- Andreas

---                                                                      ---
  Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
  415 Gute Street                     or: Andreas@DDPSoftware.com
  Owosso, MI 48867-4410               or: Andreas@Aerospace-History.net
  Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
---                                                                      ---

Thanks Andreas,

That's pretty much what I thought.  It seems obvious that there was an 
old object file (probably compiled from an older version of Xbase++) and 
that editing "Xbp.ch" resulted in a recompile that fixed the problem.  I 
am not sure exactly why the older version would cause the problem but I 
suspect it has to do with an offset in the data pointers from version to 
version.

Very tricky situation in any event.

-Joe

Andreas Gehrs-Pahl wrote:
> Joe,
> 
>> Do you know how include files are dealt with? Could it be that 
>> those files are not even recompiled on a total rebuild unless 
>> an edit has been preformed on them?
> 
> Header files (with extension ".CH") are actually never compiled. The 
> Xbase++ Pre-Processor and Compiler (XPP.exe) will read them to create 
> the "*.PPO" (Pre-Processor-Output) files from the Program source code 
> "*.PRG" files, before it creates the "*.OBJ" (Object Code) and "*.LIB" 
> (Library) files. The same is true for "*.ARC" (Alaska Resource Code) 
> files, from which the Alaska Resource Compiler (ARC.exe) creates the 
> "*.RES" (Resource) files. After that, the Alaska Linker (ALink.exe) 
> will create the "*.EXE" and "*.DLL" from the "*.OBJ", "*.LIB", and 
> "*.RES" files.
> 
> The Project Builder (PBuild.exe) decides which files need to be compiled 
> (and pre-processed), before the linker is called. This is based on two 
> different pieces of information: a) the files listed in the [Target] 
> section(s) of your Xbase++ Project "*.XPJ" file and b) the file(s) that 
> are actually #included in each of the listed source files, which might 
> include cascading #includes of files within files. The main criterion is 
> the date-time-stamp of the resulting compiled file (like an "*.OBJ" file) 
> compared with its source file. Of course, if the target file is simply 
> missing, then there is no need to compare date-time-stamps.
> 
> The Alaska Project Builder uses the "Auto-Depend" part of your "[Target]" 
> sections in your Project "*.XPJ" file to determine which files depend on 
> which sources. Those Auto-Depend sections are identified by the following
> two text markers: "// $START-AUTODEPEND" and "// $STOP-AUTODEPEND". All 
> files between those two markers are considered intermediate files that 
> are needed for the linker to create the [Target] file. The Alaska Project 
> Builder bases those relations on file names and different extensions. For 
> example, all "*.PRG" files are related to the corresponding "*.OBJ" files, 
> and all "*.ARC" files are related to corresponding "*.RES" files. The 
> opposite is not true, though, as there can be "*.OBJ" and "*.RES" files 
> that are only linked in, without any corresponding source files.
> 
> For these reasons, changing the date-time-stamp of any file listed AFTER 
> those two markers will result in the re-creation of the corresponding 
> file listed in the Auto-Depend section. The same is true, if a file that 
> is listed in the Auto-Depend section could not be found. As "*.CH" files 
> are not directly related to any specific source file in Alaska Project 
> files, any missing or updated "*.CH" file that is listed in the Auto-
> Depend section will result in a complete re-build of the target!
> 
> On the other hand, listing the "*.CH" files after the Auto-Depend section 
> together with the other Source files (like your "*.PRG" files), will also 
> result in a complete re-build of the target, if one of them is changed, 
> as Header files do not have a corresponding target file in the Auto-Depend 
> section, which means that PBuild seems to consider the target file missing.
> 
> Anyway, in your specific case I would suspect that an old "*.OBJ" file, 
> probably compiled with a previous Xbase++ version, was linked into your 
> target. Changing the date-time-stamp of the "Xbp.ch" file then resulted 
> in a complete re-build of your Target, including this old "*.OBJ" file. 
> And voila, the program runs again as expected. If it wasn't compiled with 
> a different Xbase++ version, it should have worked regardless, as those 
> define constants have actually never changed!
> 
> -- Andreas
> 
> ---                                                                      ---
>   Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
>   415 Gute Street                     or: Andreas@DDPSoftware.com
>   Owosso, MI 48867-4410               or: Andreas@Aerospace-History.net
>   Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
> ---                                                                      ---

Andreas,

One more thing:

PBuild either does not recognize a DEF file or erases a DEF file, which I 
consider as a bug.

--
Hannes

"Andreas Gehrs-Pahl" <Andreas@DDPSoftware.com> schrieb im Newsbeitrag 
news:zy5ppluh57xw.166stxpbyofql.dlg@40tude.net...
> Joe,
>
>>Do you know how include files are dealt with? Could it be that
>>those files are not even recompiled on a total rebuild unless
>>an edit has been preformed on them?
>
> Header files (with extension ".CH") are actually never compiled. The
> Xbase++ Pre-Processor and Compiler (XPP.exe) will read them to create
> the "*.PPO" (Pre-Processor-Output) files from the Program source code
> "*.PRG" files, before it creates the "*.OBJ" (Object Code) and "*.LIB"
> (Library) files. The same is true for "*.ARC" (Alaska Resource Code)
> files, from which the Alaska Resource Compiler (ARC.exe) creates the
> "*.RES" (Resource) files. After that, the Alaska Linker (ALink.exe)
> will create the "*.EXE" and "*.DLL" from the "*.OBJ", "*.LIB", and
> "*.RES" files.
>
> The Project Builder (PBuild.exe) decides which files need to be compiled
> (and pre-processed), before the linker is called. This is based on two
> different pieces of information: a) the files listed in the [Target]
> section(s) of your Xbase++ Project "*.XPJ" file and b) the file(s) that
> are actually #included in each of the listed source files, which might
> include cascading #includes of files within files. The main criterion is
> the date-time-stamp of the resulting compiled file (like an "*.OBJ" file)
> compared with its source file. Of course, if the target file is simply
> missing, then there is no need to compare date-time-stamps.
>
> The Alaska Project Builder uses the "Auto-Depend" part of your "[Target]"
> sections in your Project "*.XPJ" file to determine which files depend on
> which sources. Those Auto-Depend sections are identified by the following
> two text markers: "// $START-AUTODEPEND" and "// $STOP-AUTODEPEND". All
> files between those two markers are considered intermediate files that
> are needed for the linker to create the [Target] file. The Alaska Project
> Builder bases those relations on file names and different extensions. For
> example, all "*.PRG" files are related to the corresponding "*.OBJ" files,
> and all "*.ARC" files are related to corresponding "*.RES" files. The
> opposite is not true, though, as there can be "*.OBJ" and "*.RES" files
> that are only linked in, without any corresponding source files.
>
> For these reasons, changing the date-time-stamp of any file listed AFTER
> those two markers will result in the re-creation of the corresponding
> file listed in the Auto-Depend section. The same is true, if a file that
> is listed in the Auto-Depend section could not be found. As "*.CH" files
> are not directly related to any specific source file in Alaska Project
> files, any missing or updated "*.CH" file that is listed in the Auto-
> Depend section will result in a complete re-build of the target!
>
> On the other hand, listing the "*.CH" files after the Auto-Depend section
> together with the other Source files (like your "*.PRG" files), will also
> result in a complete re-build of the target, if one of them is changed,
> as Header files do not have a corresponding target file in the Auto-Depend
> section, which means that PBuild seems to consider the target file 
> missing.
>
> Anyway, in your specific case I would suspect that an old "*.OBJ" file,
> probably compiled with a previous Xbase++ version, was linked into your
> target. Changing the date-time-stamp of the "Xbp.ch" file then resulted
> in a complete re-build of your Target, including this old "*.OBJ" file.
> And voila, the program runs again as expected. If it wasn't compiled with
> a different Xbase++ version, it should have worked regardless, as those
> define constants have actually never changed!
>
> -- Andreas
>
> ---                                                                      ---
>  Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
>  415 Gute Street                     or: Andreas@DDPSoftware.com
>  Owosso, MI 48867-4410               or: Andreas@Aerospace-History.net
>  Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
> ---                                                                      ---

Andreas Gehrs-Pahl,

I believe there is an error in your statement:

> The Project Builder (PBuild.exe) decides which files need to be compiled 
> (and pre-processed), before the linker is called. This is based on two 
> different pieces of information: a) the files listed in the [Target] 
> section(s) of your Xbase++ Project "*.XPJ" file and b) the file(s) that 
> are actually #included in each of the listed source files, which might 
> include cascading #includes of files within files. The main criterion is 
> the date-time-stamp of the resulting compiled file (like an "*.OBJ" file) 
> compared with its source file. Of course, if the target file is simply 
> missing, then there is no need to compare date-time-stamps.

Create a simple project of one or two source files which include a 'local'
*.ch file, but do NOT run pbuild with the /g option.

build the project with a simple 'pbuild' command, and then edit the include
file and try and rebuild again - it won't.

What this shows, is that only the files named in the XPJ project are
considered when deciding what needs to be processed, and embedded references
(including cascading #include) are actually only considered by the compiler
- which is only called if a source named in the project is identified as
newer than the target.

In my opinion, this is desirable for two reasons:

a) PBuild runs much faster obeying a simple script rather than having to
scan each source file in the project on every invocation.

b) This allows the astute developer to temporarily remove (comment out) any
source in the project file to prevent a recompile of that source (doesn't
work of course if it is #included by another source that requires
recompiling).

Regards,

Phil Ide

---------------------
www.xbhcl.com
www.pbih.eu
www.idep.org.uk/xbase
---------------------
In the end, gravity wins -- Dolly Parton.

Phil,

>I believe there is an error in your statement:

You are of course right -- my statement was colored by wishful thinking! 
The Project Builder doesn't actually check any source files and only uses 
the *.XPJ file as its source for files to check. 

That's why I don't quite understand why Alaska changed the rules for VX -- 
stating that Library files (for example) should only be requested via a 
"#Pragma" statement -- as they do in several header files, like "ActiveX.ch"
etc. But this removes the "*.LIB" file from the view of the Project Builder,
so that changes to a LIB and/or DLL will not affect the re-linking of the
project. This might be fine for (more or less static) Xbase++ runtime files, 
but not for third-party and self-built DLLs, IMNSHO. So, I still place all 
the *.LIB files in the *.XPJ file.

-- Andreas

---                                                                      ---
  Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
  415 Gute Street                     or: Andreas@DDPSoftware.com
  Owosso, MI 48867-4410               or: Andreas@Aerospace-History.net
  Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
---                                                                      ---