I’ve long included RPM in my program for use in two procedures.
When compiling w/ v13622, errors are thrown for a class having method prototypes with the TYPE attribute. Any ideas of the necessary changes to these prototypes?
SaveAs PROCEDURE(PreviewQueue, , BYTE=0),VIRTUAL,TYPE
SaveAs PROCEDURE(?),VIRTUAL,TYPE
DevCallback PROCEDURE(LONG=0, <*GROUP>),VIRTUAL,TYPE
I’ll bet the problem is going to be the OVERLOAD
IOW, rename one of the SaveAs methods
The following quote appears in the Blog posting below:
If there is more than one Procedure or Class/Interface method with the label (for example, a class method is overloaded), or there is a data declaration with the same label in the current scope/context, the compiler returns an error.
That would not seem to explain the error on DevCallback, which is not overloaded.
Interesting that I was able to get a clean compile by removing the VIRTUAL attribute, but because this is the global data dll, that causes problems with dlls down the line.
Lee White has a thread in the softvelocity.clarion.third_party newsgroup about this specific issue and is b busy with a workaround.
If you can access that newsgroup it’s the
‘RPM and CRT for C11 13622’
thread.
Latest post from Lee today 9th Sept was
I still have some tests to run but so far everything is working with
VIRTUAL and DERIVED in place and TYPE dropped. Two stub CLW’s for the
classes, updated source/templates and newly compiled libraries and DLL
and LIB projects are compiling and working.Still need to test drill down from preview as well as CRT and PNet and
then create new installs specifically for 13622 and beyond.I’m hopeful I can get installs ready by next week.
13622 made changes in the compiler that broke the attributes I was using in the target support class in RPM.
I’m working on a fix that includes changes to the core source, templates and class defines so that this problem is fixed. I hope to have new installs available this weekend or next week. These will fix the errors you’re seeing.
SoftVelocity usually provides 3rd party developers with lead time to cover any RTL/compiler changes but they did not consider their changes would affect anyone… they were wrong.
Sorry for the delay in getting this ready, they blindsided me with 13622.
Does the ,VIRTUAL attribute make any sense
when then the ,TYPE attribute is present ?
TYPE, as it has been explained to me, was never documented for use with methods even though it has been documented forever for use with procedures.
I originally used VIRTUAL but that required what is now necessary, empty stubs in a CLW referenced by the class define. By using the TYPE attribute the compiler overlooked the fact that there was not an actual method which is the purpose of TYPE but I had to have VIRTUAL/DERIVED to satisfy the compiler and RTL when they were used.
This has worked since C6 but 13622 changed things and the compiler no longer allows VIRTUAL,TYPE or DERIVED,TYPE. My only avenue was to create stubs and redefine the class structures for RPM and RPMDD(drill down in preview).
I will be testing RPMDD tomorrow although I suspect it will work as expected since the RPM libraries and my target test APP’s compile and work with the new templates, classes and modified library source.
Once I’m satisfied with that I’ll crank up SB and get an install out the door.
Interesting, sort of a pure virtual method.
I’ve always just written a stub,
and put a warning in the method
to remind the programmer that they were supposed to derive the method
MESSAGE('ctBySched.DeleteRepeat should be derived' |
,'Programmer Error' |
,SYSTEM{PROP:Icon} |
)Good way to visualize it and the way I was using it. Just seemed cleaner than an empty stub since it wasn’t required at the time.
Lee,
Very much appreciate the prompt response to the issue. Upon looking at the prototype after seeing the compile errors, my first thought was “this code must date back before Clarion gray hair.”
The attached Abstract class is an example I made based on a Skype post by Mark Sarson (I think). It has TYPE Virtual methods with no definition.
It compiles and works in 13505. My VM won’t run today so maybe one of you can try it in 13622?
AbstractCls.zip (2.0 KB)
Shape CLASS,TYPE !TYPE on Method makes it ABSTRACT i.e. Must Implment
Area PROCEDURE(),REAL,VIRTUAL,TYPE !Abstract
Perim PROCEDURE(),REAL,VIRTUAL,TYPE !Abstract
DESTRUCT PROCEDURE(),VIRTUAL!,TYPE !Abstract compiler error on TYPE Destructor
END
Polygon CLASS(Shape),TYPE
Sides PROCEDURE(),LONG,VIRTUAL,TYPE !Abstract Probably not best design, this should be in Shape
END
Rectang CLASS(Polygon),TYPE
W LONG
H LONG
Sides PROCEDURE(),LONG,DERIVED
Area PROCEDURE(),REAL,DERIVED
Perim PROCEDURE(),REAL,DERIVED
DESTRUCT PROCEDURE(),DERIVED
END
R Rectang
CODE
R.W=4
R.H=8
Message('W=' & R.W & ' |H=' & R.H & |
'|Sides=' & R.Sides() & |
'|Area=' & R.Area() & |
'|Perim=' & R.Perim(),'R. Rectang')
!======================================== Classes ======================================================
! These are NOT defined (cannot be) in the Shape Base because they are TYPE = Abstract aka Must Override
!-------------------------------------------------------------------------------------------------------
! Shape.Area PROCEDURE()!,REAL,VIRTUAL,TYPE !Abstract
! CODE
! Shape.Perim PROCEDURE()!,REAL,VIRTUAL,TYPE !Abstract
! CODE
Shape.DESTRUCT PROCEDURE()!,VIRTUAL,TYPE
CODE
!Must Code this empty DESTRUCT if you want Derived to DESTRUCT if a Base Class DESTRUCT is done by &Shape refernce
!----------------------------------------------------------------------------------
Rectang.Sides PROCEDURE()
CODE
RETURN 4
Rectang.Area PROCEDURE()
CODE
! Message(parent.Area()) !<-- will error on TYPE
RETURN SELF.W * SELF.H
Rectang.Perim PROCEDURE()
CODE
RETURN (SELF.W + SELF.H) * 2
Rectang.DESTRUCT PROCEDURE()!,VIRTUAL !Abstract
CODE
Message('Rectang is Destructed')No need. Z informed me that VIRTUAL,TYPE and DERIVED,TYPE are flagged by the new compiler as errors preparing for the documented use of TYPE on a method to come later.
There’s a new build coming soon but it doesn’t change this new behavior. I was told that TYPE was never documented for use on methods, just procedures but I now know they’re different although not specifically documented as different. This is the sort of thing that makes me want to SCREAM!
OTOH, it’s very 2020
I expect to have an RPM install available this weekend.
The existing CRT, AFE and PNet products should move forward without any changes required. If an update becomes necessary one will be provided at a later time.
I have contract work, I think (hope), that needs my attention.
Sorry Lee, I guess that was me that caused SV to “fix” it to work as documented…
In May I sent that Shape Class example to SV saying TYPE methods work and should be documented because it’s a useful and common OOP technique exactly like C++ Pure Virtual, C# ABSTRACT or VB.net MustOverride . You cannot declare a Shape object, you must inherit and define the Type Methods.
BTW notice the Shape DESTRUCT is implemented (not Type) because I want it to be Virtual. What I think of as a “Jeff Destructor” that works for Dispose(Shape) to call the Derived. Maybe the coming changes will allow DESTRUCT,VIRTUAL,TYPE which would be ideal (it errored for me). Maybe they will be more C++ Abstract like or maybe C# .NET that seems to have the most OOP features.
Maybe it would make you feel better you fixed it all yourself to think of SV not fixing this way:
This is akin to raiding someone’s underwear drawer then posting photos
of it on the internet, then demanding that they mend the holes on their dime.
I’m with you and want to SCREAM!
This is just an approximation, but I think the metaphor in this case is discovering a well near an abandoned broken whiskey still in the Smoky Mountains, then using the well water to plant a beautiful fruit orchard, and Lee makes some yummy preserves to sell (If this was CA, it would be MJ). Then SV fixes the still then diverts the orchard water for whiskey production, then the orchard dies and everyone gets hammered drunk waiting for the next build. But they used corn in the mash and the whiskey has methanol in it and everyone dies alone after they go blind and their livers explode, but at least the stock market is kicking butt.
Gotta find those silver linings wherever you can!
Confirmed my Shape example errors on the VIRTUAL,TYPE. Works without VIRTUAL.
Methanol is wood alcohol not corn.
I recall that from the story of the Stage Coach driver that would steal alcohol by putting a nail into the wood barrel. He could not read but knew a few words like Alcohol. Was a bully and beat up the guy at the General store who solved the problem by ordering only Wood Alcohol. The bully could not read it said “Wood Alcohol not for human consumption”. So he went blind and died. So you might say the barrel was undocumented to the driver.
Kinda sorta but not really. I tried that myself and the EXE compiled since the use there included in the locally defined methods. However it was just fooling itself and since the related RPM libraries do not include locally defined methods calls to those through a passed reference would NOT compile.
The only solution was to write stubs with empty methods, remove TYPE and use the original VIRTUAL and DERIVED. Now it all compiles and works as expected although it’s not nearly as “clean” as I wanted it to be when using TYPE.
I highly recommend dropping TYPE on methods for now since Z already mentioned they will be used in some manner in a future release - best to dodge the bullet now, at least for me.
MEMBER
INCLUDE('RPMxtSupport.INC')
RPMxt_SupportTYPE.SaveAs PROCEDURE(PreviewQueue PQ, <QUEUE MarkedQ>, BYTE CloseWin=0) !STUB for changes in C11, 13622
CODE
RETURN
RPMxt_SupportTYPE.SaveAs PROCEDURE(? LookupText) !STUB for changes in C11, 13622
CODE
RETURN
RPMxt_SupportTYPE.DevCallback PROCEDURE(LONG PassedLong=0, <*GROUP PassedGroup>) !STUB for changes in C11, 13622
CODE
RETURN
MEMBER
INCLUDE('RPMddSupport.INC')
RPMdd_SupportTYPE.Callback PROCEDURE(LONG SelectedQRec) !STUB for changes in C11, 13622
CODE
RETURN
RPMdd_SupportTYPE.HoverCallback PROCEDURE(LONG SelectedQRec, BYTE Enable=0) !STUB for changes in C11, 13622
CODE
RETURN
Using these stubs it all works as expected now.