New Clarion language features - Clarion

marketplace clarionsharp.com/blog/
1
2

New upcoming features are really cool and powerful, but imho they are adding as an AnyScreen dev requirements and will be used exclusively in AnyScreen code, they are not for a use by average Clarioneer.

1 Like
3

No idea of the intended use, but first priority should be to make AnyScreen usable.
Six months since release, one minor bug fix update, still not usable with a two procedure App.

1 Like
4

SYSTEM hooks properties are no longer write-only in the upcoming RTL release. The result of getting these properties are RTL internal functions implementing corresponding statements:
MESSAGE, COLORDIALOG, FONTDIALOG and other standard dialogs,
OPEN for Windows and Reports, CLOSE for Windows and Reports, changing SYSTEM properties, etc.

This means your program can retrieve the RTLā€™s hook function and replace it with your own function, which calls the original RTL code internally

I like the new SYSTEM hook Read feature making it easier to intercept and then call the underlying RTL. Iā€™ve always thought it was fragile to have to Hook=Zero, call the RTL, then re-setup Hook=Address(MyProc). It also prevents more than one hook. This way it can work like WndProc.

I like to hook Window Open/Close for debug and profiling. I changed the templates to save 0{ā€˜Proc_Nameā€™}=%Procedure so from any window I can get the procedure name. A lot of times the HLP() will ID the window.

One thing I need to post is my test to slow how REMOVE() is 10 to 100 times slower now that SV changed to use ShFileOperation. This shows up in Close(Report) taking a longggggg time to remove 1000+ page reportā€™s WMFs. I modified CPCS to insert a call to my DeleteReport(Queue) that uses the API DeleteFile(). I could change that code to the Report Close Hook.

1 Like
5

Iā€™ve been following the AnyScreen newsgroup. In there youā€™ll find that there have been several major updates to AnyScreen and Marko et al have been working with a limited beta group (mostly those who are already on the commercial version) to iron out the kinks. As mentioned there once all the known kinks have been sorted out a clarion 11 build would be made for those developers interested in the free Developer Demo version.

A new C11 build appears to be in the works with all of these updates. Incidentally if you are interested in building AnyScreen apps then I strongly recommend participating in the newsgroup so you can stay up to date with things happening there.

6

To be honest I donā€™t really care why they are added. But they are, as you say, cool and powerful.

While they may not be ā€œimplemented in hand codeā€ by the average Clarion programmer, they are a tool that can be exploited by accessory providers to enable more complex features. So, itā€™s kinda like the template language - while most developers never write a line of template code, almost all developers benefit from the template language existing.

Clarion allows these ā€œleversā€ to exist - a single feature that only one template developer ever makes use of, may end up being ā€œusedā€ by thousands of average Clarion programmers.

7

I like your optimism.

8

Good suggestions indeed. SV originally asked me to participate in the beta group, but when I reminded them that I would need to be ā€œun-bannedā€ from the newsgroups, the offer was rescinded. Same goes for participating in the AnyScreen newsgroup.

Iā€™m sitting here with a suite of test examples that likely could be helpful to Marko et al, but once one is perceived to be a danger to SV, it seems the label lasts a lifetime.

9

I sent this email to SV to suggest a PROP to be able to easily get the address of the underlying Hooked RTL function so make it possible to avoid all Hooks and call into the RTL. I would think this could be done using GetProcAddress(ā€˜messageā€™,hClaRun) unless the RTL is a linked in Lib.

To SV:
The way Read was added to SYSTEM{PROP:MessageHook} allows having a chain of hooks so I could insert a Hook to log messages then call the next hook that I read.

I would suggest a new PROP way to Read the RTL Hook Address anytime to give me a way to call the RTL function and avoid any hooked function. One suggestion would be a PROP:LibHook like property SYSTEM{PROP:LibHookRTLAddress, 1 to 24}. An easier way (for me) would be to allow a Zero Index so SYSTEM{PROP:MessageHook,0} returns the Address in ClaRTL.DLL.

E.g. Maybe I want to only call the RTL Message() and not any hooked replacement when Iā€™m inside PROP:LastChanceException hook because my APP is crashing and I want to keep it simple.

HookExceptionLastChance PROCEDURE(*ICWExceptionInfo ExInfo)
RtlMessage  &MESSAGE   
  CODE  
  RtlMessage &= 0 + SYSTEM{PROP:LibHookRTLAddress,6}   !#1 way  
  RtlMessage &= 0 + SYSTEM{PROP:MessageHook,0}         !#2 way  
  RtlMessage('An unexpected problem has caused an Exception 0x' &  LastChanceHookCls.ExCode ā€¦

What I do now in this case is call the Windows API MessageBox() to avoid Capesoft Message. I know of no problems, just seems a good time to keep it very simple. Iā€™d probably keep it as is and avoid the RTL message too.

10

We need those features to remove all our pointer calls using the old gordon smith solution he called a chunk. Both to hold Dot not delegates and also for handing single function pointers to the CPP language runtime engine instead of an API interface selection.

Put clarion dlls for me on the same footing as CPP.

Instead of binding a class to the runtime using a interface callback pointers can be passed now to runtime bindings.

CalcCoreBindifc.Bindclass(ā€˜GUIā€™,address(classcominterface),CallbackFunctionPtr)

now clarion can live inside the runtime engine as a first class citizen.

11

Blog example

R2       &MESSAGE  ! the MESSAGE - built-in function
  CODE
  R2 &= 0 + SYSTEM {PROP:MessageHook

The new PROCEDURE References syntax does not indicate it is a Procedure, so it would live in the same ā€œname poolā€ as Data that currently allows a Reference? E.g. I can name a Group ā€œMessageā€:

Message  Group
M1          string(255)
M2          string(255)
        end
RefMessageGrp     &Message
  CODE
  RefMessageGrp &= Message

I would guess this gets ā€œError: Ambiguous reference typeā€ mentioned in the blog post.

The next release could require renaming some ā€œreferencedā€ data that conflicts with any procedure name in scope. Typically on the RHS I reference a defined TYPE and I name as ā€œXxxx_Typeā€ so maybe not a big issue. Weā€™ll seeā€¦

12

Tried putting a ref in a queue but the compiler did not seem to like it. Also our previous examples of any screen did not fire of an MDI window on start. We logged a couple of items in the bug report.

Does not seem to be a very well tested release.

13

You could do something along these lines:

DelegateQueue       queue
elegateADR              LONG
                    END
DelegateShape       &Message ! Or any other procedure shape 

    code

    DelegateQueue.elegateADR = ADDRESS(MESSAGE)
    DelegateShape &= DelegateQueue.elegateADR+0
    DelegateShape('Hello there','World')

I know itā€™s not elegant, but itā€™s way better than the old way of doing things.Or just roll a queue of interfaces if it fits in your design.

14

Yes we have been doing an address call in a queue for Dot Net delegates that way for a decade now and using a gordon smith chunk call . which can now be a function pointer call back.

but we would love to put the function ref in a class as a ref not an address as the address has to be cast . we have dozens of dot net delegates working with our scripting language platforms.

They need to get the function pointer refs working in queues and class as they have stated in the helpā€¦ Compiler refuses to compile them.

Means we can move to proxy classes in clarion and really powers clarion up to let me take over the CPP development group, they are going to HATE IT! They hate clarion now but with this i can drive the scripting language engine with clarion services and the DEV TEAM are just going to HATE CLARION as it over takes there much loved CPP. Of course CPP stays the main engine multi platform but CPP can never be used like clarion can now to develop quick windows DLL functionality. The Function pointer technology in clarion now changes the game,

15

We have tested clarion 11 and found the new language feature support does not appear to work properly in Classes and Queues as per stated in the Help.

MAP

   PInvokedtype(long,long,long,long),type,pascal
    PInvoked(long,long,long,long),pascal,name('Pinvoked')

END

Brokerlangauge Class,type

BrokerInvokeref &PInvokedtype

  END

Compiler does not work with this.

16

So when you build the error window says ā€œCompiler does not work with this.ā€? :face_with_monocle:

Or is there an error and on what line of code?

Seems like PInvoked() needs to declare it is a PInvokedtype but I do not recall the syntax for typed procedures, maybe
PInvoked(PInvokedtype),pascal,name('Pinvoked')

17

In your example you have set up a procedure that passes a function pointer of type Pinvokedtype.

Not what we are testing.

18

This works fine. Its the compiler and i dont think they have tested type function refs in classes, queues, groups and BIND yet. Its a first cut they have thrown in there. Our delegates from dot net and type defs in CPP work with clarion 10.

This work ok as well. But there are no examples in classes , queues or groups or Bind for us to test.

MAP
         PPtrType( *Cbase,LONG),LONG,type,PASCAL
     End

PType PROCEDURE(PPtrType ref,cbase p1)

CODE

no# = ref(p1,500)
return(FALSE)

19

We have had email from support regarding it.