Author Topic: Dialog as Main Window - Part 1  (Read 2840 times)

0 Members and 1 Guest are viewing this topic.

Arnold

  • Guest
Dialog as Main Window - Part 1
« on: January 10, 2017, 12:21:51 AM »
Hello,

this is a small project which I started some time ago but interrupted it for a while.
The idea is to use resources like menus, bitmaps, controls in a dll. In this case also use a dialog as a main window for small applications. An advantage would be that a visual resource editor like Resed
https://svn.code.sf.net/p/fbedit/code/ResEd22/ResEd.zip
could be used to arrange the controls, menues, etc in the dialog box. The project is then saved as a .rc file which can be compiled to a .res file with GoRc.exe which then can be linked to a dll or exe file.
There is a small Tutorial about dialog as a main window here:
https://www.relisoft.com/win32/windlg.html

For developing the application I linked the resources to a dll which can be created quite easily with OxygenBasic. The code for sliders_dll.o2bas is simply this:
Code: [Select]
$dll
$filename "Sliders.dll"
 
includepath "$/inc/"
 
#include "RTL32.inc"
'#include "RTL64.inc" 
                                                 
// do nothing

I used a small batch file to create the .res and .dll file and to start the main slider.o2bas file:
Code: [Select]
@echo off

set filename=Sliders

:: get path of Oxygenbasic
:: -------------------------
set o2_dir=c:\OxygenBasic
if not exist %o2_dir%\gxo2.exe goto missing_dir
if not exist %filename%.o2bas goto missing_file

:: delete exe, dll
::----------------
if exist %filename%.exe del %filename%.exe
if exist %filename%.dll del %filename%.dll

:: build dll
::----------
echo gxo2: Building dll file
%o2_dir%\gxo2.exe %filename%_dll.o2bas
cd res
if exist %filename%.rc %o2_dir%\tools\goRC %filename%.rc
cd ..
if exist res\%filename%.res %o2_dir%\tools\linkres2exe res\%filename%.res %filename%.dll

:: delete obj, res
::----------------
echo deleting obj, res files
if exist res\%filename%.obj del res\%filename%.obj
if exist res\%filename%.res del res\%filename%.res

::build or run main file
::-----------------------
echo gxo2: Starting %filename%.o2bas
%o2_dir%\gxo2.exe %filename%.o2bas
echo .
echo Done ...
goto goodbye


:missing_dir
echo.
echo Please correct the path for o2_dir in this batch file
echo.
pause
goto goodbye

:missing_file
echo.
echo Error:
echo missing %filename%.o2bas
echo .
pause

:goodbye

To run this project successfully, gxo2.exe (co2.exe) and oxygen.dll are expected in c:\oxygenbasic, GoRC.exe and LinkRes2exe.exe are expected in \OxygenBasic\tools. Otherwise the paths must be adapted in the batch file. I used the latest download of OxygenBasic (Dez. 11 2016).

To create a 32-bit executable of Sliders.o2bas the comment of:
'#include "$/inc/RTL32.inc" must be removed.
To create a 64-bit executable the comment of
'#include "$/inc/RTL64.inc" must be removed. This change must be done in Sliders_dll.o2bas for 64-bit too.

This small application already offers some interesting features: application icon, menu, toolbar, tooltips, buttons, sound, hotkeys, versioninfo - Right-Click with mouse on Sliders.dll and select details. Using Resed.exe (and I only applied it without customizing) still more is possible. The proceeding would always be similiar. The code and resources of the project are attached as a zip file.

Roland

Edit: deleted and modified project attached with later message

.
« Last Edit: January 13, 2017, 09:46:33 AM by Arnold »

Arnold

  • Guest
Re: Dialog as Main Window - Part 1
« Reply #1 on: January 10, 2017, 12:44:24 AM »
Attached are the files sliders.exe and sliders.dll compiled for 64-bit windows. The app will not run with 32-bit windows.

Roland

Edit: deleted and new files attached with later message
« Last Edit: January 13, 2017, 09:47:50 AM by Arnold »

Arnold

  • Guest
Re: Dialog as Main Window - Part 1
« Reply #2 on: January 10, 2017, 04:18:34 AM »
Hi Charles,

Running the slider project as a 32 bit application there is no problem. It will also work as a 64-bit executable but there is a difference: the tooltips are not shown. I am a little bit helpless in this situation. I found that WM_NOTIFY works, and in sliders.inc / function showToolTips the value of lpttt.hdr.code is printed but the line:
   if lpttt.hdr.code = TTN_NEEDTEXT then
has no effect because I expected this:
...
   string TTText
printl "lpttt.hdr.code: " lpttt.hdr.code " hex: " hex lpttt.hdr.code         
   if lpttt.hdr.code = TTN_NEEDTEXT then
printl "TTN_NEEDTEXT: " TTN_NEEDTEXT
...

The value of TTN_NEEDTEXT is -520 and I do not know if negative values must be treated a little bit different for 64-bit Windows. Is there a solution or work-around? There are some more negative Winapi constants.

Roland


.

Arnold

  • Guest
Re: Dialog as Main Window - Part 1
« Reply #3 on: January 11, 2017, 02:13:31 PM »
Hi Charles,

maybe I found a solution. I used this statement:
   if lpttt.hdr.code = (uint) TTN_NEEDTEXT then
and now I see tooltips in Win32 and Win64.  Is this approach ok?

Roland

Mike Lobanovsky

  • Guest
Re: Dialog as Main Window - Part 1
« Reply #4 on: January 11, 2017, 07:57:07 PM »
Yes Roland, this is correct.

MSDN and related reference sources are mostly C oriented. Unless an integral numeric value the C language uses in its #define ascends to something that's explicitly specified as long, it is assumed to be an int and as such is bitness-dependent. Thus, -520 would have different hex representations under x86 and x64 to reflect automatic sign extension performed by a C compiler on the higher order bits of an x64 integer value. Apparently, Oxygen's explicit casts to (unsigned) int are also bitness-aware and are thus C compliant while Oxygen's equates still aren't.

I'd also like to point out that your declarations of the two msvcrt functions you're using in your code aren't safe. Msvcrt.dll is a CDECL library so your declarations of srand() and rand() should use a cdecl attribute. I am not at all sure that O2 would use some sort of automatic parameter stack balancing of its own on a user call to a function in a 3rd party library.

Arnold

  • Guest
Re: Dialog as Main Window - Part 1
« Reply #5 on: January 12, 2017, 12:10:57 AM »
Hi Mike,

thank you for the info. Now I know what I can do in similiar situations. I did not like to change the member: dword code in type NMHDR.

The functions rand() and srand() are only experimental. I also read that they are not safe (and I do not know what they mean) and that there is a function rand_s which is used with MSVCRT100.dll. When I first declared rand() and srand() I used the cdecl convention. But then I remembered that using IUP.dll I cannot use cdecl in 64-bit and tried without. I used these functions in the puzzle project and they work in 32bit and 64bit. I have to admit I do not know why this is the case.

Roland

Mike Lobanovsky

  • Guest
Re: Dialog as Main Window - Part 1
« Reply #6 on: January 12, 2017, 03:48:49 AM »
You are correct about 64 bit IUP: you can't use cdecl under 64-bit MS Windows. Instead, you are supposed to use ms64 that's the only calling convention on 64-bit MS platforms.

But as long as you're on 32 bits, you're supposed to make a distinction between cdecl (caller cleans/balances the stack) and stdcall (callee cleans/balances the stack) calling conventions. All msvcrt exports are cdecl and must be declared as such to hint O2 to employ its stack balancing mechanism on each call to an msvcrt function. 32-bit O2 defaults to stdcall if the calling convention isn't specified explicitly.

Your DLLs use 32-bit includes:
Quote from: Arnold
Code: [Select]
#include "RTL32.inc"
'#include "RTL64.inc"
which was the reason why I raised this issue to your attention at all.

Arnold

  • Guest
Re: Dialog as Main Window - Part 1
« Reply #7 on: January 12, 2017, 04:40:12 AM »
Maybe I should define a Win32 / Win64 flag and declare both variations? If it works I could meet all demands. I know there are a lot more MSVCRT.dll functions which could be useful.

Mike Lobanovsky

  • Guest
Re: Dialog as Main Window - Part 1
« Reply #8 on: January 12, 2017, 05:24:19 AM »
Exactly!

Arnold

  • Guest
Re: Dialog as Main Window - Part 1
« Reply #9 on: January 13, 2017, 09:53:45 AM »
Hello,

I tried to implement Mike's suggestions and used a trick which I found in \projectsC\Powerbasic\DemoTheo.o2bas. In Sliders.o2bas now there is this modification:

Code: OxygenBasic
  1. ' Sliders.o2bas - a Puzzle demo game
  2. ' This can also be compiled to an executable
  3. ' must use sliders.dll which keeps the resources
  4.  
  5. macro executable(name,width)
  6. % Filename name
  7. #if (width=64)
  8.   #define Win64
  9.   include "$\inc\RTL64.inc"
  10. #else
  11.   include "$\inc\RTL32.inc"
  12. #endif
  13. end macro
  14.  
  15. '32 for Win32, 64 for Win64
  16. ' executable("Sliders.exe",32)
  17. ...
  18.  

In Sliders.inc I added these lines:

Code: OxygenBasic
  1. ...
  2. ! PlaySound lib "winmm.dll" alias "PlaySoundA" (char * pszSound, sys hmod, DWORD fdwSound ) as bool
  3. #ifdef Win64
  4. ! srand lib "msvcrt.dll" (int seed)
  5. ! rand lib "msvcrt.dll" () as int
  6. #else
  7. ! srand cdecl lib "msvcrt.dll" (int seed)
  8. ! rand cdecl lib "msvcrt.dll" () as int
  9. #endif
  10. ...
  11.  

Sliders.o2bas can be run either directly, or compiled to an exe by removing the comment of:
' executable("Sliders.exe",32)
For creating a 64-bit executable the value 64 must be used, and in Sliders_dll.o2bas #include "RTL64.inc" must be applied for a 64-bit dll. The batch file will then build and link the resources to the dll, otherwise the necessary steps must be executed by hand in a console window. I attached the modified project and a running Win64 executable as zip files.

The idea is to use a more general approach for this kind of application - either run the program directly or create a 32/64 bit executable. Perhaps there is a better way to achieve this? My further intention is to use almost the same code to create a standalone 32/64 bit executable with the resources directly linked (part 2).

Roland


.

Mike Lobanovsky

  • Guest
Re: Dialog as Main Window - Part 1
« Reply #10 on: January 13, 2017, 05:41:58 PM »
Hi Roland,

Yours seems to be a pretty viable solution, at least it does exactly what you want it to do. Probably Charles will offer something better from up his sleeve in his usual way, but we can certainly survive in the meantime. :)