GetMonth error?

According to documentation: The returned value is between 1 and 12.
Bu the following code:

program ErrProject;
var ID1, ID2, DateTime: integer;
begin
  ClearForm;
  SetFormTitle('Get Month Error');
  ShowForm;
  DateTime:=getCurrentTime;
  ID1 := FormAddDateField('Date1: ', DF_DATE);
  FormSetDate(ID1, DateTime);
  ID2 := FormAddString ('Date2: ' + GetDay(DateTime) + '.' + GetMonth(DateTime));
  delay(10000);
end.

… generates two different dates on the screen (today): Date1: 28 Oct 2010 and Date2: 28.9

The month is zero-based in the Java platform when using java.util.Calendar.get (http://download.oracle.com/javase/1.5.0/docs/api/java/util/Calendar.html#MONTH) as MIDletPascal uses, so the documentation is wrong.

So, being curious why is documented wrong, inspecting the code I found a non-sense +0 to the returned value (in stdpas.c:1627 you can find the instructions iconst_0 / add after the call to Calendar.get), so may be in an old version of MIDletPascal (maybe in the 1.x series, since the MP 2.02 source code has that +0) it was returning in the 1..12 range, and it was documented that way. But, being counterintuitive when coding for the Java platform, in some point it was changed or reverted back the funcionality to return in a zero-based range, forgetting to reflect that change or reversion in the documentation. But this is just my guess on the evidence.

In any case, let's comment by the way that if a new behaviour change in that function takes place to return in the 1..12 range (which is pretty simple as flipping that iconst_0 to an iconst_1), it will have a strong destructive impact on backward compatibility. So, there is no chance to get a value as expressed wrong in the documentation.

Let's conclude that I will fix the documentation for the next release.

Thanks for your report!

There are errors in examples also:

  var choiceGroupID: integer;
      NY, LA: integer;
  begin
    showForm;
    choiceGroupID := formAddChoice('Where do you live?', CF_EXC_LUSIVE_);
    NY := choiceAppendStringImage(choiceGroupID, 'New York', loadImage('/NY.png'));
    LA := choiceAppendStringImage(choiceGroupID, 'Los Angeles', loadImage('/LA.png'));
    if choiceIsSelected(choiceGroupID, NY) then
      formAddString('New York');
    else
      formAddString('Los Angeles');
  end.

… and others.

Right, it should read CH_EXCLUSIVE. There are 3 files where that constant is named incorrectly: mr_choiceisselected.htm, mr_choiceappendstringimage.htm and mr_choiceappendstring.htm.

It will be fixed for the MP 3.3 ALPHA.

Thanks for your report!

Missing letter in help:

**choiceIsSelected

function choiceIsSe>>l<<ected(choiceID: integer; itemIndex:integer):boolean;**

Will be fixed in the next release. Thanks for pointing that out.

bits.mpsrc(1739): E429 identifier 'font_style_underline' is not constant, function or variable name

The constant is FONT_STYLE_UNDERLINED, there is a typo in the documentation or may be the constant name was changed somewhere between 1.x and 2.x versions.
Adjust the constant name in your code and it will compile.
In any case I will fix the documentation, expect it in the next release.
Thanks for pointing that out!

Isn't it a  little bit strange that the following code doesn't generate syntax error (missing semicolons at operator end):

…
  if Trns.TrType=TPayment then
    Accs.Payments:=Accs.Payments-Trns.TrAmount
  if Trns.TrType=TCash then
    Accs.Cash:=Accs.Cash-Trns.TrAmount
…

… and also this (extra semicolon at the end of then part):

    if Trns.TrType=TPl then ID:=FormAddString('Pl'+CR);
      else ID:=FormAddString(CR);

Yes, I'm aware about this inconsistencies and do totally agree with you.

But, besides the Pascal language rules, in the MP dialect this two things seem to be "legal" from the beginning, just check older versions like the 2.0 one. The fact, controversial or not, is that if I change it now, there will be broken code, betraying the goal of the 3.x series that implies to mantain backward compatibility to get an smooth upgrade from older version and that way (at least try to) deprecate them from the daily use. Also, that kind of "big-impact" changes, in my opinion, should be made on major releases, with the proper documentation of course. That's why I only focused all this time on adding new things to the syntax (infinite loop, exit keyword, etc) instead of modifying already existent things (so you can compile in 3.0 exactly the same than in 2.0).

Resuming, I agree this should be changed for the 4.0 and that way adjust the MP dialect to the common Pascal rules. And for the 3.x series I think I can add a note on this to the "The MIDletPascal Dialect \ Introduction \ Differences with the standard Pascal language" section.

Thanks for your report!