Mint: Listbox wrongly filled with data

The code below when executed on Linux Mint 18.1 (up to date !) from 2015r1 add one Row (only).
When running the application created on El Capitan (up to date), it also add only one Row, but with tons of columns…

Go figure !

BTW: I forget to tell … the application runs fine on El Capitan and Windows… (10, XP some times ago).

DateBool = ParseDate(TF_Date_Start.Text,DateStart) DateBool = ParseDate(TF_Date_End.Text,DateEnd)

Now I know why I stopped using ParseDate (even if ParseDate is not at fault !).

BTW: I tested a different (fixed) way to fill the two dates and commented the two lines above, so the problem is definitively in ParseDate (or in the Linux locale…)

Just in case you want to know, the two pre-defined dates are: 26-10-1985 and 25-10-1986.
The generated lines received the correct dates. (I tested a periodicity of week and month)

Also: working code (but bad code; the dates are user defined not fixed as below…)

[code] DateStart = New Date
DateEnd = New Date

DateStart.Year = 1985
DateStart.Month = 10
DateStart.Day = 1

DateEnd.Year = 1995
DateEnd.Month = 10
DateEnd.Day = 1[/code]

I checked the Release Notes for ParseDate: no change since 2015r1.

I see no code there that adds rows to a listbox.

Greg:

the problem lies with the ParseDate line. Once I commented out these two lines and add the code above, the Listbox is correctly filled.

Now, if you think the used code can be important… [I fire Xojo and Copy it):

[code]Sub LB_Fill()
//
// POPULATES THE LISTBOX (May 17, 2015)
//
Dim DateStart As New Date
Dim DateEnd As New Date
Dim IssueStart As Integer // Allow to start a list with issue IssueStart
Dim LoopIdx As Integer // Loop Indice
Dim TimeStep As Integer
Dim LocRow As Integer
Dim Frequency As Integer // Time between two issues…

// Get the magazine issue start value
IssueStart = CDbl(TF_Issue_Number.Text)

// Set the Start and End dates
// BECAUSE THIS DOES NOT WORKS ON Linux…
// DateBool = ParseDate(TF_Date_Start.Text,DateStart)
// DateBool = ParseDate(TF_Date_End.Text,DateEnd)
//
// [2017-07-10] New code that works now…
DateStart.SQLDate = TF_Date_Start.Text // User set date
DateEnd.SQLDate = TF_Date_End.Text // User set date

// Set the TimeStep value
Frequency = PM_Frequency.ListIndex
If Frequency = -1 Then
// Issue an error message and stop here
MsgBox “An error occured” + EndOfLine + EndOfLine + “No Frequency have been set.”
Return
End If

// Clears the previous ListBox contents
LB.DeleteAllRows

For LoopIdx = 1 to 50000 // The end of loop set to 50000 is BAD !
LB.AddRow “” // Ad an empty Row
LocRow = LB.LastIndex // Get the just added Row #
LB.Cell(LocRow,0) = TF_Book_Name.Text + " " + Format(IssueStart,“0000”) // Add the Book name & issue #
LB.Cell(LocRow,2) = DateStart.SQLDate // Add the start date

IssueStart = IssueStart + 1 // Increase the matrix value

// Check the Year, Month and Day
If DateStart.Year = DateEnd.Year And DateStart.Month = DateEnd.Month And DateStart.Day = DateEnd.Day Then
  // Exits here
  Exit
End If
// A second check is mandatory to avoid errors…
If DateStart.TotalSeconds > DateEnd.TotalSeconds Then
  // Exits here
  Exit
End If

// Increase the date’s day value
'DateStart.Day = DateStart.Day + StepDays
Select Case Frequency
  
Case 0 // Weekly
  DateStart.Day = DateStart.Day + 7
  
Case 1 // Fortnightly
  DateStart.Day = DateStart.Day + 14
  
Case 2 // Monthly
  DateStart.Month = DateStart.Month + 1
  
Case 3 // Spring
  DateStart.Day   = 21
  DateStart.Month = 3
  
Case 4 // Summer
  DateStart.Day   = 21
  DateStart.Month = 6
  
Case 5 // Winter
  DateStart.Day   = 21
  DateStart.Month = 12
  
Case 6 // Fall
  DateStart.Day   = 21
  DateStart.Month = 9
  
Case 7 // Annual
  DateStart.Year = DateStart.Year + 1
  
Case 8 // Special
  TimeStep = -1
  
Else // Undefined: stop here
  MsgBox "An error occured" + EndOfLine + EndOfLine + "Frequency step error."
  Return
End Select

If UserCancelled Then Exit // To avoid 1, Infinite Loop…

Next
End Sub[/code]

ParseDate doesn’t work with SQL dates. It’s designed to parse dates in the format that the user has their system set to.

On those two likes where you were calling ParseDate, did you bother to look at the returned values? DateBool is False and the date variables are Nil. Honestly I’m surprised you weren’t getting a NilObjectException when you assigned LB.Cell(LocRow,2) = DateStart.SQLDate

Greg: thank you for your answer.

That was not working (and its brother):

DateBool = ParseDate(TF_Date_Start.Text,DateStart)

You are correct, I do not checked the Boolean returned value !
You are correct too for the NilObjectException in the case ParseDate returned Boolean is False (seems I do not tested heavily that part…)

Nota: a previous build (some days, weeks ? ago) only add one Row… While yesterday’s build add only one Row, but add other data in that very same Row: say (5 Columns * # of Row data) inside the same Row…
Only differences between the two builds are the Mint updates (there may be other differences like other running application or so.

The only strong explanation I can give is the passed date format (26-10-1985) <> from the Linux locale and ParseDate do not liked that. And since I do not had any crash / NilObjectException / infinite loop, etc. I think there is thing to explorate. This is just IMHO, your opinion can be different.

When I test a method like this one, I usually pass a wrong date, but it seems that I never do that.

BTW: I forgot (fortunately) how much I suffer during the development of this complex project… The top trouble was when I format the hard disk where the project resides… (and the last backup was a … pdf printed project 15 days prior the format / two or three month earlier backup I forgot on another hard disk… a test project of some kind)…
Function that worked fine (finalizd at my local McDonald’s) and that do not works anymore after a power off / on, back at home, and many, many other troubles (some are my fault, some are unknow… black cat ?)

Oh ! 6 O’Clock, the day light are coming slowly… Time to wake up (sorry, already done)… time to take a breakfirst !

I just conduct a small serie of tests and the date stored in my DateStart Date Class is… today’s date !

[code]DateBool = ParseDate(“1985-10-26”,DateStart)

// Then:
DateBool = ParseDate(“26-10-1985”,DateStart)

// At last, this one returns the correct (the one I passed) date:
DateBool = ParseDate(“10-26-1985”,DateStart)[/code]

Checked in the Debuger.

Seems that in the Mint 18.1 (up to date), the locale format is the US Date Format

Nota: I checked the returned Boolean value when I pass a bad formated Date to ParseDate, and yes, the value is False. But the passedvariable have today’s date thus no NilObjectException where you expected (so no warning to the user, the bad coded user: me).

Now, why I get my Columns filled with the contents of the Rows in my build application… I do not know.
I understand why I get only one Row in the running IDE: the loop runs only once (For LoopIdx = Today to Today [fake code] runs only once.)