The new function pointers in Clarion using Start()

! Calling MDI windows. Next to try is using start with an address of a function pointer.

PMDITypeInvoke PROCEDURE(funcptr funcptrref,*IWindowDisplay MDIRef )

areturntype LONG

CODE
funcptrref(MDIRef,areturntype)    
    
return(areturntype)    

Callstartproc PROCEDURE(string address)
callw &funcptr
objectaddress LONG
ParamAnyListref &ParamAnyList
WindowBaseref &IWindowDisplay

CODE
if address > FALSE        
    ParamAnyListref  &=  (address) 
    if not ParamAnyListref &= NULL    
    
       !MDIRef  &= (objectaddress) 
       
        MDIWindow# = ParamAnyListref.IParamsAnyList.GetNamed('GUIMDI') 
        WindowBaseref   &= (MDIWindow#) 
        if not WindowBaseref &= NULL
            callw &= (ParamAnyListref.IParamsAnyList.GetNamed('IDISPLAY'))
            no# = PMdiTypeInvoke(callw,WindowBaseref)
        END    
       
    
   END           
END

If you look at BuiltIns.clw you’ll see that START takes a function pointer now

  _PROC(),TYPE
  _PROC1(STRING),TYPE
  _PROC2(STRING,STRING),TYPE
  _PROC3(STRING,STRING,STRING),TYPE

START(_PROC procName, UNSIGNED stack=0),SIGNED,PROC,NAME('Cla$START')
START(_PROC1 procName, UNSIGNED stack=0, STRING passedValue),SIGNED,PROC,NAME('Cla$START1')
START(_PROC2 procName, UNSIGNED stack=0, STRING, STRING),SIGNED,PROC,NAME('Cla$START2')
START(_PROC3 procName, UNSIGNED stack=0, STRING, STRING, STRING),SIGNED,PROC,NAME('Cla$START3')

Those can be overloaded to take a LONG and pass Address(Procedure). You would have to do all 4 and pick the right one of four.

START(LONG Address_procName, UNSIGNED stack=0),SIGNED,PROC,NAME('Cla$START')

Jim Kane wrote a CMag article “Calling By Address STARTing By Address” 2001-11-16

What would you do if someone gave you a project that involved either calling or STARTing a procedure in a DLL which was loaded dynamically at runtime with some procedures using the Pascal calling convention some the C calling convention and even one procedure with an MDI window that needed to be started on its own thread? If you’re Jim Kane you write a class that handles all of this.

1 Like

2001 Jim Kane!!! That would be an interesting article to read.

Yes start takes a function pointer.

Functiontocall &= MDIWindowFunction

Start(Functiontocall,stacksize#,address(Params))

The new function pointer support is providing a lot of flexibility for code reuse.

1 Like

we have a huge GUI class under development and testing set for this winter that includes an already developed View class manager that changes the GUI View like a scene.

Part of this later this year is a class to resize the control based on a special class that created a screen map rather than the classic resize approach.

The GUI class is only awaiting a Control for use class where the view manager reuses control objects to save on resources as each control uses about a 1000K of memory.

Each control gets a runtime macro for its positioning and a Controls class for each window. I will put some examples up on GIT Hub later this winter but right now its High summer in NZ and we are closed till May.

the only time we have tried opening on another screen is using some csharp code.

the win32 api code for this we havnt tried.

Scenes in out class manger are better off though of as window with runtime controls that move into the user view on event or macro code.

by the way it brand new and we will try it out this winter south hemisphere.

will post the csharp code later… very busy today.

Csharp code but no use in clarion… We dont use winforms nor any graphics in dot net…some csharp code for accessing MS Office and that is all.

monitros.clw (2.1 KB)

Maybe Larry Sand’s Monitor Enum example could help get you on your way? http://www.clarionfreeimage.com/related.html#EnumerateMonitors

Read the contents of the page for instructions about that.

many thanks for that ! We will look into it and see if we can use the information to include in our view manager class.

i actually have Larry sands book that we imported in the day when it had to come via customs clearance.

Multiple Display Monitors Functions - Win32 apps | Microsoft Docs

Does windows 10 even ship win32 anymore or does it just thunk the calls to its new GUI

You can read about WoW64 “Windows on Windows”. I program 32-bit rarely thinking about the OS being 64-bit. The registry can require some thought.

We have started to separate code , base classes and building to a GUI class allowing code to run without a GUI and then With GUI.

yes WOW64 seems the step towards replaceable GUI elements on a multi platform OS for windows.

It looks like this topic could be split into a few new ones to cover all the tangents :slight_smile:
Regarding the Win32 APIs, this came out recently which looks interesting:

1 Like

Larry Sands little example has allowed us to play with idea of a wider monitor to have windows driven by macros… A lot to keep us busy over winter.

we are mindful of not using anything that moves outside a simple GUI set that can displayed say on clarions data any screen.

Possible use in ABC for the new function pointer ref vars in Clarion 11 is an update to the thread work class which uses _CallAdr in CWSYNCLP.CLW.

this could perhaps be replaced with a derived class where you supply the function address and prototype for your work thread.

something perhaps for web session from Bruce or other engineer steeped in clarion.

I just came across this interaction and so am attaching Jim’s article here for reference, with thanks to Dave Harms as always.

cmag-2001-11.pdf (759.4 KB)