xsharp.eu

Thomas,

We decided to do Substr() that way so we can allow all kind of "strange" parameter values, such as a negative 3rd parameter. We could add many overloads, but this was simply easier.

For functions inside Core we could not do XBase style parameters because we do not have a USUAL type there.

For functions such as GETFLDSTATE I would prefer to have simply one implementation that checks for valid parameter types. Even if you write overloads for the parameter you will still have to check for the validity of the fieldname, field number, area number and/or the table alias.
If you create overloads then you would have to create duplicate checks and I don't think that is a good idea.

I have no idea what Python-Slice does, but our rule of thumb has been that we do not add extra "strange" behaviour, such as negative start positions, unless one of the dialects already supports that.

Robert

Hi Robert,

robert wrote:We decided to do Substr() that way so we can allow all kind of "strange" parameter values, such as a negative 3rd parameter. We could add many overloads, but this was simply easier.

In vfp negative numerical values result in returning an empty string (if all other given parameter types are correct)

Checking for those conditions and fixing missing parameters will duplicate most of the parameter checks done in RT (which I totally agree is nothing to strive for), but is probably less effort in code and runtime registering on QueryPerformanceCounter than trying to call RT,SubStr with the same # of parameters, but that way vfp behaviour is mirrored better.
As __SubStr(str, int, int) from Core can be called as a function sidestepping all those checks, perhaps a note in vfp docs for SubStr() should be added (including negative numbers) as well as a hint to String.SubString() for those occasions you have to run a tight loop very often.

For functions such as GETFLDSTATE I would prefer to have simply one implementation that checks for valid parameter types. Even if you write overloads for the parameter you will still have to check for the validity of the fieldname, field number, area number and/or the table alias.
If you create overloads then you would have to create duplicate checks and I don't think that is a good idea.

Understood.

I have no idea what Python-Slice does, but our rule of thumb has been that we do not add extra "strange" behaviour, such as negative start positions, unless one of the dialects already supports that.

I see xSharp as "vfp10" (or "vfpX"), and vfp, while VERY good at avoiding breaking changes in new versions, often introduced addiional parameters to existing functions to add capabilities.

I probably was too cryptic stating that my JustExt(tcURI) was following Dotnet conventions: vfp returns extension without leading dot, whereas Dotnet includes said Dot. As long as you use ForceExt(), this difference will not matter, as ForceExt() does minimal cleaning to stem and extension, but if you just concatenate in user code, that usercode will have problems encountering "extension" with a leading dot. But as we move to Dotnet, some might WANT Dotnet Extension returned - so I see no problem adding optional second parameter to return Dotnet format WITH leading dot, as all existing code (having only 1 parameter allowed in vfp9) works as expected. But for real vfp compatibility that dot has to go
(Describing the stuff takes more time than code....)

Your call to decide if adding "Dotnet dot" return option via additional parameter is better or not..

regards
thomas

robert wrote:
- The currency support is in the 2.3 compiler. You do not have that compiler yet.
- You will therefore not be able to compile XSharp.RT, unless you also build the compiler
...reordered
- To help with the VFP functions you should normally only need to download the code to the XSharp.VFP component. I am sure that this will not work now (until we have released 2.3) because functions like NToM and MToN require the Currency support in the new compiler.

I'll stay in vfp and replacing those 3 CURRENCY enables compilation just as much as "out-commenting" those lines

- I am not sure why your project wants .Net Core. Non of our runtime components requires .Net core.

My mistake - was Dotnet Framework 4.6, installed was 4.6.1

- The keyfiles are in the right location if you compile with VS. Chris is the only one in our team that works with XIDE. You should ask him what to change to get the XIDE code to run. I can imagine that the Runtime.xiproj file needs to be updated, since I have added some new files since it was last updated in October 2019.
- When you install X# then we install the runtime files in the GAC. When testing you have to make sure that you are testing with the updated runtime and not with the files from the GAC. That's why there is an option to NOT install the runtime in the GAC in the installer.

At the moment it works (except for JustFName... but probably just spelling mistake somewhere I need to check after good sleep), so I am not worried. Going for EVL(), NVL(), ForceExt(), ForcePath(), StrExtract() later this week - in ForceExt() some edge cases to consider like leading and trailing dots. NVL() without IsNull() not really testable, but with Nil, DBNull, none and perhaps other stuff I will not try IsNull().

I see the benefit of the compiler flagging not implemented versions, but that XML stuff is drudgery. If you can automatically generate the XML once for all functions, including those not yet implemented, prepending the not implemented ones with "_#" will still generate compiler errors for correct function names not implemented yet, but give a skeleton XML easy to modify without typing errors...

regards
thomas

Hi Chris,

at the moment it works - and I am happy on every single occasion I "compile" or "Run" compared to "Projectmappe erstellen F6"
Compared to VS XIDE at the moment is better for me and I have not reached areas where I really need VStudio - went with it as Robert mentioned using it for xSharp.Vfp project and I tried not to change anything in the setup.

Chris wrote:Unfortunately for myself that's not an option, because I also need to be looking at many reports that do assume the dlls are in the GAC and it is not convenient adjusting them every single time, so what I am doing is to do my changes in the runtime, close XIDE, update the files in the GAC (just a simple copy & paste), then restart XIDE.

But for you Thomas, what you can do is to remove all X# runtime references from the GAC and replace them with direct references to the "active" dlls that you use/compile, then also delete the X# files from the GAC and then always work with your own set.

I tried redirecting xSharp.vfp.Dll, but failed due to missing start function - maybe forgot to restart. No big deal, as copying into GAC works, only problem is to always use Win tools as others may have trouble with admin authorisation needed for that stuff.

regards
thomas

Hi Matt,
Promatrix and the Feldman fwk were around in FPW times and they had a datadictionary functionality either before vfp6 and/or surpassing DBC. IIRC together wth xCase and Stonefield they created a common "data dictionary dbf structure" enabling all toolsto work together. (dbxi ?).
Never looked hard, as we - if needed - just used xCase. Hank Fay, who did a lot with Promatrix, extended xCase to allow data driving more fwk processes and automatically resolved / lifted fubctionality from DD into client code.
Might be either of those 2...

regards
thomas

FoxProMatt wrote:By "vpme", I assume you are referring to "Visual ProMatrix Enterrpise" ??

https://promatrix.com/

And they use their own classes and tables to live without the DBC features. But without DBC you don’t have long field names and some other features..
BR Rainer

So, I'm not sure what point(s) you are trying to say here.

Hi Thomas,

mainhatten wrote: I tried redirecting xSharp.vfp.Dll, but failed due to missing start function - maybe forgot to restart. No big deal, as copying into GAC works, only problem is to always use Win tools as others may have trouble with admin authorisation needed for that stuff.

XIDE very rarely needs a restart, if ever. And certainly never a PC restart! The missing start function (error message?) means that either you accidentally had set the "target" of your app to Console or Windows instead of Library (DLL), or that you indeed created a console/win app, but did not provide a suitable Start(). Please keep in mind that Start() in X# is the same as Main() in c#, so it has the same requirements, and can't have ANY parameters and return types. Acceptable versions of the Start() are:

FUNCTION Start() AS VOID
FUNCTION Start() AS INT // returns exit code
FUNCTION Start(args AS STRING[]) AS VOID // or INT // cmmandline argsuments are passed to "args"

Regarding copying to GAC, I've always used for more than 10 years a simple win explorer copy and overwrite directly to the GAC windows folder, like in C:WindowsMicrosoft.NETassemblyGAC_MSILXSharp.RTv4.0_2.1.0.0__ed555a0467764586, that never failed me once!

Hi Chris

Chris wrote: XIDE very rarely needs a restart, if ever. And certainly never a PC restart! The missing start function (error message?) means that either you accidentally had set the "target" of your app to Console or Windows instead of Library (DLL), or that you indeed created a console/win app, but did not provide a suitable Start(). Please keep in mind that Start() in X# is the same as Main() in c#, so it has the same requirements, and can't have ANY parameters and return types. Acceptable versions of the Start() are:

FUNCTION Start() AS VOID
FUNCTION Start() AS INT // returns exit code
FUNCTION Start(args AS STRING[]) AS VOID // or INT // cmmandline argsuments are passed to "args"

It was a Console app, with snipped
FUNCTION start() AS VOID

Regarding copying to GAC, I've always used for more than 10 years a simple win explorer copy and overwrite directly to the GAC windows folder, like in C:WindowsMicrosoft.NETassemblyGAC_MSILXSharp.RTv4.0_2.1.0.0__ed555a0467764586, that never failed me once!

I am often changing Filemanager(s), from Totalcommander over Double Commander (Java, but that allows it to run on Linux) or other more modern Norton clones - trying sometimes on Linux with Wine, different VM's and so on as I also have to move from Win7 soon and am still undecided if I should go to Hyper-V, try for booting directly from .VHD or move to Linux as Host OS and some VirtualBox Windows VMs, perhaps even a Linux guest WINE enhanced...

regards
thomas

Thomas,

mainhatten wrote:

robert wrote: I see the benefit of the compiler flagging not implemented versions, but that XML stuff is drudgery. If you can automatically generate the XML once for all functions, including those not yet implemented, prepending the not implemented ones with "_#" will still generate compiler errors for correct function names not implemented yet, but give a skeleton XML easy to modify without typing errors...

I am not sure what you try to say here. We have already generated the XML for all functions, but since this is generated it may need some cleaning up. That is why we have 2 separate XML files. One for the "original" converted XML comments, and one for the "cleaned up" comments.
And if you think the XML is "dirty" then please have a look at https://github.com/VFPX/HelpFile/tree/m ... xhelp/html, which is where we got the original code from. Each file is a page.
https://github.com/VFPX/HelpFile/blob/b ... e88f5f.htm is the page for STRTRAN().
I am not sure how this was edited, but to me that's a real nightmare..

Robert

robert wrote:I am not sure what you try to say here. We have already generated the XML for all functions, but since this is generated it may need some cleaning up. That is why we have 2 separate XML files. One for the "original" converted XML comments, and one for the "cleaned up" comments.
And if you think the XML is "dirty" then please have a look at https://github.com/VFPX/HelpFile/tree/m ... xhelp/html, which is where we got the original code from. Each file is a page.
https://github.com/VFPX/HelpFile/blob/b ... e88f5f.htm is the page for STRTRAN().
I am not sure how this was edited, but to me that's a real nightmare..

I probably guess wrong about your workflow - even with XML editor Ifilling in Docs will be ugly. Had hoped you could generate. missing Function, parameters, returns and docs from the tables I sent you, but probably too hard to integrate already existing stuff into dbf table structure...
Pls. Eyeball attatched,
done by intent in the upmost xSharp-runtime level where I thought appropriate. Overloading twice, but I think easy as nothing duplicated.
Will do StrExtract, GetWordCount,GetwordNum next

regards
thomas

Thomas,

Thanks for the code. I will have a check and will integrate it. Some remarks from having a quick look:
- good idea to add the return type for the Just..() functions and AddBs()
- avoid using Left() and Right() to check for starting or ending with a certain character. These functions create new strings and you don't want that. Use :EndsWith() on the string in stead
- avoid calling untyped functions such as Len(). For strings we can call the :Length property or the typed function SLen() (which does not crash when the string is NULL)
- there is no need to create locals lcFileName etc when the parameter is already declared properly.
- instead of a function __SubStr() you can call string:Substring() with a 0 based offset.
- in the runtime code we prefer to use ":=" in stead of "=" to avoid confusion between comparisons and assignments and we also prefer to use the ":" send operator over the "." operator because that last one could also be interpreted as workarea.Field .

Robert