Basic questions

[Serggio]

I'm using VS 2015 (Update 3) and XSharp beta 11.

Created an empty Windows Forms Project via wizard.

Question 1:
How do I use VO or Vulcan functions there? Like AllTrim, SubStr etc?
I changed dialect to Vulcan (it was set as Core by default).
I wrote sth like this:

Code: Select all

LOCAL cS1, cS2 AS STRING
    cS1 := "Hello"
    cS2 := SubStr3(cS1, 2, 3)

Tried to compile. It said I need to include references to VulcanRT and VulcanRTFuncs. OK, So I went to "Add references" and I could NOT find them in the list!
OK.
Then I created a new project - a native XSharp project, where these libs are already present in References. Looked at the actual dll location, turned back to WinForms project and added references to those VulcanRT and VulcanRTFuncs DLL's manually using their full path. That seems to be not elegant enough and these libs should be present at References List the same way Vulcan SDK is.
Now functions began to work. But with NO intellisence. I cannot see functions' params at all.

Question 2.
How do I call Windows API functions ?
I've added a VulcanVOWin32APILibrary to my references list. I have it from Vulcan 4.0.401
I may call API functions now, but still NO intellisence.
And I cannot create a structure. I write:

Code: Select all

LOCAL rc IS _winRECT

and get this error at compile-time:
XS0118 '_winRECT' is a element but is used like a VOSTRUCT/UNION

what should I do with this?

SUMMARY:
1. What is the correct way to call standard functions from a WinForms-project ?
2. What is the correct way to call WinAPI functions from a WinForms-project and how to deal with structures?

Thank you in advance for your replies!
Serggio

[Serggio]

As to structure, it seemed to work out after adding: USING Vulcan.VO
The other questions are actual.

[wriedmann]

Hi Serggio,

Tried to compile. It said I need to include references to VulcanRT and VulcanRTFuncs. OK, So I went to "Add references" and I could NOT find them in the list!

only changing the dialect does not change adds/removes assemblies from your application. If you create an application from scratch, they are there because they are added to the template of a new Vulcan dialect application.

Regarding Windows API and structures: do yourself a favor and discard them whenever possible! The .NET framework offers most functionality and you don't need unmanaged code. And why write a wrapper around a Windows API function when the functionality is already there, tested not only by Microsoft, but also by a lot of users, and more powerful in most cases.

Wolfgang

[Serggio]

only changing the dialect does not change adds/removes assemblies from your application. If you create an application from scratch, they are there because they are added to the template of a new Vulcan dialect application.

I agree with that except that I think those assemblies should be registered somehow and be available in the list of "includable" references. I had to add them manually via Browse-Tab pointing the exact dll-file location. Is it the way it is supposed to be?

Regarding Windows API and structures: do yourself a favor and discard them whenever possible!

I would be happy to rewrite everything "from scratch". But it's rather hard to be done when you've got a project running for several decades with millions lines of code. Lot's of ownerdraw components, etc. It would be nice to migrate with copypasting as mush as possible and rewriting gradually. I am looking for that possibility.

The question is about functions in general. I would like to have intellisence for SubStr or At, etc.

But as to the other points, I seem to be falling in love with X#

[wriedmann]

Hi Serggio,

I agree with that except that I think those assemblies should be registered somehow and be available in the list of "includable" references. I had to add them manually via Browse-Tab pointing the exact dll-file location. Is it the way it is supposed to be?

if you have Vulcan installed, they should be in the GAC, and therefore listed where all others are listed. I don't work with Visual Studio, but XIDE has templates also for references.
Normally, I put all my assemblies I need to include in a subfolder of c:DevNETLibs, not only the Vulcan DLLs, but also my own, they fromSQLite, PostGreSQL, AdWords, ....

I would be happy to rewrite everything "from scratch". But it's rather hard to be done when you've got a project running for several decades with millions lines of code. Lot's of ownerdraw components, etc. It would be nice to migrate with copypasting as mush as possible and rewriting gradually. I am looking for that possibility.

I have a lot of code too, but when rewriting it, I will rewrite it in most pure .NET code, so I don't need to touch it later.
Currently, I have not started the migration of my VO applications because I'm waiting for the VO XPorter, but when I need functionality of my VO projects in my X# projects, I rewrite them without using the VO functions because the .NET frameworks offers better alternatives most of the time.

Regarding ownerdraw: this is completely to rewrite when moving to WinForms, I think. Please don't forget that .NET is UTF only, and the VO GUI classes are very different from the WinForms classes (I'll be missing the ListView functionality....)
And when you rewrite, you should use the .NET functionality whenever possible instead of playing with the Windows API structures.

Wolfgang

[robert]

Sergio,

Intellisense for functions etc. is planned for the General Release of X#.
Fabrice is working very hard to support this.

Wolfgang already mentioned 'using Vulcan.VO'.
You can also set the project property that allows X# to look for types in other assemblies that have an 'Implicit Namespace' attribute.
Goto the Language page of the project properties and set "Enable Implicit Namespace lookup" to true.

Robert

[Serggio]

Sergio,

Intellisense for functions etc. is planned for the General Release of X#.
Fabrice is working very hard to support this.

Wolfgang already mentioned 'using Vulcan.VO'.
You can also set the project property that allows X# to look for types in other assemblies that have an 'Implicit Namespace' attribute.
Goto the Language page of the project properties and set "Enable Implicit Namespace lookup" to true.

Robert

Thank you very much for your answer! I'm looking forward for the General Release

Is the way to use WinAPI functions by adding reference to VulcanVOWin32APILibrary correct ? Or there is a better way to do that? Because we still need them, though I do agree with Wolfgang that one should rely exclusively on the .NET Framework. Nevertheless reality dictates that we cannot migrate without those API-calls at least temporarily.

[Serggio]

Another point.
In CAVO I could make REF-argument optional like this:

Code: Select all

METHOD FillString( cStr REF STRING ) AS DWORD PASCAL CLASS Some

   IF (@cStr) != NULL_PTR
     cStr := "Hello"
   ENDIF

RETURN 5

METHOD UseFillString() AS VOID PASCAL CLASS Some
LOCAL cTest AS STRING
LOCAL nRes1, nRes2 AS DWORD

  nRes1 := SELF:FillString(@cTest)
  ? cTest, nRes1  // outputs: Hello, 5

  nRes2 := SELF:FillString(NULL_PTR) // I don't need this function to fill cTest
  ? nRes2 // outputs: 5

what is the way to give NULL to a ref parameter and skip filling it in XSharp?
SELF:FillString(NULL_PTR) gives error: A ref or out argument must be an assignable variable

[robert]

Serggio,

There are 3 problems here:

1) VO does not distinguish between variables by reference and typed pointers. In Vulcan and X# you can distinguish between the 2 following syntaxes:
REF varName = pass variable by reference
@varName = pass typed Pointer

The first syntax is considered "safe" the second syntax is considered "unsafe" and will only compile if you enable "unsafe code" and when you enable compiler option /vo7.

2) Passing a NULL_PTR to a function/method that expects a ref variable is not possible. The function expects that there is a valid memory address and will write to that address. You can imagine what will happen if your program write to a memory address with the value NULL_PTR: exception.

3) Your method FillString already receives a reference to a string. So what do you expect that the expression @cStr returns ? That should be the location of the parameter, so the location where the compiler has stored the NULL_PTR. This location is never a NULL_PTR but always a location on the stack.
I am surprised (and shocked) that this works in VO. It should not work.

Robert

Robert

[leon-ts]

Hi Robert,

Serggio,

I am surprised (and shocked) that this works in VO. It should not work.

Robert

This construction works in VO and works very well. It is similar to MyFunc(cVal AS STRING PTR), but in such look it is untied from GC and with it there will be problems. And in option with REF it is correctly traced in GC. Check on invalid pointer is executed as follows: (@cVal)

Leonid