is a 'field' but is used like a 'type'

[EWeiss]

Sorry aber was soll das jetzt. ?

Ich weiß was eine Klasse ein Feld und eine Methode ist.
Meinen Fehler immer wieder zu posten bringt einfach nichts.

Es ist mir bekannt das es falsch ist.
Und wie schon gesagt höchstwahrscheinlich so wie in Delphi/C++ nicht umsetzbar.
Wenn doch wie ist die Lösung. ?

gruss

[Sir Rufo]

Zitat:

Zitat von EWeiss (Beitrag 1297177)

Sorry aber was soll das jetzt. ?

Ich weiß was eine Klasse ein Feld und eine Methode ist.
Meinen Fehler immer wieder zu posten bringt einfach nichts.

Es ist mir bekannt das es falsch ist.
Und wie schon gesagt höchstwahrscheinlich so wie in Delphi/C++ nicht umsetzbar.
Wenn doch wie ist die Lösung. ?

gruss

Entschuldigung für die Störung, aber wenn du keine Antwort von mir möchtest, dann richte keine Frage an mich.

Zur Erinnerung (ist wohl schon zu lange her)

Zitat:

Zitat von EWeiss (Beitrag 1297127)

Zitat:

Zitat von Sir Rufo (Beitrag 1297125)

Weil du ein Feld genauso benannt hast wie einen Typ kommt dieser Fehler.

Mach das nicht und der Fehler geht weg.

Die einfachste Lösung ist ja wohl dem Feld einen anderen Namen zu geben

Welchen Feld ?

PS: Keine weitere Störungen meinerseits auf diesem Kanal ... over and out :roll:

[jfheins]

Die beste Lösung wäre wohl:

Zitat:

Zitat von Dejan Vu (Beitrag 1297118)

Du kannst am Anfang der Datei zwar 'using HTags = IntPtr;' schreiben, aber das gilt nur für die Datei.

Das musst du dann eben in jeder Datei schreiben. Alternativ geht ja immer noch:

Zitat:

Zitat von Dejan Vu (Beitrag 1297118)

Verwende einfach IntPtr statt HTags.

Das sind jetzt zwei Wege, die relativ gut sind, und funktionieren sollten. Dass man einen Pointer noch typedef'd, damit man das richtige übergibt, ist eben typisch C++ und weniger C#. (Ein typedef Pointer ist eben immer noch ein Pointer und da könnte immer noch quasi alles dahinter stecken.)

[Dejan Vu]

Die beste Lösung wäre einfach, keine Synonyme für Typen zu verwenden. Das verwirrt doch nur.

[EWeiss]

Zitat:

Zitat von Dejan Vu (Beitrag 1297180)

Die beste Lösung wäre einfach, keine Synonyme für Typen zu verwenden. Das verwirrt doch nur.

Die Fremd DLL ist in Delphi geschrieben und da machen die meisten Leute das so zumindest wie ich das so sehe.

Ich wollte halt die API so auslegen wie es in C++/Delphi ist, geht aber wohl nicht.
Ist halt nicht überall Konform abhängig von der Developer Sprache halt.

Ich habe es nun mit IntPtr gemacht.

Zitat:

PS: Keine weitere Störungen meinerseits auf diesem Kanal ... over and out

Na da kann man nichts machen.. Ist halt so wie es ist.

gruss

[Sailor]

C-Sprachen sind case-sensitive, d.h. HTAGS != HTags

[EWeiss]

Zitat:

Zitat von Sailor (Beitrag 1297188)

C-Sprachen sind case-sensitive, d.h. HTAGS != HTags

Ist mir klar ;)
Hat aber nichts mit meinem Problem zu tun.

gruss

[Aviator]

Was Sir Rufo meinte ist, dass du eine Variable (bzw. ein Feld) in der Klasse vom Typ IntPtr mit dem Namen HTags erstellt.
Die Funktion sollte aber den Typ HTAGS zurückgeben. Deshalb wohl auch die Anmerkung von Sailor.

Zitat:

Zitat von Sailor (Beitrag 1297188)

C-Sprachen sind case-sensitive, d.h. HTAGS != HTags

Wenn du deine Funktion so deklarieren würdest, wäre es was anderes und würde vielleicht auch funktionieren.

Code:

public static extern HTAGS TagsLibrary_Create();

Man beachte das groß geschriebene HTAGS. Aber schlag mich bitte nicht, wenn das nicht so funktioniert wie gewünscht. Bin auch kein C#/C++ Profi. Habs mir nur mal für ein kleineres Projekt angesehen.

Dein HTAGS Typ solltest du dir dann so einbauen können.

Code:

typedef IntPtr HTAGS

Stimmt, in C# gibt es ja gar kein Typdef :shock:

Vielleicht hilft es ja trotzdem weiter. :roll:

[EWeiss]

Zitat:

Die Funktion sollte aber den Typ HTAGS zurückgeben. Deshalb wohl auch die Anmerkung von Sailor.

NÖ.
Sie muss identisch mit dem Definierten Name sein. (Groß und Kleinschreibung beachtend)
Wenn als

Code:

IntPtr HtAgS = IntPtr.Zero;

definiert muss sie auch in folge so benannt werden.
Aber das merkt der Compiler da muss man sich selbst nicht drum kümmern.

Zitat:

Aber schlag mich bitte nicht, wenn das nicht so funktioniert wie gewünscht.

Warum sollte ich :)

Code:

public static extern HTAGS TagsLibrary_Create();

Genau so hab ich es gemacht.

Code:

IntPtr HTags = IntPtr.Zero;
public static extern HTags TagsLibrary_Create();

HTags = HTags
HTAGS = HTAGS

HTAGS = HTags geht nicht.. Was ich aber schon sagte (Ist mir bekannt)


gruss

[EWeiss]

Letztendlich habe ich die Lösung dann doch selbst noch erarbeitet (nicht aus dem Internet)

Code:

  [Serializable, StructLayout(LayoutKind.Sequential)]
  public struct HTAGS
  {
    private IntPtr _htags;

    public IntPtr HTags
    {

      get { return _htags; }

      set { _htags = value; }

    }

  }

Jetzt geht das!

Code:

    //TagsLibrary_Create
    [DllImport("TagsLib.dll", EntryPoint = "TagsLibrary_Create", CharSet = CharSet.Auto)]
    public static extern HTAGS TagsLibrary_Create();

und das! (Darum ging es mir.. Die API gleich zu halten mit den Aufruf Konventionen.

Code:

    //TagsLibrary_Free
    [return: MarshalAs(UnmanagedType.Bool)]
    [DllImport("TagsLib.dll", EntryPoint = "TagsLibrary_Free", CharSet = CharSet.Auto)]
    public static extern bool TagsLibrary_Free(HTAGS Tags);

in der Anwendung wird dann einmalig HTAGS definiert.

Code:

Dim hTags As HTAGS

Code:

hTags = TagsLib.TagsLibrary_Create()

If TagsLib.TagsLibrary_Free(hTags) Then
    MessageBox.Show("Is Free")
End If

In Delphi ist der Aufruf wie folgt!

Delphi-Quellcode:

t_TagsLibrary_Free = function (Tags: HTags): LongBool; {$IFDEF MSWINDOWS}stdcall{$ELSE}cdecl{$ENDIF};

Und genau diese Art des Aufrufs wollte ich beibehalten Tags: HTags
Deshalb schreibe ich die Lib (Wrapper in C#) damit Developer mit VB_NET sich mit der API nicht rumquälen müssen.


gruss