64 bit Gui_Demo issues

[jcfuller]

Kevin,
  I am going to post as I find them or I'll forget or misplace the info

  First 64bit issue with the Gui_Demos.
Unfortunately I didn't try Pelles64 before I changed it.

I compile first with CLANG as you said it has the best error/warning info.

BC.BAS

If Use_BCX_Tooltip

Change two instances of
    FPRINT FP_WRITE, "  ti.uId=(UINT)hWnd;"
To
    FPRINT FP_WRITE, "  ti.uId=(INT_PTR)hWnd;"

James

[MrBcx]

BC.BAS

If Use_BCX_Tooltip

Change two instances of
    FPRINT FP_WRITE, "  ti.uId=(UINT)hWnd;"
To
    FPRINT FP_WRITE, "  ti.uId=(INT_PTR)hWnd;"

JC -- Applied to 761 and tested w/ Pelles 32/64 -- works as it should.  Thanks ...

[jcfuller]

Kevin,
  Heads up on BcxEdit.
There is an issue in the rc file. I do not know how the original included res file was created but the rc will not compile.

Line 43:
"IDMAINMENU" MENU

there should not be quotes. remove them
IDMAINMENU is defined above under // Windows Controls

With this change there are a couple changes needed in the basic source
In WINMAIN comment this line:
AppMenu$  = "IDMAINMENU"

change:
Wc.lpszMenuName    = AppMenu$
To
Wc.lpszMenuName    = MAKEINTRESOURCE(IDMAINMENU)

'==============================================================================

An item I was criticized for with my bc9 demos for José's CWindow port and you are also guilty are are the inclusion of WS_SIZEBOX and  WS_MAXIMIZEBOX in all the demos. I was not aware at the time of a Function to remedy this (AfxRemoveWindowStyle) without having to do a FULL create with all the default params:
BCX I see has the same  functionality A simple addition of:
MODSTYLE(Form1,0,WS_SIZEBOX|WS_MAXIMIZEBOX)   'no size or max box
corrects the issue.

It is now one of my pet peeves


James

[MrBcx]

Kevin,
  Heads up on BcxEdit.
There is an issue in the rc file. I do not know how the original included res file was created but the rc will not compile.

Line 43:
"IDMAINMENU" MENU

there should not be quotes. remove them
IDMAINMENU is defined above under // Windows Controls

With this change there are a couple changes needed in the basic source
In WINMAIN comment this line:
AppMenu$  = "IDMAINMENU"

change:
Wc.lpszMenuName    = AppMenu$
To
Wc.lpszMenuName    = MAKEINTRESOURCE(IDMAINMENU)

'==============================================================================

An item I was criticized for with my bc9 demos for José's CWindow port and you are also guilty are are the inclusion of WS_SIZEBOX and  WS_MAXIMIZEBOX in all the demos. I was not aware at the time of a Function to remedy this (AfxRemoveWindowStyle) without having to do a FULL create with all the default params:
BCX I see has the same  functionality A simple addition of:
MODSTYLE(Form1,0,WS_SIZEBOX|WS_MAXIMIZEBOX)   'no size or max box
corrects the issue.

It is now one of my pet peeves

James

Thanks for the updates. 

The original res file was created using Lcc-Win32's resource compiler (lrc.exe) which still does the job.

With your changes to the .rc and .bas, the Pelles resource compiler (porc.exe) also gets the job done.

You can have your pet peeves ... I have bigger fish to fry.

[jcfuller]

Kevin,

Doughboy

Clang and the MinGW whine:
from BCX_OlePicture
    int        dwFileSize;
    int        dwBytesRead;
I tried
    DWORD        dwFileSize;
    DWORD        dwBytesRead;
and no more warnings. the dw prefix would indicate a DWORD variable??
'------------------------------------------------------------------------------
Clang did not like this in the WndProc. All others were ok.
    if(Msg == WM_HSCROLL || WM_VSCROLL || WM_SIZE)

Doughboy.c(651,26): warning: use of logical '||' with constant operand [-Wconstant-logical-operand]
    if(Msg == WM_HSCROLL || WM_VSCROLL || WM_SIZE)
                         ^  ~~~~~~~~~~
Doughboy.c(651,26): note: use '|' for a bitwise operation
    if(Msg == WM_HSCROLL || WM_VSCROLL || WM_SIZE)
                         ^~
                         |
Doughboy.c(651,40): warning: use of logical '||' with constant operand [-Wconstant-logical-operand]
    if(Msg == WM_HSCROLL || WM_VSCROLL || WM_SIZE)
                                       ^  ~~~~~~~
Doughboy.c(651,40): note: use '|' for a bitwise operation
    if(Msg == WM_HSCROLL || WM_VSCROLL || WM_SIZE)

I did not find code that worked??
'==============================================================================
James

[MrBcx]

Thanks for the report JC


BCX_OLEPICTURE needs an update

Change

if(Msg == WM_HSCROLL || WM_VSCROLL || WM_SIZE)

to

if ( Msg==WM_HSCROLL || Msg==WM_VSCROLL || Msg==WM_SIZE )


Plus your updates:

DWORD        dwFileSize;
DWORD        dwBytesRead;


These will be in 761.

[MrBcx]

JC -

If you're testing 64-bit compiles, you will likely encounter "missing olepro32.lib" errors on a handful
of GUI demos.  Those were overcome with $NOLIBRARY "olepro32.lib" directive to support the
64-bit batch files that I recently uploaded.

761 will remove that library entirely. 

Pelle stated in a reply to Robert 12 years ago that olepro32.lib was only needed for very old versions of
Windows ( up to Windows 2000 ) and that its functionality was rolled into oleaut32.lib.

[jcfuller]

Kevin,
  I'm not sure if this is me or the BCX dpi settings or just the wrong sizes to begin with?
Editctrl.bas

James

[Robert]

Kevin,
  Heads up on BcxEdit.
There is an issue in the rc file. I do not know how the original included res file was created but the rc will not compile.

Line 43:
"IDMAINMENU" MENU

there should not be quotes. remove them
IDMAINMENU is defined above under // Windows Controls

With this change there are a couple changes needed in the basic source
In WINMAIN comment this line:
AppMenu$  = "IDMAINMENU"

change:
Wc.lpszMenuName    = AppMenu$
To
Wc.lpszMenuName    = MAKEINTRESOURCE(IDMAINMENU)

'==============================================================================

An item I was criticized for with my bc9 demos for José's CWindow port and you are also guilty are are the inclusion of WS_SIZEBOX and  WS_MAXIMIZEBOX in all the demos. I was not aware at the time of a Function to remedy this (AfxRemoveWindowStyle) without having to do a FULL create with all the default params:
BCX I see has the same  functionality A simple addition of:
MODSTYLE(Form1,0,WS_SIZEBOX|WS_MAXIMIZEBOX)   'no size or max box
corrects the issue.

It is now one of my pet peeves

James

Thanks for the updates. 

The original res file was created using Lcc-Win32's resource compiler (lrc.exe) which still does the job.

With your changes to the .rc and .bas, the Pelles resource compiler (porc.exe) also gets the job done.

You can have your pet peeves ... I have bigger fish to fry.

To compile on MSVC change line 80 Bcxedit.bas from

Code Select Expand



  Wc.hbrBackground   = GetStockObject(WHITE_BRUSH)



to

Code Select Expand



  Wc.hbrBackground   = (HBRUSH)GetStockObject(WHITE_BRUSH)



Without the cast, this error occurs

Code Select Expand



Bcxedit.cpp(497): error C2440: '=': cannot convert from 'HGDIOBJ' to 'HBRUSH'
Bcxedit.cpp(497): note: Conversion from 'void*' to pointer to non-'void' requires an explicit cast



[MrBcx]

JC -

I include the attached manifest in all my GUI builds. 

It ain't perfect but it's perfect enough for me.

[Robert]

Thanks for the report JC


BCX_OLEPICTURE needs an update

Change

if(Msg == WM_HSCROLL || WM_VSCROLL || WM_SIZE)

to

if ( Msg==WM_HSCROLL || Msg==WM_VSCROLL || Msg==WM_SIZE )


Plus your updates:

DWORD        dwFileSize;
DWORD        dwBytesRead;


These will be in 761.

I prefer ULONG in BCX, and unsigned long in C,  instead of DWORD. I always have to look up "DWORD" because I can never remember what it means. Here's the definition

Code Select Expand



typedef unsigned long DWORD, *PDWORD, *LPDWORD;



taken from the Microsoft page at

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/262627d8-3418-4627-9218-4ffe110850b2

[MrBcx]

PowerBasic instilled that habit in me ( and many others ) with its excessive use of DWORD for seemingly everything.

[Robert]

PowerBasic instilled that habit in me ( and many others ) with its excessive use of DWORD for seemingly everything.

Definitely easier to type DWORD rather than unsigned long.

[jcfuller]

JC -

I include the attached manifest in all my GUI builds. 

It ain't perfect but it's perfect enough for me.

Kevin,
  The manifest did nothing for me. Still looks the same.

I compiled your Embed_YT code (really cool) without any manifest and it looked and played great!

James

[MrBcx]

Yeah ... the effects of the manifest are better seen on windows with label, buttons, textboxes, etc ...