error XS0118: 'byte *' is a element but is used like a VOSTRUCT/UNION
error XS0118: 'uint' is a type but is used like a VOSTRUCT/UNION
error XS0118: 'uint' is a type but is used like a VOSTRUCT/UNION
I have a error on this code (its a :
PROTECT DIM aBufList[MDPDF_MAXBUF] IS BYTE PTR // Buffer of pointers
PROTECT DIM aBufLen[MDPDF_MAXBUF] IS DWORD // Buffer of lengths
PROTECT DIM v_offsets[MDPDF_MAXOBJECT] IS DWORD //array of object offsets
what i have to change ?
And this warning is confusing me:
warning XS0060: Inconsistent accessibility: base class 'DBServer' is less accessible than class '_CryptServer'
And will this change when X# comes with own runtime?
warning MSB3270: Konflikt zwischen Prozessorarchitektur des Projekts "MSIL",
"VulcanVOWin32APILibrary", "x86". ecetera
The error messages are due to the keyword "IS" used for types like DWORD, BYTE PTR etc. IS is supposed to be used only in conjunction with (VO)STRUCT types, not with "normal" types. VO does allow it also here (my guess is that this is just a glitch), but x# doesn't, you just need to change IS to AS here.
About the inconsistent accessibility warning, see this simplified code:
INTERNAL CLASS InternalClass
EXPORT oIntObj AS InternalClass
In this sample, the PublicClass (that can be used from code outside of the library where it is defined) has a field (EXPORT) of a type that is not visibly outside. So you cannot properly and fully use PublicClass from outside, even though that class itself is visible, hence the warning.
METHOD TestMethod(o AS InternalClass) AS VOID
Again, this is a class that can be used from outside, and TestMethod() is also a public method which is also supposed to be callable from other libraries. But in fact it cannot be really used like that, because it needs a param of type InternalClass, which is only visible inside the defining assembly.
In order to avoid such warnings, you need to make both classes either public or INTERNAL. Or in the sample with the METHOD, you can make the method INTERNAL, so you specify that it is to be used only from code inside the same library.
Regarding the MSIL/x86 warning, that's because the vulcan dlls are 32bit only, so you need to set your app as 32 bit, too. To do that, you need to go to the Project Properties, Build page and set the target to x86.
Regarding the x# runtime, we will try to make it all AnyCPU, so it can be used with either 32 or 64 bit apps, but I am not sure if it will be possible to do all of it like that, especially the VOGUI classes I am sure will give some trouble. But for the libraries that it will be possible to do it, we'll make them AnyCPU.
I am honest, i dont understand the part with the classes.
i have just this little bit code and a Method to recycling records, for later i wanna maybe making more changes on the DBServer. This class is in a DLL and all other app using that class.
What is the change a i have to do so it works like before ?
CLASS _CryptServer INHERIT DbServer
//CLASS _CryptServer INHERIT SEFastServer
// constructor inserted by xPorter, remove superfluous arguments
That code that you posted should give no warnings at all, I think the compiler complained about something else. What line did the warning message report? Maybe you can zip the solution as a whole and send it to me to have a look?
Ah, I see what's happening, that's because you have 2 methods without an enclosing class:
METHOD WildSeek2( cToWildSeek, aCheckFields ) class DBServer
METHOD WildSeek( cToWildSeek ) class DBServer
the compiler tries to create a local class named "DBServer" for those methods (separate from the DBServer class of the VOSDK), but apparently this class by default is generated as internal, so you get the warning when you try to inherit from that class.
The real problem here, is that in .Net you cannot add like that methods to an already existing class (DBServer) that is defined in a different library (in the RDD classes). You need to use subclassing for that, so add a CLASS definition like the XPorter did, something like (also remove the CLASS clause from the methods):
CLASS My_DBServer INHERIT DBServer
METHOD WildSeek2( cToWildSeek, aCheckFields ) //class DBServer
METHOD WildSeek( cToWildSeek ) //class DBServer
and then change your other class definition to
CLASS _CryptServer INHERIT My_DbServer
and the warning will go away.
There's another option, to use an extension method instead, but this requires some more work, so better leave it for now, until your code compiles ok.
After doing that, number of errors will decrease, but there are some others now:
- Cannot convert type void* to string:
Simply change the code to:
cToWildSeek := Upper(cToWildSeek)
- The first argument to PCALL must be a typed function pointer
Change your 3 PCALLs to PCallNative<INT>. For example change
(this is because from what I see, those IJL functions return an INT)
- Errors about Buffer() function:
That part of the code needs several changes, because strings cannot be used like that as 8bit buffers. Do you still need the MDPDF class in .Net?
Ohh yes i need this class for the momment because all my prints is made with this class. i generating PDF's for my prints. And its a lot of code with this class.
i was reading some part of this class and i think it was converted form C to VO , so maby i can rewrite my importend function's to 'normal' xBase code. My output is very simple, Text, Lines and Jpeg. I dont need all Function of this class.
I had a closer look and from what I see, most of the code works with normal strings, so there shouldn't be problem with it. Only the jpeg/png related code uses binary data and needs adjustment. If you have trouble making it work in x#, please give me a (compileable) sample of using this class to create a report and I will have a look myself.
To give you a little more help, main issue that the VO code uses this in a few places:
LOCAL cBuffer AS STRING
cBuffer := Buffer(bufSize)
FRead3(hFile, PTR(_CAST, cBuffer), bufSize)
this casts a string to a PSZ, which works in VO because strings are 8 bit, like PSZs. This will not work though in .Net which has unicode strings, but you can change it to:
LOCAL cBuffer AS STRING
FRead(hFile, REF cBuffer, bufSize)
and that should do the trick. From what I see, the code does not further manipulate those buffers as binary data, so possibly just the above change in a few places will be enough and no further changes will be needed.
Thanks for the sample! (no big problem, but next time please also include the .sln file, which is in the folder one level up from the folders you included). I see 3 separate issues:
- I think I was not very clear in my previous message, but what I meant with the FRead() function is to also use FRead() instead of FRead3() (note the missing "3"), because the FRead() function takes a STRING param, while FRead3() works with pointers. The way you have your code now, it will fail at runtime, because it is passing to the FRead3() function a pointer to a unicode string, while the function expects a PSZ pointer. So please change your code like that and it will work fine:
IF FRead(hFile, REF l_tbl, l_l) <> l_l
you can omit the "REF" if you want, or replace it with "@", but I think the REF keyword makes it more clear. But it is in any case important in this code to use FRead() instead of Frread3(). You will need to make that change in about 10 places in MDPDF.prg, wherever Fread3() is used with a string argument.
- The Assertion Failed error is due to this:
LOCAL oFormular AS BasicHtmlForm
LOCAL odbArtikel AS _CryptServer
SELF:Artikel_Browser (@odbArtikel, @oFormular, ...
In newer x# builds, this reports a proper error instead of this assertion dialog and the error is that the Artikel_Browser() method accepts params of type OBJECT, while the code passes a BasicHtmlForm and a _CryptServer. You must use the exact types for REF params, so you need to change the method like:
you will need to do the same also to the other methods that use REF params, like Artikel_Write_Formular_Bottom(), WriteMWST(), WriteKategorie() etc. Then all the code of all libraries should compile fine.
- About terminating VS, I don't think you needed to do that, you could instead press the "Ignore" button in the assertion failed dialog, although because it appears a few times you'd need to press it every time. But anyway that's an old issue, as I said in newer X# versions you will not be seeing this dialog, you will be getting a proper error message instead.
VS compie all dll and exeErstellen gestartet: Projekt: _ISAPI SDK HK, Konfiguration: Release Any CPU
_ISAPI SDK HK -> C:\XporterOutput\Release\_ISAPI SDK HK.dll
Erstellen gestartet: Projekt: _Swissbase-Basic, Konfiguration: Release Any CPU
_Swissbase-Basic -> C:\XporterOutput\Release\_Swissbase-Basic.dll
Erstellen gestartet: Projekt: _Swissbase Html-Cgi, Konfiguration: Release Any CPU
_Swissbase Html-Cgi -> C:\XporterOutput\Release\_Swissbase Html-Cgi.dll
Erstellen gestartet: Projekt: Hand SBS Artikel, Konfiguration: Release Any CPU
XSharp Compilation time: 00:00:00.7177458
Hand SBS Artikel -> C:\XporterOutput\Release\Hand_SBS_Artikel.exe
0 Warning(s), 0 Error(s)
========== Build: 4 erfolgreich oder aktuell, 0 fehlerhaft, 0 übersprungen ==========
then i copy this files to my cgi root
the 2 dll vulcanRT and RTFunccs also
and the error text is
Unbehandelte Ausnahme: System.IO.FileNotFoundException: Die Datei oder Assembly "_Swissbase-Basic, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null" oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden.
Before running your app from a different folder, you need to make sure that it runs correctly from withing the IDE (VS). Please try to run it with the green "Start" button in the toolbar, or with Debug/Start Debugging.
I think in your case you will get an error, which is because there's a direct reference to a previous version of a dll in a project. Please go to the "_Swissbase Html-Cgi" library, expand the "References" node an delete the "ISAPI SDK HK" entry. To add it again, select "Add Reference..." and pick it again from the "Projects" page in the dialog that pops up.
Now run rebuild the solution and run again from winthin the exe. Possibly there will be some other runtime error, if there is then it's far easier to resolve it from within the IDE, where the debugger can give you the exact error, line, callstack etc. Only after you make sure the app works properly this way, you can copy thee app files in a separate folder and run it from there.
If course if you need any help in resolving runtime errors, please don't hesitate to ask here!