Author Topic: Bug or feature ?(termination of GUI applications)  (Read 344 times)

massel_co

  • Newbie
  • *
  • Posts: 5
    • View Profile
Bug or feature ?(termination of GUI applications)
« on: March 18, 2020, 04:28:30 AM »
Hi,

the termination of GUI applications seem to be defective (compiled with BCX 7.45 and PellesC for Win32).
If the main window is closed via the close button (cross at top right position) the process is not terminated (see task manager) but stays alive in the background.
If the END command is put in the WM_CLOSE selection block (see below) the task is terminated as expected. In C this leads to a line
Quote
ExitProcess(0 );
Without this line the process won't terminate.

Code: [Select]
BEGIN EVENTS
  SELECT CASE CBMSG
...
  CASE WM_CLOSE
  ...
  END ' necessary for correct termination
  END SELECT
...
END EVENTS

Is this behavior purpose or a bug? If this is not wanted please insert the
Quote
ExitProcess(0 );
automatically in the WM_CLOSE section.

Greetings,

Sebastian

MrBcx

  • Administrator
  • Sr. Member
  • *****
  • Posts: 264
    • View Profile
Re: Bug or feature ?(termination of GUI applications)
« Reply #1 on: March 18, 2020, 08:22:17 AM »
Sebastian,

What are you basing your bug report on?

I just examined several of the GUI_Demos and I am not seeing the problem you described.

I am running Windows 10 Pro (64-bit) and I have personally compiled the demos many times
using MSVC2015, MINGW32, PELLES C, and LCC-WIN32 and ran them with no problems.

I am attaching a scrnshot showing one of the Gui_Demos  ( Amort.Exe ) running and terminating correctly.

The translated code uses only WM_DESTROY.

I think the problem you are experiencing needs more investigation.

massel_co

  • Newbie
  • *
  • Posts: 5
    • View Profile
Re: Bug or feature ?(termination of GUI applications)
« Reply #2 on: March 18, 2020, 04:32:26 PM »
Hi,

I had two occasions where I got this phenomena.
I wanted to use the CompilerManager.exe, as problems occurred I tried to revise and recompile the compiler manager from the section OpenSrc (up to that point I only modified 3 EXIT statements, see attached CM.BAS).
If I select a bas file to compile and press the GO button unfortunately nothing happens (that why I look for the problem). Maybe something crashed within the process (?). Then I try to terminate the application by pressing the CLOSE cross (right top) and the window disappears but the process stays behind in the task manager. I noticed this because I couldn't link anymore...
The concerned section in CompilerManager.bas (or revised CM.bas) is:
Code: [Select]
    CASE WM_CLOSE
    DeleteObject(BCXFONT)
  END SELECT

It is translated to:
Code: [Select]
// [cm.bas - 280] CASE WM_CLOSE
      goto L1000;
    }
  if(Msg==WM_CLOSE )
    {
// [cm.bas - 281] DeleteObject(BCXFONT)
      DeleteObject(BcxFont);
// [cm.bas - 282] END SELECT
    }
L1000:;
// [cm.bas - 283] END DIALOG
  if(Msg==WM_CLOSE) EndDialog(hWnd,0);
  return 0;
}

As I want a real termination of the process I add a END statement:
Code: [Select]
    CASE WM_CLOSE
    DeleteObject(BCXFONT)
    END
  END SELECT
This is translated to:
Code: [Select]
// [cm.bas - 280] CASE WM_CLOSE
      goto L1000;
    }
  if(Msg==WM_CLOSE )
    {
// [cm.bas - 281] DeleteObject(BCXFONT)
      DeleteObject(BcxFont);
// [cm.bas - 282] END
      ExitProcess(0 );
// [cm.bas - 283] END SELECT
    }
L1000:;
// [cm.bas - 284] END DIALOG
  if(Msg==WM_CLOSE) EndDialog(hWnd,0);
  return 0;
}

With this trick the termination was successful (even something went wrong within the application).

The same issue occurred with a small DLL testing application I build. In this application the GUI application calls a DLL that uses its own dialogue. If i.e. the dialogue of the GUI application was closed while it was running (shortly after pressing the button "Show progress bar") the GUI window was hidden but not terminated (see GUI_Problem.zip) and the DLL dialogue remained.
Maybe the problem is related here to the fact that I use DOEVENTS() to be able to stop the GUI process again with the same button.
With the END statement the GUI application + plus the DLL were terminated as expected.

Maybe the effect is only there if more or less asynchronous program parts are used.

I run BCX 7.45 and PellesC on Win 7 Pro SP1 (64 bit).

MrBcx

  • Administrator
  • Sr. Member
  • *****
  • Posts: 264
    • View Profile
Re: Bug or feature ?(termination of GUI applications)
« Reply #3 on: March 18, 2020, 07:16:19 PM »
I compiled your CM.BAS, found a 2005 copy of MainBatch.bat, modified the Pelles console batch instructions in it, and then ran CM.

CM correctly translated and compiled a copy of Bcx 746 beta.  See scrnshot.

If you don't have MainBatch.bat, CM will not function correctly.

I've attached the April 2005 copy of MainBatch.bat by Mike Henning.
You may need to update things for your system.
« Last Edit: March 18, 2020, 07:53:28 PM by MrBcx »

Robert

  • Full Member
  • ***
  • Posts: 212
    • View Profile
Re: Bug or feature ?(termination of GUI applications)
« Reply #4 on: March 18, 2020, 08:26:51 PM »
Hi,

The same issue occurred with a small DLL testing application I build. In this application the GUI application calls a DLL that uses its own dialogue. If i.e. the dialogue of the GUI application was closed while it was running (shortly after pressing the button "Show progress bar") the GUI window was hidden but not terminated (see GUI_Problem.zip) and the DLL dialogue remained.
Maybe the problem is related here to the fact that I use DOEVENTS() to be able to stop the GUI process again with the same button.
With the END statement the GUI application + plus the DLL were terminated as expected.

Maybe the effect is only there if more or less asynchronous program parts are used.

I run BCX 7.45 and PellesC on Win 7 Pro SP1 (64 bit).

Hi Sebastian:

I noticed that your Gui_Problem.bas was generated (in part ???) by Dialog Converter 3.01a. This utility was written by Dindo Liboon and the 3.01a version has been upgraded several times with the latest version available on Dindo's Github site at

https://github.com/dindoliboon/archive/tree/master/bcx/dc

There's a lot of good stuff there. Check it out.

I don't know if Dindo's latest DC is compliant with BCX translation of termination procedures.  Can you post the dialog code from which Gui_Problem.bas was generated?

MrBcx

  • Administrator
  • Sr. Member
  • *****
  • Posts: 264
    • View Profile
Re: Bug or feature ?(termination of GUI applications)
« Reply #5 on: March 19, 2020, 09:58:06 AM »
 
As I want a real termination of the process I add a END statement:
 

If seems Dialog Converter emits the BCX keyword CLOSEDIALOG which emits the Win32 API EndDialog which
should only be used for processes created by one of the Windows API dialogbox functions.

https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-enddialog

You made a good decision to use END which forced BCX to emit ExitProcess. 

« Last Edit: March 19, 2020, 10:16:13 AM by MrBcx »

MrBcx

  • Administrator
  • Sr. Member
  • *****
  • Posts: 264
    • View Profile
Re: Bug or feature ?(termination of GUI applications)
« Reply #6 on: March 19, 2020, 12:04:48 PM »

The same issue occurred with a small DLL testing application I build. In this application the GUI application calls a DLL that uses its own dialogue. If i.e. the dialogue of the GUI application was closed while it was running (shortly after pressing the button "Show progress bar") the GUI window was hidden but not terminated (see GUI_Problem.zip) and the DLL dialogue remained.
Maybe the problem is related here to the fact that I use DOEVENTS() to be able to stop the GUI process again with the same button.
With the END statement the GUI application + plus the DLL were terminated as expected.

Maybe the effect is only there if more or less asynchronous program parts are used.

I run BCX 7.45 and PellesC on Win 7 Pro SP1 (64 bit).

Two things about this ...

1) I had to add a cast here:

  lpfnOldProc = (FARPROC) GetProp(hWnd, "oldproc")

2)
This is not necessary and should be removed. 
  CASE WM_CLOSE
  CLOSEDIALOG


I was able to toggle the Show/Hide Progress bar button multiple times and click the Close button with no unwanted side effects.


massel_co

  • Newbie
  • *
  • Posts: 5
    • View Profile
Re: Bug or feature ?(termination of GUI applications)
« Reply #7 on: March 19, 2020, 04:15:25 PM »
Hi,

Thanks for the replies.
As you may have noticed I compiled my files with the PellesC from the distribution (version 7).
That is why I didn't got an error on the forgotten cast (FARPROC). I updated the code as you suggested and dropped the CLOSEDIALOG.

Finally I found out the problem with the original CompilerManager.bas:
As I have spaces in the paths to the compiler etc. it is necessary to put quotes around the file path calls (with ENC$).
I enclosed the revised version (cm.bas).
Additionally the connected batch files have to be modified. With PellesC version 7 the BCX Compiler Manager works now well.


@Robert: The resource files of the DLL are included in the attachment GUI_Problem.zip (see below). The original version of the files was from 2005 and the resources of GUI_Problem is directly coded as you see (no old sources remained). If you see anything to optimize please tell. I have already downloaded the new dc.


I will try to use PellesC (version 9) in future.
I already reconfigured PellesC.bat and povars32.bat.
@MrBcx: Could you provide an updated version of mainbatch.bat for use with PellesC version 9? I seem to have a library path problem.

Greetings,

Sebastian

MrBcx

  • Administrator
  • Sr. Member
  • *****
  • Posts: 264
    • View Profile
Re: Bug or feature ?(termination of GUI applications)
« Reply #8 on: March 19, 2020, 05:44:01 PM »

@MrBcx: Could you provide an updated version of mainbatch.bat for use with PellesC version 9? I seem to have a library path problem.

Greetings,
Sebastian

Sebastian ... attached is a quick hack that allowed me to compile CONSOLE apps using PELLES 9.0

If you need to compile a GUI or DLL with Pelles, you should be able to use the hack as a guide.

Sorry ... I have my hands full right now or I'd put more effort into it.


Robert

  • Full Member
  • ***
  • Posts: 212
    • View Profile
Re: Bug or feature ?(termination of GUI applications)
« Reply #9 on: March 20, 2020, 03:21:40 AM »
 
As I want a real termination of the process I add a END statement:
 

If seems Dialog Converter emits the BCX keyword CLOSEDIALOG which emits the Win32 API EndDialog which
should only be used for processes created by one of the Windows API dialogbox functions.

https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-enddialog

You made a good decision to use END which forced BCX to emit ExitProcess.

For What It's Worth (Stop, Hey What's That ....), Dindo's Dialog Converter 3.4 emits

Code: [Select]

' *************************************************************************
    Case WM_CLOSE
' *************************************************************************

' *************************************************************************
    Case WM_DESTROY
' *************************************************************************
        PostQuitMessage(0)


perhaps earlier versions of Dialog Converter emitted  CLOSEDIALOG


massel_co

  • Newbie
  • *
  • Posts: 5
    • View Profile
Re: Bug or feature ?(termination of GUI applications)
« Reply #10 on: March 20, 2020, 06:05:27 AM »
Thanks to you all.

I adjusted mainbatch.bat according to your example to work with CON, GUI and DLL of PellesC 9.0 (see attachment). It seems to work.
Now I am hopefully up to date with my system.
Have a nice weekend!

MrBcx

  • Administrator
  • Sr. Member
  • *****
  • Posts: 264
    • View Profile
Re: Bug or feature ?(termination of GUI applications)
« Reply #11 on: March 20, 2020, 08:40:47 AM »
I know Sebastian uploaded an updated MainBatch.bat file.

I'm attaching another version of MainBatch.bat that allows Pelles to also compile
GUI, Console, and Dll using the Pelles Driver Program cc.exe , as in the original.

The trick to getting cc.exe to work again was to add the Pelles Library Path for the linker

/LIBPATH:%PELLESLIB%

CC invokes the compiler and linker in one statement instead of two.

Code: [Select]
:: PELLESLIB added by MrBcx Mar 2020
SET PELLESLIB=C:\PellesC\lib\win\



Code: [Select]
:Pelles
IF EXIST %3.res GOTO res
IF NOT EXIST %3.rc GOTO nores
ECHO Compiling resources.....
%PELLESPATH%porc.exe %3.rc  /fo %3.res
:res
IF EXIST %3.res SET RESFILE=%3.res
:nores
ECHO Compiling %3.c with Pelles C
if "%2"=="GUI" goto PellesGui
if "%2"=="DLL" goto PellesDll

%PELLESPATH%cc /Go /Gn /W1 /Gd /Ze /Zx /Tx86-coff /D_WIN32_WINNT=0x501 %3.c /machine:x86 /subsystem:console /LIBPATH:%PELLESLIB% %RESFILE% %3.obj   %4 %5 %6 %7
goto done

:PellesDll
%PELLESPATH%cc /Go /Gn /W1 /Gd /Ze /Zx /Tx86-coff /D_WIN32_WINNT=0x501 %3.c -OUT:%3.dll     -DLL /LIBPATH:%PELLESLIB%  %3.obj %RESFILE% %4 %5 %6 %7 
goto done

:PellesGui
%PELLESPATH%cc /Go /Gn /W1 /Gd /Ze /Zx /Tx86-coff /D_WIN32_WINNT=0x501 %3.c  -subsystem:windows /LIBPATH:%PELLESLIB% %3.obj %RESFILE% %4 %5 %6 %7 
goto done

« Last Edit: March 21, 2020, 11:07:47 AM by MrBcx »

Robert

  • Full Member
  • ***
  • Posts: 212
    • View Profile
Re: Bug or feature ?(termination of GUI applications)
« Reply #12 on: March 20, 2020, 08:47:56 PM »
I know Sebastian uploaded an updated MainBatch.bat file.

I'm attaching another version of MainBatch.bat that allows Pelles to also compile
GUI, Console, and Dll using the Pelles Driver Program cc.exe , as in the original.

The trick to getting cc.exe to work again was to add the Pelles Library Path for the linker

/LIBPATH:%PELLESLIB%

CC invokes the compiler and linker in one statement instead of two.

Code: [Select]
:: PELLESLIB added by MrBcx Mar 2020
SET PELLESLIB=C:\PellesC\lib\win\



Code: [Select]
:Pelles
IF EXIST %3.res GOTO res
IF NOT EXIST %3.rc GOTO nores
ECHO Compiling resources.....
%PELLESPATH%porc.exe %3.rc  /fo %3.res
:res
IF EXIST %3.res SET RESFILE=%3.res
:nores
ECHO Compiling %3.c with Pelles C
if "%2"=="GUI" goto PellesGui
if "%2"=="DLL" goto PellesDll

%PELLESPATH%cc /Go /Gn /W1 /Gd /Ze /Zx /Tx86-coff /D_WIN32_WINNT=0x501 %3.c /machine:x86 /subsystem:console /LIBPATH:%PELLESLIB% %RESFILE% %3.obj   %4 %5 %6 %7
goto done

:PellesDll
%PELLESPATH%cc /Go /Gn /W1 /Gd /Ze /Zx /Tx86-coff /D_WIN32_WINNT=0x501 %3.c -OUT:%3.dll     -DLL /LIBPATH:%PELLESLIB%  %3.obj %RESFILE% %4 %5 %6 %7 
goto done

:PellesGui
%PELLESPATH%cc /Go /Gn /W1 /Gd /Ze /Zx /Tx86-coff /D_WIN32_WINNT=0x501 %3.c  -subsystem:windows /LIBPATH:%PELLESLIB% %3.obj %RESFILE% %4 %5 %6 %7 
goto done


Copying from the Pelle's C povars batch files, 32 bit should be

Code: [Select]
SET PELLESLIB=C:\PellesC\Lib;C:\PellesC\Lib\Win
64  bit

Code: [Select]
SET PELLESLIB=C:\PellesC\Lib;C:\PellesC\Lib\Win64

MrBcx

  • Administrator
  • Sr. Member
  • *****
  • Posts: 264
    • View Profile
Re: Bug or feature ?(termination of GUI applications)
« Reply #13 on: March 21, 2020, 11:10:48 AM »

Copying from the Pelle's C povars batch files, 32 bit should be

Code: [Select]
SET PELLESLIB=C:\PellesC\Lib;C:\PellesC\Lib\Win
64  bit

Code: [Select]
SET PELLESLIB=C:\PellesC\Lib;C:\PellesC\Lib\Win64

I re-uploaded my version with your change to the 32-bit path.

If an industrious person wanted to update CompilerManager, adding options for the various 64-bit compiles would be useful.