Hello José,
There is a powerfull fonction DateDiff on Cpowertime.inc (on AFX dir) that is commented.
Is there any problem ?
I have decommented and that compile ok... But there is minimal differences with the same function used in PowerBasic.
Is there any bug in it ?
I have transferred one app from Powerbasic to Freebasic x64, with DDT.inc. This is cool.
Have a good day...
Yes, it failed in some cases. I have a new procedure that works correctly:
' ========================================================================================
' The date part of the internal CPowerTime object is compared to the date part of the
' specified external CPowerTime object. The time-of-day part of each is ignored. The
' difference is assigned to the parameter variables you provide. nSign is -1 if the internal
' value is smaller. nSign is 0 if the values are equal. nSign is +1 if the internal value
' is larger. The other parameters tell the difference as positive integer values. If
' parameters are invalid, GetLastError will return ERROR_INVALID_PARAMETER.
' Usage example:
' DIM cpt1 AS CPowerTime
' DIM cpt2 AS CPowerTime
' cpt1.NewDate(2019, 2, 2)
' cpt2.NewDate(1930, 12, 25)
' DIM AS LONG nSign, nYears, nMonths, nDays
' cpt1.DateDiff(cpt2, nSign, nYears, nMonths, nDays)
' print nSign, nYears, nMonths, nDays
' ========================================================================================
PRIVATE SUB CPowerTime.DateDiff (BYREF cpt AS CPowerTime, BYREF nSign AS LONG, BYREF nYears AS LONG, BYREF nMonths AS LONG, BYREF nDays AS LONG)
' // Check for valid parameters
IF VARPTR(nSign) = NULL OR VARPTR(nYears) = NULL OR VARPTR(nMonths) = NULL OR VARPTR(nDays) = NULL THEN
SetLastError(ERROR_INVALID_PARAMETER)
RETURN
END IF
' // Get components of internal and external CPowerTime
DIM y1 AS LONG = this.Year, m1 AS LONG = this.Month, d1 AS LONG = this.Day
DIM y2 AS LONG = cpt.Year, m2 AS LONG = cpt.Month, d2 AS LONG = cpt.Day
' // Determine sign
IF y1 > y2 OR (y1 = y2 AND m1 > m2) OR (y1 = y2 AND m1 = m2 AND d1 > d2) THEN
nSign = 1
ELSEIF y1 < y2 OR (y1 = y2 AND m1 < m2) OR (y1 = y2 AND m1 = m2 AND d1 < d2) THEN
nSign = -1
ELSE
nSign = 0 : nYears = 0 : nMonths = 0 : nDays = 0 : RETURN
END IF
' // Normalize so y1,m1,d1 is always the later date
IF nSign = -1 THEN SWAP y1, y2 : SWAP m1, m2 : SWAP d1, d2
' // Compute difference
nYears = y1 - y2
nMonths = m1 - m2
nDays = d1 - d2
IF nDays < 0 THEN
nMonths -= 1
DIM prevMonth AS LONG = m1 - 1
IF prevMonth < 1 THEN prevMonth = 12 : y1 -= 1
nDays += this.DaysInMonth(prevMonth, y1)
END IF
IF nMonths < 0 THEN
nYears -= 1
nMonths += 12
END IF
END SUB
' ========================================================================================
> I have transferred one app from Powerbasic to Freebasic x64, with DDT.inc. This is cool.
CDialog is an attempt to replicate PowerBasic's DDT engine. However, you seem to be the only interested in it. Nobody of the remaining DDT'ers seem interested.
I'm currently working in a new SDK framework, AfxNova, that will replace Afx.
See: https://github.com/JoseRoca/AfxNova
Eventually, I will incorporate CDialog and DDT.inc as an alternate option of the AfxNova framework.
Applications that use AFX will require changes to work with AfxNova, specially using DWSTRING instead of CWSTR and some string procedures. I'm developing AfxNova using the new Tiko editor by Paul Squires.
This new version is needed to modernize the framework to work with the problems imposed by the high resolution monitors. It requires Windows 10 or 11 because the new High DPI apis aren't available in older Windows versions.
Great, the new function Datediff give same result as in Powerbasic. Thanx.
For clarification :
For my powerbasic code, should i use DDT.inc, or Cdialog.inc ?
There is no Cdialog on afx nova...
DDT.inc will be deprecated ?
Not clear for me...
QuoteHowever, you seem to be the only interested in it. Nobody of the remaining DDT'ers seem interested.
For my new code i use Purebasic (wich each new version destroy old code), Lazarus (very good) or Delphi Community (very buggy).
I have old apps, that works in Powerbasic... I try to transfert them... I am an old coder...
> For my powerbasic code, should i use DDT.inc, or Cdialog.inc ?
You can use either CDialog.inc or DDT.inc. DDT.inc is just a proceudral wrapper to provide DDT-like syntax to CDialog, which is the one that does the work. CDialog is a class and you have to use the dotted syntax with it.
> There is no Cdialog on afx nova...
I'm finishing the integration. Just give me one day or two.
> DDT.inc will be deprecated ?
No. It will be integrated in AfxNova. What is deprecated is the namespace Afx2. I used it to avoid conflicts with Afx while I was working replicating the DDT engine.
In AfxNova you will have CWindow for SDK windows and CDialog/DDT for DDT like
dialogs. The other files will be shared with both. What you can't do is to mix Afx with AfxNova. Both can be used independently, but not mixed.
I have finished the integration of CDialog and DDT wrappers in AfxNova. You can now have SDK windows with CWindow and dialogs with CDialog. I also have uploaded many dialog templates.
However, the GUI is only the pretty face. I will adapt all the existing Afx classes to work with AfxNova. A recent addition is CMoney, that implements a currency data type compliable with TRANSACT-SQL. I will need it when I will update my ADO and ODBC classes to work with SQL Server Express Edition.
Hello José,
i have recompile my app (old powerbasic code translate to FB) with AFXnova : all is ok.
I have change the using DDT with using afxnova.
It is missing examples for graphics inside a dialog like in Powerbasic.
But i continue my research...
Good job. Very usefull. Thanx.
I have a graphic control that I will adapt to AfxNova soon. But first I have to adapt the GdiPlus classes. Contrarily to DDT's graphic control it uses DIBs and 32 bit, so there is not a 4 MB limitation and it can work with alpha-blended images. It natively supports GDI, GDI+ and OpenGL. I have future plans to see if I can add support for Direct2D and DirectWrite. It won't be easy, because Direct2D only works with the main window, not with child windows, but I intend to use a memory bitmap as a middle man, i.e. render the graphics to the memory bitmap and then BitBlt to the control's device context. In theory, it should work.
For a graphic window, FreeBasic does support it natively. The syntax would not be the same, but we can't have everything.
There is much code to adapt and update, so this is going to ve a hot summer (not pun intended). Fortunately, Tiko is allowing me to work faster than before. What takes more time is to test te code, write templates and write the documentation. It takes me much more time that coding.
With SDK you have the raw power. With dialogs there are limitations. For example, there is no way to have controls children of other controls. With SDK, if I want to have a progress bar embedded in a section of an status bar, there are no problems; with dialogs it is impossible. With SDK, if I want to have a toolbar embedded in a rebar, there are no problems; with dialogs there are repainting problems. And so on... Dialogs can be useful for many things, but they aren't suitable to work as the main application window.
Anyway, I was a little bored and thought that it was a good challenge to reverse engineer the DDT engine and replicate it. In the process, I have fixed some DDT quirks, added custom classes, anchor resizing and scrolling.
CWindow has also these featrues. You anchor the wanted controls and forget about resizing the controls in WM_SIZE. If you want to make a window scrollable, you only need to call the SetViewPort method. Adding colors to the main window background and the text and background of some controls like labels and text boxes is also easy.
All the PowerBasic's string functions have been replicated and a regular expressions engine is also avalable.
Contrarily to PowerBasic file statements, I provide classes to work with Unicode. FreeBasic supports to write and read unicode files, but it does not support unicode file names in Windows (with Linux they use utf-8).
There is a problem with FreeBasic's headers and 32-bit import libraries. The headers haven't been updated in ten years and many 32-bit import libraries are partially broken. So, if some code fails to compile with 32-bit, don't blame AfxNova and use 64-bit. The 32-bit headers for GDI+ are a very big mess, so I will ignore them and use the declares for the flat api. There should not be problems using the flat api and 64-bit (the import library for 32-bit is partially broken).
I think that we must start to forget 32-bit and use 64-bit always. After all, AfxNova and Tiko won't work in 32-bit only versions of Windows. It is as when we had to transition from 16-bit to 32-bit.
Ok for me, i compile for x64 with C backend, like in Purebasic.
On AFX nova, DDT templates, the ddt_button_ownerdraw_02.bas, the text is in chinese... encoding is utf16-BOM with tiko...
If i change encoding, i cant read the code.
Here is what i see in tiko... (begining)
'#TEMPLATE DDT Dialog with an ownerdraw button with an image
�⌀搀攀昀椀渀攀 开圀䤀一㌀㈀开圀䤀一一吀 ☀栀 㘀 ㈀ഀഀ
#include once "AfxNova/DDT.inc"
�唀匀䤀一䜀 䄀昀砀一漀瘀愀ഀഀ
�䐀䔀䌀䰀䄀刀䔀 䘀唀一䌀吀䤀伀一 眀圀椀渀䴀愀椀渀 ⠀䈀夀嘀䄀䰀 栀䤀渀猀琀愀渀挀攀 䄀匀 䠀䤀一匀吀䄀一䌀䔀Ⰰ 开ഀഀ
BYVAL hPrevInstance AS HINSTANCE, _
� 䈀夀嘀䄀䰀 瀀眀猀稀䌀洀搀䰀椀渀攀 䄀匀 圀匀吀刀䤀一䜀 倀吀刀Ⰰ 开ഀഀ
BYVAL nCmdShow AS LONG) AS LONG
Another little bug in templates...
ex_ddt_inputbox.bas : compiler error : afxinputbox not declared...
Missing : #include once "afxnova/cwindow.inc"
and compile fine...
> On AFX nova, DDT templates, the ddt_button_ownerdraw_02.bas, the text is in chinese... encoding is utf16-BOM with tiko...
GitHub does not like utf-16 encoded files. I have reuploaded it.
Quote from: docroger on July 20, 2025, 01:47:46 PMAnother little bug in templates...
ex_ddt_inputbox.bas : compiler error : afxinputbox not declared...
Missing : #include once "afxnova/cwindow.inc"
and compile fine...
Should be DialogInputBox. I have modified the template. Thanks for reporting it.
CWindow is not needed to work with dialogs.