Compiler treats namespace as a static property error?

I have this code:

   raise new InvalidOperationException( GuardianAutoCompleteBox.Properties.Resources.AutoComplete_OnSearchTextPropertyChanged_InvalidWrite)

which causes this error:

error E43: No static member "Properties" on type "GuardianAutoCompleteBox"

And, it is correct. There isn’t such a static member, but there IS a namespace. In the Resources.Designer.pas:

   namespace GuardianAutoCompleteBox.Properties;
    
    interface
uses
    System;
    
type
    /// <summary>
    ///   A strongly-typed resource class, for looking up localized strings, etc.
    /// </summary>
    // This class was auto-generated by the StronglyTypedResourceBuilder
    // class via a tool like ResGen or Visual Studio.
    // To add or remove a member, edit your .ResX file then rerun ResGen
    // with the /str option, or rebuild your VS project.
    [System.CodeDom.Compiler.GeneratedCodeAttribute('System.Resources.Tools.StronglyTypedResourceBuilder', '4.0.0.0')]
    [System.Diagnostics.DebuggerNonUserCodeAttribute]
    [System.Runtime.CompilerServices.CompilerGeneratedAttribute]
    Resources = class

Any suggestions how to get around this?

… time passes …

I was able to put a GuardianAutoCompleteBox.Properties in the uses and that got by the problem, but I think one still SHOULD be able to use GuardianAutoCompleteBox.Properties.Resources and it should realize that there IS a namespace that would work for Resources.

Do you maybe also have a type called GuardianAutoCompleteBox? that is in scope? If so, that can confuse the compiler. It’s a had ice a to have types and namespaces with the same name.

hth,
marc

This code is a copy of the toolkit AutoCompleteBox and all the organization of files and names and namespaces is as it was originally, except I called the class GuardianAutoCompleteBox.

The compiler wasn’t confused in my old Delphi Prism, FWIW.

Also I just checked and this namespace naming is apparently very common. I made a new WPF application and it was called WPFApplication20. Then I added a resource string. Now there is a file Resources.Designer.pas that has a generated namespace of namespace WPFApplication20.Properties.

So I think ANY app that has resources will have a namespace like that and I think the way to reference it would be through WPFApplication20.Properties.Resources.

A class in scope will always have precedence over a root namespace. If the earlier compiler didn’t do this it had a bug.

right, but there should be no class called WPFApplication20.

ck,

So, I guess I can understand that there is a rule that says that the class should have precedence, but then if it determines that the class doesn’t have a Properties static member, shouldn’t it look to see if there IS a namespace that has a Properties thingee?

No :wink:

No. What happens when it looks for an identifier is first it tries the current namespace. If there’s a type OR subnamespace with that name, that one is picked. Then it moves to the parent namespace (if any) and does the whole process over, until it reaches the root namespace.

It finds GuardianAutoCompleteBox and determines that means, the class. It then goes on compiling under the assumption that it is the class. and expects class members. It doesn;t go back and rethink what GuardianAutoCompleteBox could mean — it’s well-defined what GuardianAutoCompleteBox means, always.

ck,

I think your statement is ambiguous. Where you said “If there’s a type OR subnamespace with that name, that one is picked”.

If there is a type AND subnamespace, then “that one” is ambiguous, no? I think that is what Marc is saying, if it finds the class, it doesn’t look for the subnamespace. If I’m understanding correctly.

Now I’m wondering, since Marc said it was a bad idea to have a Namespace and Type using same names, maybe there should be a compiler warning on that very fact.

I realize that the error message that got generated sort of implies that situation, but perhaps it warrants its own warning. I can’t see my way through the whole syntax, but if the Namespace were Whatever.WhateverElse and the Whatever Class HAD a WhateverElse property, the compiler might have been happy, but the code might not be doing what was the intent of the author.

That can’t happen at the same level. Once it finds something thats the namespace or type it picks.