xsharp.eu

That's due to using

accountService.GetRange(...)

The dot is used in X# for namespace names as Karl said, and also in order to address STATIC members of classes, for example Int32.MaxValue and Int32.Parse(), which use the MaxValue property and Parse() method of the class "Int32". In such cases, the first part of the expression, is a class name.

But in the case of the code above, "accountService" actually refers to a LOCAL (VAR) defined just above, not to the "AccountService" class. The error message says you need to use an object, because it sees you are using a dot and assumes you intended to use the AccountService class.

In order to fix this, just replace "." with ":", as in

accountService:GetRange(...)

and it should work.

Additionally, as Nick pointed out, most of the confusion here is because the same identifier name is used for a local and a class name. I'd suggest using a different name for the local, for example

VAR oAccServ := AccountSevice{...}
and
VAR accounts := oAccServ:GetRange(...)

that should get the confusion away.

Edit: which, after reading Nick's post more carefully, it's exactly what he suggested already

Chris wrote: Edit: which, after reading Nick's post more carefully, it's exactly what he suggested already

With the crucial difference that Nick was guessing, whereas you know what you're talking about

Nick

Thanks Nick and Chris. What take you guys so long to have the blind helping the not so blind.

I realise it is not a good idea to use variable names similar to class names, was trying to mimic the MYOB example given on there website. Thought we did change initially the . to a : for GetRange() etc. <Grrr> when can we get a case sensitive compiler for cases like these? Keep on forgetting we back to case-insensitivity again.

Anyway thanks for jumping in.

Regards,

lumberjack wrote: <Grrr> when can we get a case sensitive compiler for cases like these?

God, no, please. Is it not enough to loose countless hours hunting dots? Do you really need and want that johan is not Johan is not JOhan is not JoHan???

Karl

Hi Karl,

FFF wrote:

lumberjack wrote: <Grrr> when can we get a case sensitive compiler for cases like these?

God, no, please. Is it not enough to loose countless hours hunting dots? Do you really need and want that johan is not Johan is not JOhan is not JoHan???

Ok let me rephrase. When can we get the option back of turning on case sensitivity...

Was one of the first things I did in the previous era...

CLASS Karl
PROTECT name, surname AS STRING
CONSTRUCTOR(n AS STRING, s AS STRING)
SELF:name := n
SELF:surname := s
RETURN
PROPERTY Name AS STRING GET name
PROPERTY Surname AS STRING GET surname
END CLASS

// Looks very need and tidy to me, except for the end user...
VAR oKarl := Karl{"kARL", "fALLER"}
? oKarl:Name
? oKarl:Surname

Johan, sorry, I had the impression it was just the original c# sample that was using those same named identifiers. In any case, X# does allow this (after much work in the compiler...), I just think it's more clear to use different names, especially for someone that is new to .Net and there already a lot of new things on .Net to learn about.

@Karl, case sensitivity would only be implemented as an option, same as in vulcan, so only those who like it would use it. It's very difficult implementing this option now though,as it requires tons of changes in the compiler. That's something maybe for later, after everything else is done.

@Nick, nah, you said it all perfectly actually, only missed the "." vs ":" thing, I noticed it just because I've come across similar issues a lot of times before!

Hi Chris,

Chris wrote:
Johan, sorry, I had the impression it was just the original c# sample that was using those same named identifiers. In any case, X# does allow this (after much work in the compiler...), I just think it's more clear to use different names, especially for someone that is new to .Net and there already a lot of new things on .Net to learn about.

No I used the exact "direct" translation not to confuse Tom, but I agree I will never use in my own code same names.
Just did not realise the .GetRange() slipped in again somewhere, and with my eyes as you know...

Anyway will show Tom tomorrow how to encapsulate his MYOB link in a Singleton class for use anywhere his application requires it.

Regards,

Sorry Johan,
what's the point? To let you use the same "name" for protect and property? <Duh>.
Helps you zilch, when you call it on an object oKarl and type by chance oKarl:name, expecting to read the access, but get the instance var back - without any warning or error.
Or, did you miss to write Property Name as String Get Proper(name)?
Again, fine, say nothing against, but has zero to do with using name and Name.
And what should happen, if you call oKarl: NAme? You'll get an error, but why should that be an error?

Karl

Hi Karl,

FFF wrote:
Sorry Johan, what's the point?

When it comes to coding I am a purist. If somebody sends me code, the first thing I will do is to remove all trailing spaces at the end of each line, then I will replace all space indents with tab indents. XIDE provides me with "White space" markers, I love it, will never see me working without it.

So in a non-case sensitive environment: Well from an end-user perspective all seems fine. However I too many times have seen code like this. It is a nightmare to fix bugs in somebody else's code. If you the only person working with the above it is fine. However, I talk from experience, too many times I had to take over projects to fix somebody else's mess. On top of that, X# to now a hobby. In the real life environment working with c# and Delphi apps that I inherited. We talking of over 5million lines of code. So to make sense of it, you need some standard and case-sensitivity gives that to some extend. In the .NET world, most examples are in c#, so for translation purposes case sensitivity ease the translation to X#.

I am not shooting you down, I just prefer to have the option of turning it on.

Thanks to All, I have it working.

METHOD OKButtonClick2() AS VOID

VAR oConfig := ApiConfiguration{"http://localhost:8080/accountright"}
VAR oCFService := CompanyFileService{oConfig}
VAR oCOFileList := oCFService:GetRange()

SELF:oTextBox:Text := "Company Files set"
VAR oCOFile := oCOFileList.FirstOrDefault({x => Version{x:ProductVersion} >= Version{"2013.3"}})
VAR oCredentials := CompanyFileCredentials{"Administrator","xxxxxxxxxxx"}
VAR oAccService := AccountService{oConfig}

VAR oAccList := oAccService:GetRange(oCOFile,NULL,oCredentials,NULL)

RETURN

As it appears, it doesn't matter if I use a dot or a colon:

VAR oAccList := oAccService:GetRange(oCOFile,NULL,oCredentials,NULL)
VAR oAccList := oAccService.GetRange(oCOFile,NULL,oCredentials,NULL)

First hurdle done

Thanks Again to ALL