TOPIC:

In preparing my VO libs for X# conversion I encounter a few issues with the next lib for which I would appreciate further advice:

Question 1 I have multiple programs including IC2.lib and iConnect.lib.

The first lib contains all shared basic functionality. Some programs do not need more, you could say we have a main program and IC2.lib is included from where the (mainly few) menu items are called from.Other programs also include iConnect.lib and usually have the whole bunch of general screens (like relation screen, countries, languages, contact persons etc).


In IC2.lib we have:

CLASS IC2StSh INHERIT acf_shellwindow // (this inherits from ShellWindow)

In that lib we have all methods for this class necessary.
Obviously in the iConnect.lib we have many more methods of that same class only needed for programs including that library. And any of these generate the much hated XS9016 error because CLASS IC2StSh is not present in iConnect.lib.

I can imagine that possible solution is to create a iconnectstsh inherit ic2stsh and replace the class in all methods in iConnect.lib.

I guess that solution works? But is it the most efficient? I have 100's of methods of that class which would need to be replaced.

Question 2

oHTTP := cHTTP{"Test"}
cResult := oHTTP:GetDocumentByURL(cFile)
oHTTP:CloseRemote()
oHTTP:Axit()

The last line gives this error:

oHTTP:Axit()
Severity Code Description Project File Line Suppression State
Error XS0245 Destructors and object.Finalize cannot be called directly. Consider calling IDisposable.Dispose if available.

No idea what I should do here?

Question 3

CONSTRUCTOR(lGroupAttparm AS LOGIC,lYearOnlyparm AS LOGIC) AS OBJECT CLASS ProfileFilter
//#s Passes parms to filter 22-11-2004
SELF:lGroupAtt:=lGroupAttParm
SELF:lYearOnly:=lYearOnlyParm

Severity Code Description Project File Line Suppression State
Error XS1003 Syntax error, 'Classvar Modifier (EXPORT, PROTECTED, HIDDEN, PRIVATE, PUBLIC, INSTANCE, STATIC) expected' expected iConnect Library

Same question. What is wrong with this?

Question 4 In a library Common control MEF I have not created myself I found this DEFINE:

DEFINE LVM_GETTOOLTIPS := (LVM_FIRST + 78)
RETURN PTR( _CAST , SendMessage( hwndLV , ;
LVM_GETTOOLTIPS , ;
0 , ;
0 )

This gives this error:

Severity Code Description Project File Line Suppression State
Error XS9002 Parser: unexpected input 'RETURN' iConnect Library
It looks highly unusual to have a return value in a define but I guess it serves some purpose. What should I do there?

Dick

Hi Dick,

1. Yes, inheritance sounds like the most logical solution here, and is easy enough I think. With "I have 100's of methods of that class which would need to be replaced." are you referring to adjusting the CLASS <classname> clause of the methods? With search & replace in files this will happen instantly...

2. Normally you can just delete this line of code and let the garbage collector call the Axit() (destructor in .Net) itself, when it collects the object. I checked what this method does in the SDK and mainly it closes connections. Is it important for you that this happens exactly on that moment, and not a lttle later (when the GC kicks in)? If it is important, I think we can add a method in the SDK that does that, using a different name than Axit and you can call it instead.

3. Try removing the "CLASS ProfileFilter" clause for this entity, does this fix it?

4. This is clearly corrupted code (I have seen it as well in the SDK), for which strangely enough VO does not give an error message, or does not even report a warning at all, that something is wrong!!!. Just delete the four lines after the one with the DEFINE.

Hello Chris,

You keep amazing me with your fast replies...

1 Sounds easy enough but it doesn't work.
- In my MAIN program I have an emptyshellmenu. One of the menu choices calls: ShowWindowX
- In my IC2.lib resides the class IC2StsH
- In my iconnect.lib I have the method ShowWindowX class IC2StSH. This method is called when someone selects that menu item.
- I add in the same iConnectlib
CLASS iConnectStSh INHERIT IC2StSh
and change:
ShowWIndowsX class iConnectStSh

...now the method is no longer called. Why not I wonder?

2 I remember from earlier uses of the GetDocumentByURL that leaving out any of the lines including the Axit caused problems. Maybe because of multiple calls and the object must be destroyed before the next call works, does that make sense? In that case there should be a working solution for Axit in X# indeed .

3 Removing CLASS ProfileFilter does not help. It is supposed to be ignored anyway I understand?

4 I thought something like that already. I've removed it in VO and I still see tooltips on buttons and that's the only place I use them I think.

Dick

DIck,

1) I have a difficulty imagining your class hierarchy.
2) I will make a change to the VO SDK code. The contents of Axit() will be moved to another method (Destroy() or Close()) and Axit will call that method. You can then call that method in your code too if you want to force close the session before the garbage collector kicks in.
3) remove the "AS OBJECT" clause as well as the CLASS clause. And did you have a typed Init() method in VO as well? That may work for documentation purposes but constructors in VO are always called using late binding.

Robert

Hello Robert,

For 2, great. For 3, yes, removing the AS OBJECT helps and indeed the strong typing of an init is strange. The Error XS1003 Syntax error,did show up once more in a more astonishing way: a non strong typed method where the following lines (like the 1st 3 using a local oServer used throughout the method) was the line the error pointed to. Only by disabling all 4 lines it was gone (and back again on enabling any of these lines).

olServer:Commit()
olServer:Unlock()
olServer:ResetNotification()
SELF:oDCfxStatus:Caption:=NTrim(ni)+"/"+NTrim(nLen)+" "+Vt(CLM_OPEN,"Open")+" "+cDataPath+"__RelationMoveLog.txt"

Unless this directly makes sense to you I will try to reproduce it in a separate program.

About 1, I have attached a picture. I would say this is nothing special.
1 I have multiple main programs (AEF with just a few mefs/methods), say 1 +2 (top picture). In the most basic way these show an empty shell menu and a start method
2 Both programs include IC2.lib with the most basic functionality of our programs in it. Part of these methods are from IC2StSH defined here in IC2.LIB
3 Only program 2 also includes iConnect.lib with more functionality. Part of these methods are also from IC2StSH defined in IC2.LIB
4 I can call method DoThis of class Ic2ShSh (class defined in ic2.lib) from iConnect.lib from the EmptyShellMenu
5 If I define a class iConnectStSH INHERIT IC2StSH in iConnect.lib and change method DoThat to be of that subclass, the method is simply not called.

Does this make it more clear? It is very difficult to debug something which does not happen due to a class structure which I would say makes sense.

Dick

Hi Dick,

In the place where you instantiate the shell window, did you remember to change IC2StSh{} to the new one iConnectStSh{} ?

Btw, regarding Axit(), do you mean you are reusing the same cHttp object after calling Axit() in VO? I am not really familiar with those classes, but by looking a bit into the SDK code, I cannot imagine how the object can still be reusable after calling what Axit() does right now.

Hello Chris,

In the place where you instantiate the shell window, did you remember to change IC2StSh{} to the new one iConnectStSh{} ?

Ah, that makes sense and that is basically the issue. I didn't realize that this is done in the start.
In our Start method this is what we do:

oWindow := iconstsh{SELF,oMenu,oToolbar} // App's shell window
oWindow:Show(SHOWZOOMED)

(iconstsh inherits from ic2stsh)

If I quickly replace iconstsh to iconnectstsh, the window with the changed method indeed starts. I do lose Sven Ebert's nice toolbar at that moment, this is arranged in iconstsh apparently, but that can be fixed I expect. Thanks!

Btw, regarding Axit(), do you mean you are reusing the same cHttp object after calling Axit() in VO?

No, certainly not. I only vaguely remember that if any of the lines, including the Axit, were missing, the whole procedure failed. Probably immediately, or on a second call (with a fresh object). Not sure about that, every time I use this I make sure copy the same lines as in existing methods.

Do you want me to do some testing and report back? It wouldn't be the first time that something also works without code one thinks to be absolutely necessary

Dick

Hi Dick,

ic2 wrote: Do you want me to do some testing and report back? It wouldn't be the first time that something also works without code one thinks to be absolutely necessary

Out of curiosity, I would indeed like to know if it indeed makes a difference, for future reference. But in any case as Robert said he will anyway move the code from Axit() to a regular method, which does not hurt at all and will give you the option to call it no matter if it is actually necessary or not.

Hello Chris,

I checked and directly after that saw & remembered the issue of not having an Axit. The call works, but after closing the exe you always get this unhandled exception error of CSession. See picture.

So yes, at least in VO, an Axit is a necessary program line.

Dick

Hi Dick,

Thanks! That looks to me like a bug in VO, maybe its garbage collector releases objects in the wrong order. I wouldn't be surprised if it works fine in X#, without any call to Axit() or similar.

In May 2020 you wrote about Axit:

robert wrote: DIck,

2) I will make a change to the VO SDK code. The contents of Axit() will be moved to another method (Destroy() or Close()) and Axit will call that method. You can then call that method in your code too if you want to force close the session before the garbage collector kicks in.
Robert

But in the forelast version of X# I use I still get

Error XS0245 Destructors and object.Finalize cannot be called directly. Consider calling IDisposable.Dispose if available.

on a line like oParser:Axit() .

I assumed that with the above that should no longer give an error?

Dick

Dick,
Axit methods should not be called directly. Also not in VO. They are called by the Garbage collector when needed.

The best approach is:
- Move the body of the Axit() method to a Destroy() method
- Call Destroy() from inside Axit()
- When you want to cleanup under program control, call Destroy() and not Axit()

Robert

Thanks Robert.

I concluded from your earlier reply that the error would be fixed (without change), but changing Axit to Destroy in some places should be easy as well.

Dick

Robert,

I am currently trying to translate a thirdparty Lib called ClassicNuVo und fighting with the Axit as Dick did.

What if the Axit Method itself calls Axit in the last line like:

Class Foo inherit DATAWINDOW

Method Axit() Class Foo
* Do some Stuff that should be moved to a Destroy() Method in x#
return super:axit()

Class Foo1 Inherit Foo
* Do some Other Stuff that should be moved to a Destroy() Method in x#
return super:axit()


If I should not call Axit directly in my code, are all axit methods from all subclassed Classes called?

Heiko

Heko,
Try this and you will see that both destructors are called, even when there is no call to the super:destructor
Robert

Robert,

thank you for the fast response!

Heiko