Sublime Text is a sophisticated text editor for code, html and prose. You’ll love the slick user interface and extraordinary features.

I must say that after a few days of use I totally agree! This is looking like the top contender to replace TextPad, something I have been trying to do for years without any success. TextPad is great but falls short in a few places and until now I have not found anything that comes close to its ease of use and performance…

Of course there is no syntax definition available for clarion files by default so I have made a start on one.

Disclaimer, I am new to Sublime Text as well as GitHub but I will plug away at it for a while and see what comes out!

You should take a look at the official help for creating Syntax Definitions before trying to understand the files in the GitHub repo. When it is a little more mature I will create a package that can be loaded easily, for now you will have to do it the hard way

Grab the code for SublimeClarion on GitHub.

-brahn

Check it out, download the addin and play with the source and get cracking writing your own addins

Thanks for the opportunity Dave!

-brahn

I suppose something I should be doing in the meantime is getting the source code uploaded!

(Also, stay tuned for the ClarionMag article. It should coming any day now I am sure…)

-brahn

C7 Addin Possibilities – The ClarionMag Blog

Thanks Dave for the opportunity, I look forward to seeing the published version and to see what the reaction is. Hopefully the article will inspire some more love for the IDE !

-brahn

For those interested, this is the process:
(This is all triggered from a single batch file)

1. 1. Copy C6 apps to a new directory for C7 conversion
   2. Clean out destination directory of cwproj, sln, etc
   3. Launch AutoHotKey file
   4. Call Clarion7 with the “master” app file as a parameter so it auto opens.

The AutoHotKey script takes care of ALL of the dialogs, including adding all referenced apps to the project and even sets the path of the dictionary to the new root folder (the C6 project has sub folders which have been scrapped for the C7 version)

Once that is done, typically 10 minutes or so on my new machine, I click generate/build and sit back and wait! (yeah, it would be nice to also automate the generate/build… there might be an addin coming up for that to)

This is the AHK script, you may need to adjust it to suit your specific needs. Oh and Win+C will close the script.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

Loop
{
  IfWinExist, Generator
  {
    WinActivate
	ControlClick, OK, Generator
	ControlClick, Yes, Generator
  }
  IfWinExist, , Unable to find the specified dictionary
  {
    WinActivate
	ControlClick, OK, , Unable to find the specified dictionary
  }
  IfWinExist, Select New Dictionary
  {
    WinActivate
	ControlSetText WindowsForms10.EDIT.app.0.378734a1, Global.dct
	ControlClick, &OK, Select New Dictionary
  }
 
  IfWinExist, Upgrade DCT file
  {
    WinActivate
	ControlClick, OK, Upgrade DCT file
  }
 
  IfWinExist, Dictionary Changes
  {
    WinActivate
	ControlClick, OK, Dictionary Changes
  }
 
  IfWinExist, Question
  {
    WinActivate
	ControlClick, &Yes, Question
  }
 
  Sleep, 500  
  if X = 1
  Break
}
ExitApp
 
#c::
X := 1
Return

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