Hello José,
With the last AFXnova, load template ex_ddt_button01.bas and compile :
warning on DDT.inc, line 404 : passing different pointer type at parameter 11 (pwndproc)
This not appear before.
On Tiko 1.2 its impossible to copy compiler result on the clipboard... Its a mess...
@jose , @docroger
edit: using the DDT.inc and CGraphCTX.inc (250723_19:02 which were changed in the related areas versus version 250724_04:59)
could be compiled successfully
EX_DDT_Button_01 -- w. AfxNova-DDT - Start - ....,\EX_DDT_Button_01.bas
EX_DDT_Button_01 -- w. AfxNova-DDT - End -
BUT The "NEW AfxNova" version 250724_04:59 has the same effect ( as @docroger)
b.r. hajubu
tested ...
for __File__ : EX_DDT_Button_01.bas and
for __File__ : EX_DDT_InputBox.bas and
for __File__ : EX_DDT_Button_Ownerdraw_02 and
.... ( no other tested), as it seems to be systematically.
copy from "tiko 'compiler log file'
and source line 404 ('compiler results') - View Output Window (Menu) to activate
pointing to
IF pDlg THEN RETURN pDlg->ControlAdd(wszClassName, cId, wszTitle, x, y, cx, cy, dwStyle, dwExStyle, lpParam, pCallbackProc)
{/color]
...\inc\AfxNova\DDT.inc([color=yellow]404[/color]) warning 3(2):
... Passing different pointer types, at parameter 11 (pWndProc) of CONTROLADD()
source hit ---->
PRIVATE FUNCTION ControlAdd (BYREF wszClassName AS WSTRING, BYVAL hDlg AS HWND, BYVAL cId AS LONG_PTR = 0, _
BYREF wszTitle AS WSTRING = "", BYVAL x AS LONG = 0, BYVAL y AS LONG = 0, BYVAL cx AS LONG = 0, BYVAL cy AS LONG = 0, _
BYVAL dwStyle AS LONG = -1, BYVAL dwExStyle AS LONG = -1, BYVAL lpParam AS LONG_PTR = 0, _
BYVAL pCallbackProc AS WNDPROC = NULL) AS HWND
DIM pDlg AS CDialog PTR = GetCDialogPtr(hDlg)
IF pDlg THEN RETURN pDlg->ControlAdd(wszClassName, cId, wszTitle, x, y, cx, cy, dwStyle, dwExStyle, lpParam, pCallbackProc)
END FUNCTION
> Passing different pointer types, at parameter 11 (pWndProc) of CONTROLADD()
You must be using an outdated DDT.INC, because the new one does not use pWndProc.
I changed
PRIVATE FUNCTION ControlAdd (BYREF wszClassName AS WSTRING, BYVAL hDlg AS HWND, BYVAL cId AS LONG_PTR = 0, _
BYREF wszTitle AS WSTRING = "", BYVAL x AS LONG = 0, BYVAL y AS LONG = 0, BYVAL cx AS LONG = 0, BYVAL cy AS LONG = 0, _
BYVAL dwStyle AS LONG = -1, BYVAL dwExStyle AS LONG = -1, BYVAL lpParam AS LONG_PTR = 0, _
BYVAL pWndProc AS SUBCLASSPROC = NULL, BYVAL uIdSubclass AS UINT_PTR = &HFFFFFFFF, _
BYVAL dwRefData AS DWORD_PTR = NULL) AS HWND
that uses pWndProc, to:
PRIVATE FUNCTION ControlAdd (BYREF wszClassName AS WSTRING, BYVAL hDlg AS HWND, BYVAL cId AS LONG_PTR = 0, _
BYREF wszTitle AS WSTRING = "", BYVAL x AS LONG = 0, BYVAL y AS LONG = 0, BYVAL cx AS LONG = 0, BYVAL cy AS LONG = 0, _
BYVAL dwStyle AS LONG = -1, BYVAL dwExStyle AS LONG = -1, BYVAL lpParam AS LONG_PTR = 0, _
BYVAL pCallbackProc AS WNDPROC = NULL) AS HWND
The reason is that pWndProc was used to optionally subclass the control. But the old way of subclassing is not recommended and the new one, using SetWindowSubclass, can be used directly.
The new optional pCallbackProc parameter is reserved for future development.
hi Jose,
repeated test BUT no luck !! -- There must be a different reason as you thought.
Did you see my remark, as I tested it also against the version of 25-07-23 07:02 PM
which ended successfully !.
I always make my setup with your AfxNova in toto , found in your repository master
The before used DDT.inc (25-07-24 04:59 AM) had the same checksum, size and content !
Summary :
:: had the same error with DDT.inc last "Github-master" download for safety again (@now)
Name Extension Size download in MESZ (-> i.e. EDT +5)
AfxNova-main.zip 2.992.018 24.07.2025 20:25:08
time stamp of folder -> inside the with valid upload time (EDT)
AfxNova-main <folder> 24.07.2025 10:24:04
Name: AfxNova-main.zip - Size: 2992018 Bytes : 2921 KiB with
MD5: 4ffdf71b1f5f172c2cfd3d8b70cda3b5
SHA256: 988f015648c579fc5305565dab10062be05bac49bbe2ed62cb329d4bff762726
DDT.inc
Name: DDT.inc - Size: 180268 bytes : 176 KiB
MD5: 7dc88def333c46d8100d5e7853ac4550
SHA256: 1327e0983f149de0a32db86d82fbf82e50ba6f41af055a98c220350c18d77f3b
Name Extension Size Attributes Modified
DDT.inc inc 180.268 ---A-------- 24.07.2025 04:59:03
{/code]
tiko - compiler results
[code]
404 - DDT Dialog - Input - w.AfxNova - DDT --
warning 3(2): Passing different pointer types, at parameter 11 (pWndProc) of CONTROLADDO
- #print ------- DDT Dialog ---- end
P.S. Why do we have or need two files of "same/similar" name ( see capital letter 'Plus' and the minor 'plus' (win cannot differentiate those names)
AfxNova/AfxGdiPlus.inc and AfyNova/AfxGdiplus.inc
> P.S. Why do we have or need two files of "same/similar" name ( see capital letter 'Plus' and the minor 'plus' (win cannot differentiate those names)
Probably I modified the name and GitHub is case sensitive.
I have reuploaded AfxGdiPlus.bi and .inc. If it does not work, I will delete all the files and reupload them from my computer, that are working.
These are the files that I'm using.
Hi , Jose
Thanks, for the download - pack - it works in the first row !
just have started two setups : each agains the 'bad-pack' vs 'good-pack'
a) totally new with tiko120 with your inc/AfxNova
and
b) a trial setup with tiko120 with inc/afx , inc/afx2 and your inc/AfxNova folder -
BOTH setups are working fine with your download and DON'T work with the Github upload time 2025-07-24_10:24 EDT )
...the actual Github version 2025-07-24_13:25 EDT will be tested as next ---
I see the differences in the single files checksums and also the additional inc-files in the folder.
Next : Trying to find the real reason for the bad-luck situation.
see more Jose response (#7)
--------Findings------
Repo_AfxNova :: CDialog.inc size 189.010 with upload time 24.07.2025 22:25:08 MESZ
contained outdated references :: "SUBCLASSPROC" (line 205,526,527,528 and in line 876-885)
info : to CDialog.inc 188.276 23.07.2025 22:03:07 MESZ in JoRo-pack was clean (line 205,525 other ref'es does not exist)
conclusion : Github repo needs to validated ( cleaned , new check-in)
Hoping that will save other to get in trouble - like me.
Thanks for the fast reply.
b.r. Hajubu
As I have been constantly updating the repository with modified versions, maybe something has gone wrong. I will remove all the files and upload updated ones.
I started running into this same problem developing Tiko Editor. My Main branch would always have modified files that would sometimes cause conflicts, etc.
I changed to using a "development" branch and when I was ready to issue a formal release, I would merge that development branch into the main branch.
Extremely easy to do with Github via the "Github Desktop" standalone application. Just go under Repository / New Branch and create a branch. Do all your work in that new branch. When ready to merge, it creates a Pull Request that you simply approve and voila, all done.
This approach has saved me from a lot of synchronization problems and anxiety of not knowing if my Main branch code was in a usable state.
I'm having a problem with the graphikc control as child of a dialog. All works except the features of making it resizable, stretchable or scrollable. Apparently, the Windows dialog engine uses many workarounds to get the Windows standard controls to work fine, but custom controls are another story. Things that with SDK windows are very easy, with dialogs became impossible, like embedding a progress bar into a section of a a status bar or embedding a toolbar into a rebar. As soon as you use custom controls, there are repainting problems. Code in the graphic control that is working flawless if the parent is a CWindow, doesn't work fine or at all if the parent is a dialog. Obviously, dialogs weren't designed to work as a main window.
Therefore, I will try another approach: to make a DDT wrapper that uses CWindow instead of the dialog engine. The major change regarding usability will be in the callback procedure. SDK windows use WM_CREATE instead of WM_INITDIALOG and the call to DefWindowProc is mandatory. Other major change will be that we will always using pixels, not dialog units, which I think that it is a good thing, since the human mind finds easier to work with pixels.
What do you think?
Hi José,
Fine for me CWindow instead of cdialog.
I will study the examples for adapt my code.
With Afxnova you give here, i dont have warnings from compiler.
I put my powerbasic code conversion on standby.
I have tried to start a DDT wrapper on top of CWindow and it does not work. The problem with procedural wrappers is that they don't provide encapsulation, so where you keep the data? In shared variables? No way.
Anyway, the syntax to use CWindow is as easy as DDT. It wlll take little time to get used to it.
Here is a preliminar documentation of CWindow, that I will revise and expand.
https://github.com/JoseRoca/AfxNova/blob/main/docs/Windows%20GUI%20/CWindow%20Class.md
I have already written many templates for CWindow.
https://github.com/JoseRoca/AfxNova/tree/main/SDK%20Templates
I have removed the files from the AfxNova folder in the GitHub repository and uploaded the ones that I'm using in my computer.
Hi Jose, Hi Paul
just picked some valid sample cw's and ddt's - all running fine ! Thumps-up !
Thanks for taking care for the "bubbles".
b.r. Hajubu
I have ported to AfxNova CImageCtx, and image control similar to VB6 Picture Box. It uses GDI+ and can be used to display pictures inside a "form". I have attached a demo that demonstrates some things of interest that may be unfamiliar to you, like anchor resizing (we anchor the controls and we don't need to worry about resizing the controls in WM_SIZE), the use of the IFileOpenDialog and the use of function pointers. Just trying to be a little didactic. Instead of IFileOpenDialog you can use the old AfxOpenFileDialog function or the VB6-like OpenFileDialog (in OpenSaveFile.inc). OpenFileDialog allows to center the dialog using a hook, like DISPLAY OPEN FILE does, but here is optional.
Documentation: https://github.com/JoseRoca/AfxNova/blob/main/docs/Graphics%20/CImageCtx%20Class.md
The lovers of coloured buttons, will enjoy CXpButton. It allows to set colors for everything. https://github.com/JoseRoca/WinFBX/blob/master/docs/Windows%20GUI/CXpButton%20Class.md
And also up to three images for normal, hot and disabled states. Also demonstrates how to implement a custom control using a class.
There is also a masked edit control:
https://github.com/JoseRoca/WinFBX/blob/master/docs/Windows%20GUI/CMaskedEdit%20Class.md