xsharp.eu

First, it's merely assumed that users have Visual Studio installed before installing X#. I recently discovered that that's the reason I didn't have integration between the two. When I reinstalled X# with VS installed, then I could open the project in VS generated by the VOXPorter. Perhaps something for future reference for other developers.

This involves another issue entirely. In my application, I have SetSoftSeek(TRUE) at start of runtime. Later, among other values, it searches for the expression "aa" in a dbf file called TypeRule. Given its particular operation, the records can't have spaces following the expressions but are followed with the "{" character, ASCII value 123, which is 1 higher than the alphabetic characters it searches for, instead of spaces, which are ASCII value 32. With that, when searching for a string such as "aasvPSs", the record pointer should point to a record with "aa{{{{{{{{" in the indexed field, and given that SetSoftSeek() is true, EOF() should be false.

In X# and VO, the record pointer points at that very record and EOF() is false, but in VS, the field is blank because EOF() is true.

I think this is handled by VORDDClasses, which is present in the VS project as well as in X# and the original VO. Is there any way to resolve this so that it runs the same in both?

Thomas,
Thanks for your remark about the installer.
I'll try to add a warning to the next installer.
W.r.t. the softseek issue: I really do not understand why the behavior of X# inside VS could differ from the behavior outside of VS. Running inside VS should have no influence on the runtime behavior.

Robert

Hi Thomas,

In addition to what Robert said, can you please send a sample reproducing the problem?

.

Sure. For some reason the VS fails to build this. Also, dbf's and ntx's aren't among the filetypes that I can include as an attachments. The structure and the sought record is here:

RECNO TYPE RULE ABBREV RETAIN PLACEHLDER SUBTYPE BASETYPE EMBED PRIBASIC DEFDUPES
98 3 aa{{{{{{{{{{ a 0 0

TYPE is a 1-byte character field and RULE is a 12-byte character field, and DBCREATEINDEX("c:DiscoveryOLDdbfsTYPERUL1","TYP Rule Placehlder")

Hi Thomas,

Thanks for the file. You did not mention what error you are getting in X#, but most likely it's that you jest need to go to the project properties, "Language" page and enable the options "Enable MEMVAR support" and "Enable Undeclared variables support". We will make sure that VOXporter automatically enables those options in the next X# release.

About the data files, please zip all the necessary dbf/ntx and or dbt files and upload the .zip file, this is allowed.

.

Actually there is no error when I run it from X# or VO, only when I run it from VS. Also, I did check the memvar support and undeclared variables support in all three.

In any event, I found out what the real problem was: it was searching for the value with the wrong index. When opening up more than one index file for a dbf file, the active index and order is different depending on which IDE it's run from. :blink: Robert was right. SetSoftSeek() behaves the same way whether in VO, X# or VS.

DBUSEAREA(TRUE,"DBFNTX","c:DiscoveryOLDdbfsTYPERULE.dbf")
DbSetIndex("c:DiscoveryOLDdbfsTYPERUL1") <<<<< In VO, it's the first index file opened.
DbSetIndex("c:DiscoveryOLDdbfsTYPERUL2")
DbSetIndex("c:DiscoveryOLDdbfsTYPERUL3") <<<<< In VS, it's the last.

So at the point where DBSelectArea("TYPERULE") is executed just prior to searching for the intended record, I just put DBSetOrder(1), and solved the problem. I guess you wouldn't need the zip file with the DBF's or NTX's then. Oy. :unsure: :S

Congrats...
FTR, there seems to be a misunderstanding/-spelling: "X#" is the compiler, "Xide" is Chris' IDE for it.

Hi Thomas,

Indeed, no need to send the dbfs, actually this specific problem (different behavior to VO) was reported and fixed last month, see here: https://github.com/X-Sharp/XSharpPublic/issues/958. The fix is already available in the latest subscribers' X# release and will be included also in the next public build.

But this issue is the same no problem where you are are running the app from, the IDE (VS or XIDE) should have absolutely nothing to do with it, so I am surprised you say you get different results. Maybe you are actually testing with slightly different code in the two IDEs and that makes the results slightly different. Of course, when you run the app from VO, then the results are different (due to above mentioned bug in X#), but VO has nothing to do with X#.

Also as Karl said, there seems to be some confusion with names. To clarify:

- X# is the main product, the compiler, runtime, VOXporter and many more things, also including integration for VS.
- XIDE is a standalone (freeware) IDE designed to work (mainly) with X#
- VS is, well, VS . X# integrates into it.

The compiler and the runtime is always the same, no matter which IDE you are using, so when the code is the same and the compiling options are the same, in both cases the X# apps should be behaving EXACTLY the same.

.