Any Ways to Stop the IDE from crashing from embed editor?


I just want to ask if do you know of any ways to prevent the IDE from crashing upon saving of code from the embed editor? I’ve lost count on how many times this happened to me for the past 10 years of me using Clarion.

Or do I just have to “deal with it” because SoftVelocity will never fix this productivity-killing crash?

Thanks in advance.

What version are you using?

1 Like

Greetings -

The only way is to slow down your typing by a breath. Enter into an embed, take a breath. Wait for things to stabilize. Add your code into the the embed, save to exit, take a breath, wait for things to stabilize, before you click on anything else. When things are loading and saving, there is a yellow marker on while the operation is happening, which goes away when the operation is done. You click too fast when you go in and out of the embeditor, and you can consistently kill the IDE. Specially when you are saving and on the way out and click on anything else. Before you click, take a breath.

So it is a question of learning the body memory timing, and you will kill the IDE a lot less. Slow down and do not click on something on the way in, and most importantly, on the way out. You will have to “deal with it” since this has been going on for years, and SV has not dealt with it yet. That we know about.

I think it is some type of (a wild guess) critical lock missing somewhere, thread interaction, or wait/release problem. SV is the only one that knows, and the fix does not exist yet.

Good luck with your breathing and timing.

Roberto Artigas


Good question by JSlarve. I am on Clarion 10, 11.1 at work. Clarion 11 at home.

I’m on Clarion 11.1.13815 right now.

The thing about the IDE crashing from an embed editor is that it happens inconsistently. Sometimes, I can exit out of embed editor just fine, other times, the IDE will just crash out of nowhere even if I didn’t do any changes to the code. Feels like I’m playing a game of Russian Roulette.

Most of my work nowadays revolve with desktop applications and the crash is more of a common occurence on browse and form procedures. Oddly enough, back when I was just making an webserver app with NetTalk, I haven’t had any crashes or whatsoever.

My assumption is that there’s really something wrong with the Window Designer of the IDE.

the short answer is;
Don’t the the “embed tree” to edit embeds. Rather use the Embeditor.

This is for two reasons;
a) as you noted the editor can occasionally crash when opened from the tree, or from the window-designer then tree. So If nothing else changing your habit will stop you losing code.

b) When you embed from the tree you lose the context of what you are doing. In other words you don’t see the code that is being generated before, and after your embed code.

By using the Embeditor (App trr, right click on the procedure, Embeditor Source) you start to get a feel for the generated code. You’ll learn how to navigate around the CLW (Ctrl-F is your friend) and you’ll gradually get more and more familiar with the generated code. (There are toolbar buttons in the embed editor for moving around quickly, to your next embed code, and so on).

Ultimately this makes you a much better programmer, (because you’ll see more of the language, and hopefully be curious when you see a new command or code block etc) - you’ll be a much more efficient embed coder (because you’ll see what else is in there, what’s available to you, and so on.

It is by far the single best habit you can adopt if you want to take your programming to the “next level”. If you don’t then you’re always just writing magical bits of isolated code at semi-random places in the procedure.

Oh, and it never crashes on saving, so there is that…


Thank you for the insight. I admit that I really have a habit of editing code from the procedure’s tree instead of going to the embeditor. In fact, everyone in our office does this and then I’ll just hear someone let out a sigh of disbelief in the middle of coding, me included.

And because of the crashes, I developed the habit of copying my code into somewhere else (e.g. Notepad) before hitting the Save button and hope for the best.

Hoping that by the time I’ve fully adapted to new habits, the crashes will be fixed by SV.

I want to say this constructively and gently. This is not meant as a judgement, but rather as constructive advice.

You can only control what you can control. You can hope for others to do things, but hope is not a strategy. Maintaining bad habits (which you control) is on you. Not on SV. The fact that the embed tree loses data is outside of your control. Additionally, it is a “worse” way to program, so quite honestly, the fact it loses data or not is irrelevant.

It doesn’t really matter what SV does, or what your co-workers do. It only matters what you do. If you make a choice to use the Embeditor, then you’ll grow as a programmer, and be better for it. If you choose to stick with bad habits, which you are know are bad, and which (co-incidentally) cause code to get lost, well, that’s on you, not on SV.

Again I’m saying this to affirm that this is under your control, not theirs. This is 100% your choice, and what they do is irrelevant. Ultimately, self-improvement is a decision that only you can make for yourself.


One thing I try never to do (and sometimes do it anyway and regret it immidiately) is that I don’t open a window designer, click on a field and go add or edit and embed under that control. It crashes CW almost always since forever. Entering embeds thru window designer is a no-no in my book.

I hate it but I live with it.

1 Like

I find all this very interesting and can only say that, interestingly, I have no difficulty with embeds within the window designer.
I have quite big window structures where a lot of action is done on different controls (buttons, entry fields, lookup fields and so on). Within these big windows structures it is much easier to find the correct embed where I want to add functionality instead of using the embeditor.
And again I can say that I do not have errors at this point.
I’m mainly using Clarion 8 but also latest Clarion 11.1.
For other procedures I also like to use the embeditor because it is then faster to switch between different embeds.

Maybe the crashes and or lockups have to do with some settings in the IDE options dialog.
For example, I have not enabled “code completion”.


Pretty much always use the EmbedEditor from the procedure. Especially, do not go into embeds from the Window Designer. This is a really easy way to crash the IDE.
I have not seen crashes from using the Embed Tree, but I almost never use it.

1 Like

What I have found is that you cannot add a control and then immediately go into the embed for that newly created control.

There are times when you can but I just don’t and it is particularly easy to make the IDE crash in the situation if you have added a control, and the ID has not yet loaded the class headers - I am referring to the progress bar that you see on the right lower side of the IDE the first time you go into an embed or do a few other activities.

If you create a control before that is done, you can pretty much crash the IDE every single time by double clicking on that new control.


1 Like


since C7 until C11.1 i encountered this as well on every Clarion-Project.

Especially when you are in hurry, distressed an have to get things done, it crashes reliable on saving.

Made me crazy for years!!

Take a breath is a good advice :wink:
And maybe the best advice, is to use the embeditor.

Ralph Rathmann

Taking all the wise advice above into consideration, there is some wiggle room I’ve found.

I’m running C11.13401, and have been for the last few years.

Am developing mostly Nettalk webserver apps, but also some plain old desktop exes.

@Bruce 's note about upgrading habits to see all the code around you, matrix style, is a big deal. I’ve found it to be of critical importance in my continued growth as a dev.

And every time I’m zooming with Bruce and go through the embed tree, we have a conversation about the embeditor.

Now. I have a very good (to me) reason why I choose to sometimes (but not always) go through the embed tree.

There is a magical option that forces the embeditor to always be opened (when you go through the tree).

Alongside the “have patience” protocol, being able to open up a tree dialog and see where I’m going - this helps me immensely.

Some of my procs, netwebforms especially, are crazy large - and while I could train myself to think about the exact naming of the place I want to go in that great big old pile of code - I find it easier/quicker to open up the embed tree and open through there.

(Note too you can skip through to embed code in the embeditor, but if you have a lot of embed code in many different places, this loses it’s speed usefulness in my experience)

Because it opens into the embeditor anyway, which is always where you want to be (always).

In the last few years I have not had a single crash when opening the embeditor through the embed tree (and strictly adhering to the patience “single click at a time” protocol, alongside another one - only open 1-2 apps at a time).

Have had other crashes, but mainly to do with trying to have too many apps open at the same time.

Right-click vew source is my main investigation tool, it’s simpler to get in for sure.

But sometimes, and you need to go through the furnace of experiencing the crashes to figure it out, whether this will work for you - sometimes I find it more helpful to go through the embed tree (as long as you are going to the embeditor itself).

That’s my 2c.


+1 on not going into embeds from the window designer. Find the embed tree mostly works for me. Haven’t felt the need to go all the way to the embeditor like Bruce.

1 Like

What I find interesting, sad, and likely true, is the implication that SV will never fix this included feature and how the expectation of being able to use it becomes a bad habit that long time Clarion users simply must learn to avoid.

when using the embed tree, i usually put a " !here " mark, and then go to the embedditor, look up the !here and then write the code.

never have problems that way