GuiEdit/GuiButton: puzzling errors when clicked several times

I would like to convert some part of my good old Gfx* code using Gui* functions, but I'm still learning how to use them. So I wrote a few samples to get a better understanding. In one case I met unexpected errors.

Basically the toy GUI consists in a GuiButton and a GuiEdit. When the button is clicked, the Edit content is changed (simply prepends "You typed: "). Here is the core :

idMyButton = 2; 
idEdit = 3;

// GUI Creation
GuiButton( "MyButton", idMyButton, 10, 20, 100, 30, notifyClicked );
GuiSetColors( idMyButton, idMyButton, 2, colorWhite, colorBlue, colorBlack);

rc = GuiEdit( idEdit, 140, 20, 200, 30, notifyEditChange );
if( rc == guiNew ) GuiSetText("Initial Text", idEdit ); // guiNew / guiExisting

// Events handling
for ( n = 0; (id = GuiGetEvent( n, 0 )) !=  0; n++ ) { // get the id of the event
	 code = GuiGetEvent( n, 1 );

	 switch ( id ) {
		 case idMyButton:
		 // do something
			if (code == notifyClicked) {
				// BUG ! error if button clicked several times (4, 5, more...)
				// Or the button may disappear entirely ! 
				// In the latter case I get an error 
				// "The control with given ID does not exist" next line:
				GuiSetText("You typed: "+GuiGetText(idEdit), idEdit);

		 case idEdit:
		 // do something else


// Finally
Title = "You typed: "+GuiGetText(idEdit);

Nothing fancy. Except sometimes the Edit box disappears after a few clicks on the button...and I get an error "The control with given ID does not exist" line 24. I guess the Edit box is destroyed/not (re)created by the script. I'm flabbergasted, I can't understand what I'm doing wrong. Maybe some good soul knows the answer...(Below a screenshot EditBox missing and another with an error...)



It works perfectly fine here. I clicked thousands of times with high frequency and nothing that you described ever happened. (Other than your code constantly appends text and you may hit Edit field limit on length). Check if you are using latest version (6.35.1).

1 Like

@alligator, I was able to reproduce it here (tested version 6.30.5 - 32 bits - Windows 7 Pro).

By the way, this is something I already saw some time ago while I was playing a bit with the GUI controls (but was not essential for my goa,l so I did not care too much about it).

It seems to me that this issue is happening since you are using one GUI control event to actually trigger another control event: at each click of the button you change the edit text, and this, in turn, trigger a notifyEditChange.

If you disable all the edit notifications (using zero as the notifyflags), the error "seems" to disappear (it does not happen regularly so it is very difficult to say with certainty).

But obviously, when @Tomasz will be able to reproduce the issue, he will surely provide a solution to avoid it.


@beppe, you nailed it ! Without notification, no error occurs.
@Tomasz it's weird, tested on AB Pro 64bits 6.35.1 on Win 10 Pro 1909, AMD zen2 (ryzen 5 3600)
Just tested with AB Pro 32bits on the same pc, same problem.
Anyway I can live with it, it's easy to circumvent. Thanks a lot.

1 Like

@Tomasz, I noticed that this seems to happen more frequently when I load my CPU (I did playing multiple HD video streams).

(This test was done with version 6.31.0 64 bit).

I added a single "A" at each click, so it seems not to be related to the length of the edit text (actually, it happened after 20/30 clicks).

I have run this all the time and click thousands of times and it does NOT fail on my end, here is a video:


Maybe 3rd party program (video player that you are using to play video) messes up something in Windows.

As for editChange notification - you should be careful not to change the content of edit field in response to editChange because you will get endless loop of notifications as setting text of edit control from your program triggers notification.

1 Like

@Tomasz, maybe the issue is specific to some PC configuration, but I still suggest to try it again on the least performant PC you have.

I just tested the @alligator code sample on a old Windows Home computer (Acer Notebook 5738 with only 4Mb Ram Intel Core2 Duo P7550 - with an Integrated ATi Radeon 4570 - 512MB) using Amibroker 6.30.5 - 64 bit.

Here below what I have seen:


In the image (captured at 15 fps) I applied the original formula on the top pane and in the second one I removed the "edit change" notification. I slightly modified the OP code to show in the title the length of the GuiEdit text

As you can see, where I removed the edit notifyEditChange (replacing it with a zero) there are no issues and the char counter progresses as expected at each click and the controls are displayed properly.

On the top pane the Gui controls flicker (they disappear sometimes) and the counter from time to time is reset to the initial value (12) and randomly we also get the error.

I hope it helps you to track the reason for such different behavior.

I performed more experiments in various setups. First on my trading station I never use streaming/videos or anything too heavy. I can reproduce it with nothing but AB & TWS running and a CPU load below 5%, memory used at 33% (AB is wonderfully efficient :slight_smile:)

I changed the sample code & found that it occurs simply by pressing a key & keeping it down inside: the button is unnecessary to reproduce the problem.
Also it seems to happen quite rarely when AB is disconnected from TWS. So load can play a role, but 5% vs 3% frankly...

_SECTION_BEGIN("GuiEdit issue");
// cf

contentId = "LastText"+GetChartID();

/* // Uncomment this one to test fast-clicking the button
idMyButton = 3;
GuiButton( "Clear", idMyButton, 10, 50, 100, 30, notifyClicked );
// */
idEdit = 2;
// rc = GuiEdit( idEdit, 140, 20, 200, 30, 0 ); // No problem of course here // XOR:
rc = GuiEdit( idEdit, 20, 20, 200, 20, notifyEditChange );
if( rc == guiNew ) GuiSetText(StaticVarGetText(contentId), idEdit );

change = 0; content = "";

for ( n = 0; (id = GuiGetEvent( n, 0 )) !=  0; n++ ) { // get the id of the event
	 code = GuiGetEvent( n, 1 );

	 switch ( id ) {

		 case idEdit:
			content = GuiGetText(idEdit);
			// change of Edit Box content AFTER consuming all events in the queue "fair"
			// "fair" but generates a new event, appended to the queue etc
			if (content != StaticVarGetText(contentId)) change = 1; 


if (change > 0) { 
	content = StrToUpper(StrRight(content,10));
	StaticVarSetText(contentId, content);
	// Everything goes havoc with the following line...ISSUE HERE NEXT LINE>>>>
	GuiSetText(content, idEdit);
	// Keep the key pressed for a few seconds to make it happen

Title = "["+StaticVarGetText(contentId)+"]";

It seems to me it's a Windows issue, unability to process messages (message queue limit ?) or something with creation/destruction of controls. Anyway thanks for your help & time. This issue is puzzling but easy to avoid but other people could get it so I hope the thread will help them.

A quick & happy note: the issue described above is fixed on my pc. I've upgraded to Amibroker version 6.40.0 but I'm not sure it's the reason: it could be due to Windows 10 or video card driver updates too. Anyway thank you @Tomasz for recent fixes

Neither Windows or graphic card driver has anything to do with that. It was your formula causing that. And now AmiBroker includes protection against incorrect formulas. The reason is listed in 6.39.1 change list:

  • calling GuiSetText from AFL formula caused notifyEditChange notification to be sent. If user formula responded to notification with another GuiSetText this could create loops. Now notifications are silenced if changes come from user code
1 Like

This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.