Extending the date range of the date gadget?

[Fangbeast]

I don't really want to hack my forms or my code after spending all this time designing them with the VISUAL designer (too damned tired most days) and as MSDN tells me that windows *should* be able to handle dates all the way down to 1603, I'd like to know if there is any way to extend the date range of PB's dategadget beyond the 1970 limit?

Many of the people I deal with have birthdays 30 to 40 years before (1970) that!!! And I was thinking of writing a simple genealogy database and once again I hit the date limit.

Regards all.

[horst]

Have a look at DateCount at my PureBasic Corner:

http://home.mnet-online.de/horst.muc/pb/

.. and check out my Date Reminder program in the Windows section...

[freak]

The Problem here is not with the Gadget, but with PB's Date library.
The Date lib uses the unix timestamp format, which ranges only from 1970 to 2030.

If you use the Api to get and set the date, you can go back to 1753 if you want.
What you will have to deal with is the SYSTEMTIME structure. It is quite simple,
it has one field for each part of the date:

Code: Select all

Structure SYSTEMTIME
  wYear.w
  wMonth.w
  wDayOfWeek.w
  wDay.w
  wHour.w
  wMinute.w
  wSecond.w
  wMilliseconds.w
EndStructure

Now getting and setting the dates in the DateGadget is quite easy:

Code: Select all

#DTM_GETSYSTEMTIME = $1001
#DTM_SETSYSTEMTIME = $1002
#GDT_VALID = 0

; Get Date:
;
SendMessage_(GadgetID(#YourGadget), #DTM_GETSYSTEMTIME, 0, @CurrentDate.SYSTEMTIME)

; Set Date:
;
SendMessage_(GadgetID(#YourGadget), #DTM_SETSYSTEMTIME, #GDT_VALID, @NewDate.SYSTEMTIME)

Just do not use the Date library for any of these dates, as this is what is limited to 1970.

[Fangbeast]

Fred was kind enough to email me back with an explanation of the problem which I accept and Horst pointed me to his code to look at with those very structures in it. I've fixed up the code thanks to him and released a fixed version of Portable SQLite address book.

It's hard to live brainless like me

[GeoTrail]

I wonder if there will be an update to the date library anytime soon...

[byo]

Please update this range as this is the only thing that is keeping me from converting my Delphi code to Purebasic (almost identical control).

[Fangbeast]

Fred explained to me that it isn't a simple library fix, it's a 'fix' that would require work at the heart of the compiler, major rework. (This is how I remember the email, I could be wrong)

And to be honest, I agree with him that for how few of us need dates to go that far back, it is certainly not worth the effort that it would take to just please us.

With Freak's examples and Horst's code, I turned them into re-useable routines and solved my problem.

And; if you own purevision designer; it has the facility to visually include an API date gadget with extended range so you have loads of choices.

If you ask Gnozal; the hardest working code out-putterer I know, he might add one in for you as well.

You could ask Bericko to include one in the official visual designer as well.

Byo, there is nothing stopping you from converting your code at all.

[Fangbeast]

Minor correct (sadly). The API date gadget seems to have gone missing from the current purevision.

[byo]

I see. Thank you for your advices.
Maybe I should search a little more for a solution.
I just thought that the DateGadget and the inner date functions could someday be synchonized without a lot of work. But I can live without it if ther are so many workarounds. Thanks for letting me know where to look.

[byo]

But the problem I have is with years after 2037/2038, not before.

freak's example did it for me. But how on Linux?

[Fangbeast]

You may have to ask Freak that. I have the funny feeling that the maximum date range of the library may be based on maximum ms date range.

/me wonders how far system bios goes too...

P.s. My home inventory and address book programs use dates based on Freak's example and Horst's code and they work great.

I have also asked the author of purevision if he could put the old api date back in but he seems to be busy these days and I don't know if he has the time.

If you use Gnozal's visual designer, ask him to put one in as his designer is quite extendible. Then you would not have to hack forms after design.

[Trond]

Fred explained to me that it isn't a simple library fix, it's a 'fix' that would require work at the heart of the compiler, major rework. (This is how I remember the email, I could be wrong)

But that was before the quad engine. If the date was stored in a quad instead of a long it would "only" be a library rewrite, not a change in the compiler.

Alternatively, the library could use numbered "date objects" (like gadgets) instead of passing the actual dates around. That would slow everything down, but it would be possible without a change to the compiler, and could allow for any date range.

[Fangbeast]

I wouldn't know, I never asked him since I have a working solution and am no longer interested in having it changed.

If the code works well, I see no need to change pb to suit me.

Unless some kind soul want to write a visual designer that supports all pb gadgets with all possible options. Then I would change all my working code (at major risk) to use this designer.

MrMatt, hurry up with woken will you???? (Pant, dribble, drool, lust)

[MachineCode]

Fred was kind enough to email me back with an explanation of the problem which I accept

Do you mean there's a valid reason why 1970-2038 are the only years available? What did Fred say?

[c4s]

Fred was kind enough to email me back with an explanation of the problem which I accept

Do you mean there's a valid reason why 1970-2038 are the only years available? What did Fred say?

If you sum up every second from 1970 on, a LONG variable will be filled in 2038.