More info http://www.clarionmag.com/cmag/faq.html

This is something I hadn’t noticed before today. It may be common knowledge to others

When editing an embed, if you hold down control key then PageUp and PageDown are restricted to the current page instead of scrolling up/down. Kind of like Home/End for the visible area only.

Do you know of any other obscure keyboard tricks in the Clarion editor?

Just yestarday I managed to duplicate these symptoms in my development environment and discovered that the problem was being triggered in the InitSetEventOffset ROUTINE of the Debuger class we are using.

You can download the class over at Radfusion Free Downloads.

The helpful folk over at the clarion skype chat were able to narrow this down to a problem with the length of the CSTRING used in the call to DebugerNameMessage.

Further analysis shows that this only manifests as an issue under very specific circumstances:

• The class instance is created using New().
• The application is compiled with debug mode set to “off” (or in other words, in “release” mode).
• The application is run “asInvoker” on a system with UAC tuned ON.
• There is no “EventOffset” entry already in the WIN.INI file*.

_{* That last point will depend on the version of the debuger class you are using. The one we have here is “6.0.2″ but there are others around that no longer use WIN.INI and they might work OK. Note though that when I say “OK” the problem hasn’t gone away and you will still see the APPCRASH error the first time your program is run but subsequent executions will be able to read the offset from the INI file and this bypasses this bug.}

Changing the variable from CSTRING(20) to CSTRING(128) fixed the problem (Thanks Larry!) but I was still curious to find out what the cause was.

First lets look at the prototype forDebugerNameMessage :

MODULE('C%V%RUN%X%')
  DebugerNameMessage(*CSTRING, UNSIGNED EventNum ),NAME('WslDebug$NameMessage'),RAW   !Note: use   EVENT() + EVENT:FIRST else will get WM_*
END

And it’s usage:

Debuger.GetEventDescr             PROCEDURE(LONG ArgEvent)
LOC:Retval   CSTRING(20)
LOC:EventNum UNSIGNED
  CODE
  DebugerNameMessage(LOC:Retval, LOC:EventNum)

(I have removed all the other code from the above method just for clarity in this example)

The call to DebugerNameMessage crashed just after giving this result:

LOC:Retval=WM_OTHERWINDOWCREATE, LOC:EventNum=66

When the LOC:RetVal is changed to CSTRING(128) we see that the next call is this:

LOC:Retval=WM_OTHERWINDOWDESTROY, LOC:EventNum=67

The reason for the crash I guess is Len(WM_OTHERWINDOWDESTROY) > 20

There are 2 questions remaining and I think I have the answer for one:

Why does it only crash when the class is instantiated with New()?

I am pretty sure this simply because when using New() the “EventOffset” is different and so the InitSetEventOffset routine attempts to find the correct offset and thus triggering the problem with our too small variable.

Why does it only happen when the program is compile with debugging turned OFF?

I guess in debug mode the code it is not so sensitive about the buffer overrun it still seems kind of strange that it should work at all.

Hopefully someone reading this will be able to give a hint as to a possible reason?

In Clarion the help has this description for “IF”:

1
2
3
4
5
6
7

IF logical expression [ THEN ]
  statements
[ ELSIF logical expression  [ THEN ]
  statements ]
[ ELSE
  statements ]
END

Quite often in production code I have seen examples of many, many lines of expressions after the IF, the developer using the “|” line continuator to span multiple lines.

The comment, I think it was Marg G, was to use THEN to make it clear where the <expressions> have finished and the <statements> have begun:

1
2
3
4
5
6

IF <some condition> OR |
   <some other condition> OR |
   <even more conditions> |
THEN
  ! Do something
END

Pretty simple and very neat!

It will be nice to see if C7 supports code folding for this kind of structure as well…

Nah, not really, that is just blatant sensationalism to get your attention

I found an article the other day that was a really interesting read.

From the article:

I’m trying to push for more Python adoption at the company I work at. This led me to casually google for “Python sucks” in order to anticipate any criticisms from coworkers.

From”Your Ignorance Does Not Make a Programming Language Suck “

It is an interesting idea for determining status of something. There is just mostly noise with “Clarion sucks“. Another option is “Softvelocity sucks ” which gets a few hits. Go on, have a try of those links for a giggle.

Still talking about Clarion, it’s nice to see Clarion recognised in a list of this kind:

The Hello World Collection

Here is why and a way to handle the situation:

Normally the Resizer does its initial resizing of the window controls when EVENT:DoResize first occurs. If you check the ABWINDOW.CLW you can see where the WindowManager Post()’s this event for the Resizer, in the WindowManager.TakeEvent method:

1
2
3
4
5

WindowManager.TakeEvent PROCEDURE
  ! <snip (lots of template code)>
    CASE EVENT()
    OF EVENT:Sized
       POST(EVENT:DoResize,0,THREAD())

The problem here is that when ThisWindow.Open() is called (triggered by EVENT:OpenWindow, see WindowManager.TakeWindowEvent ) the EVENT:DoResize has not yet actually even been fired let alone processed.

On a window with few controls and no messages or other modal events occurring between EVENT:OpenWindow and EVENT:Sized this would not be an obvious problem. The window would redraw so fast as to make this practically invisible. I have not checked but in fact the “PROP:DeferMove” may also come into play.

In this case however I think we need to try and remember that if we are going to do anything “modal” like popping a message in ThisWindow.Open then we also need to ensure that we manually call the Resizer.Resize beforehand (if the window in question has one!).
Oh, and a “Display()” is also needed to make the effect of the Resizer properly visible. This would be the full code:

1
2
3
4
5
6

ThisWindow.Open PROCEDURE
  CODE
  PARENT.Open
  Resizer.Resize()
  Display()
  ! Then you can do a Message() or whatever.

So hopefully this has been of help or perhaps it just confirms something you already knew?

Enjoy!