theForger's Tutorials revised

[Charles Pegge]

Hi Roland,

Very briefly, you need to close the dialog namespace by uncommenting 'namespace

Code: [Select]

uses winutil
uses dialogs
namespace


[Arnold]

Thank you Charles. Sometimes I miss the simplest solutions. I replaced the code in reply #29. The example works very fine now with Win32 and Win64.

Roland

[Charles Pegge]

I'm glad we caught that one, Roland. I will ensure that namespaces automatically close before a program performs its epilog.

[Arnold]

Hi Charles,

I am trying to convert theForger's app_four.o2bas using MainWindow of WinUtil.inc. This works if I use WM_NCCREATE. The app would work fine, but there is a problem with using Ctrl-F6 and Ctrl-F4 for the mdi child windows. I tried to use MessageLoopProcesses, but this seems not to work.
So as a test I modified in WinUtil.inc:

...
    #endif
    '
if not TranslateMDISysAccel(g_hMDIClient, &wm) then
    TranslateMessage @wm
    DispatchMessage @wm
end if
  wend 'GetMessage / PeekMessage
...

Now mdi.o2bas works fine, but I know this cannot be applied. In other apps there are also other combinations possible e.g.:

       ' Check for accelerator keystrokes
       if TranslateAccelerator(
                hDlg,               // handle to receiving window
                hAccelTable,        // handle to active accelerator table
                &Msg) = 0 then      // message data
       if not IsDialogMessage(hFindDialog, &Msg) then
       if not IsDialogMessage(hFindReplaceDialog, &Msg) then
       if not IsDialogMessage(hDlg, &Msg) then
         TranslateMessage(&Msg)
         DispatchMessage(&Msg)
       end if
       end if
       end if
       end if

Would it be possible to replace :
 
TranslateMessage @wm
DispatchMessage @wm

somehow with an own block or could I use % MessageLoopProcesses in some way?

Roland

Edit: Code deleted. There is no need to use WM_NCCREATE

[Charles Pegge]

Hi Roland,

I think this will fit into the system if you provide a macro defining InMessageLoop which will give you full control over the contents.

Code: [Select]

    #ifdef InMessageLoop
      InMessageLoop ''CUMSTOMISED MESSAGE PROCESSING
    #else
      #ifdef MessageLoopProcesses
        MessageLoopProcesses
      #endif
      '
      TranslateMessage @wm
      DispatchMessage @wm
    #endif


[Arnold]

Thank you again Charles. I used InMessageLoop this way:

$ filename "mdi.exe"

'uses rtl32
'uses rtl64

% InMessageLoop
sys g_hMDIClient = null
macro InMessageLoop
  if not TranslateMDISysAccel(g_hMDIClient, &wm) then     
     TranslateMessage(&wm)
     DispatchMessage(&wm)
  end if           
end macro

uses winutil
uses dialogs
namespace
...

I know I must be careful when using InMessageLoop in order to avoid endless loops and freezing the app, but the macro offers a lot of valuable usage.

After applying some more O2  library functions in app_four.o2bas I will upload my results.

Roland

[Arnold]

This is theForger example A4: app_four1.o2bas, using WinUtil.inc which Charles provided in reply #34. It will run as a 64-bit and as a 32-bit exe. I added tooltips for the toolbar, shortcuts for the menu items and arranged menus a la resource file.

App_four is remarkable in my opinion. Although coded long ago, it is still usable in the days of Windows 10. It could be easily extended with adding statusbar statements, goto line, find / findreplace, checking for modified files, in order to get a working editor. A richedit control could be used. Some routines could be added to run Oxygenbasic programs.

But I will not do this. (at least not at this point)

Roland

[Arnold]

Hi Charles,

for app_four1.o2bas I must use the constant:
% TTN_NEEDTEXT = -520

This works fine in Win32 but in Win64 this is read as 4294966776. I used the constant in sub showToolTips:
...
   if lpttt.hdr.code = TTN_NEEDTEXT then
     select lpttt.hdr.idFrom   
...


lpttt.hdr.code will not fire in Win64. So I used this definition to get tooltips to work:
dword TTN_NEEDTEXT = -520

Are there other options possible in order to use: % TTN_NEEDTEXT = -520 ?

Roland

[Mike Lobanovsky]

Hi Roland,

Prefer to use HEX notation when defining Win32 equates. That'll automatically dismiss the sign problem caused by using longs in place of DWORDs. HEX values are treated as unsigned ints on default. (hopefully this applies to O2 too)

[Arnold]

Hi Mike,

I tried to use:
% TTN_NEEDTEXT = 0xFFFFFDF8

but for me this does also only work in Win32. As lpttt.hdr.code is derived from NMHDR structure (WinData.inc) I suppose I must do a cast somewhere? (or use dword for the declaration, which I would like to avoid)

Roland

[Charles Pegge]

Hi Roland & Mike,

The problem is that o2 integer equates are typeless, and so are the prototypes. You can use a uint or dword variable instead. Then sign extension into the upper bits will not occur.

[Mike Lobanovsky]

Hi Charles,

Then sign extension into the upper bits will not occur.

But I think it should occur by all means!

There are a few Win32 constants that the C headers would #define as signed integers rather than HEX DWORDs. I think to overcome this glitch in Oxygen, equates could be treated internally as SYSes. This would extend their sign, if any, from 32 to 64 bits automatically, so that % TTN_NEEDTEXT = -520 would always amount to -520 regardless of platform bitness.

Does OxygenBasic treat its equates as PP macros rather than variables? If yes then DWORD or uint vars would be a memory consuming palliation rather than a full replacement IMO...

[Charles Pegge]

The problem is the contrary, Mike.

O2 is eager to sign-extend its numbers, but this API seems to expect a 32bit integer, with the upper 32 bits set to zero. From our point of view, this is unexpected. The Windows-side should not be evaluating the upper bits when it apparently doesn't use them.

[Arnold]

Hi Charles,

in commctrl.h of mingw32 there are these definitions:

#define TTN_FIRST   ((UINT)-520)

#define TTN_GETDISPINFOA    (TTN_FIRST - 0)
#define TTN_GETDISPINFOW    (TTN_FIRST - 10)
#define TTN_NEEDTEXTA   TTN_GETDISPINFOA
#define TTN_NEEDTEXTW   TTN_GETDISPINFOW

Should I use a method like this? Then I would prefer to use: dword/uint TTN_NEEDTEXT = -520. But could this approach be used generally? As Mike stated there are some more negative WinApi constants. I had no problem using them in Win32 but until now I did not use them in Win64.

Roland

[Charles Pegge]

Using a global variable for dodgy negative equates like this, is the only option at present.

I would also recommend using global variables for floating-point number equates, since the FPU cannot load numbers directly anyway. It is faster and uses less machine code.