Weird problem with a child process that seems to ignore signals (a bug???)

[handsource-dyko]

I have stumbled on a weird problem and it's driving me nuts. That textinput example I posted on the wiki is part of a library I'm creating and
I have made some more improvements. The issue is when I select text, the selection highlight process is drawn, but afer pasting the selection highlight doesn't seem to respond to a kill signal. Killing the process from the debug console works fine.

The process does NOT use let_me_alone or signal_action. When I kill the process from outside the text_input_handler (the highlight is a child process of it) it kills just fine. Also, the local properties of highlight can still be changed as usual, but it doesn't want to get killed.


You can download the library here from my dropbox:

https://dl.dropboxusercontent.com/u/43665695/malvado-v18-text.zip (see below)

After unpacking, run the "test_textinputs.bat" file. Selecting text is done by moving the cursor to the desired start position and hitting Alt+A, and then move the cursor to the end position and hit Alt+A again. The text is automatically copied. You'll see the text light up in yellow, that's the selection highlight process. To paste text, hit Ctrl. To cut it, hit DEL.  When you hit Alt+B or the right mousebutton, the selection is undone.


All textinput is managed by the textinput_handler () process, and the selection highlight is it's child (called "textinput_draw_selection_highlight") and it's process id in the textinput_hander is called "selection_id".  In the textinput_handler you can find the kill commands in these lines: 805 (is a test), 877, 900, 920, 940, 1013, 1045, 1089 and 1113.


The textinput routines can be found in this file: "dyko_guilib\src\core\dyko_gui_textinput_routines.prg".

I think this problem is quite strange and I have tried it with bgdc / bgdi versions: 21-11-2012 (included with the library) and a much older version: 6-1-2011.



UPDATE:

when  I add the line

Code Select Expand

debugprint ("selection_id status : "+get_id(selection_id)); in the lines

Code Select Expand

IF (((key(_alt) AND key(_b)) OR mouse.right) AND textclipboard.text_selected == TRUE)   /* undo selection. */
         
             FRAME (500);
             debugprint ("selection_id: "+selection_id);
             
             IF (exists (selection_id))
             
                debugprint ("selection_id: "+selection_id);
                signal (selection_id, s_kill); // for some odd reason nothing happens. there is NO USE OF let_me_alone or signal_action!
                debugprint ("selection_id status : "+get_id(selection_id));
             END
             
             clear_clipboard (TRUE);
             textclipboard.text_selected = FALSE;
          END

The get_id returns 0, indicating that the process does not exist. However, it is still visible and in the debug console, I can still see it and I can even change it's local properties such as the x value. This change is also visible on the screen. But if the process is supposed to be dead, then this should not be possible.  :-\

[handsource-dyko]

Sorry, I was too fast and accidently attached the wrong link.  :-[


This should be the right one:
https://dl.dropboxusercontent.com/u/43665695/dyko_guilib.zip

Another sorry: I confused get_id with get_status.  Get_Status returns 1 (dead) but it doesn't appear to be dead. Still I think there is a problem. It's not right somehow.

[handsource-dyko]

I managed to create a workaround by having the problematic process kill itself when a flag is set by it's father process. I think there is an obscure bug in the process system that only occures in some special cases.  Anyway, here's an updated version: https://dl.dropboxusercontent.com/u/43665695/dyko_guilib.zip

This is the problem process with the workaround (it looks pretty ordinary):

Code Select Expand


PROCESS textinput_draw_selection_highlight (int object_array_index, int y, int font, int selectioncolor);

PRIVATE

int text_selection_graph;

int width; height;


BEGIN

   // create a bitmap with the width of the text selection and the height of the font.
   width  = text_width (font, textclipboard.text_selection_buffer);
   height = text_height (font, widget_object_id[object_array_index].inputbox.textstring);
   
   text_selection_graph = map_new  (width, height, USER_WINDOW_DEPTH);
   
   map_clear(0, text_selection_graph, selectioncolor);
   
   // store the width of the bitmap.
   textclipboard.selection_width = map_info (0, text_selection_graph, G_WIDTH);
   
   ctype = c_screen;
   
   graph = text_selection_graph;
   
   widget_object_id[object_array_index].inputbox.selection_kill_trigger = FALSE;
   
   LOOP
     
      /*
         workaround for compiler / interpreter bug. this process is normally created as a child process by the
         textinput_hander () process, for some odd reason that process is not able to kill this process eventhough it
         should. this is a serious bug!!!!!
      */
      IF (widget_object_id[object_array_index].inputbox.selection_kill_trigger == TRUE)
         
         //say ("I kill myself!!!!!!!!! because there is a bdgc / bgdi bug! father process can't sucessfully kill me the proper way! ahhhh!!!!");
         signal (id, s_kill);
      END
      FRAME;
   END

ONEXIT:

   // free resources
   unload_map (0, text_selection_graph);
END




Here's a snippet from the father process "textinput_handler () " (with the workaround):

Code Select Expand


IF (((key(_alt) AND key(_b)) OR mouse.right) AND textclipboard.text_selected == TRUE)   /* undo selection. */
         
             FRAME (500);
             
             
             IF (exists (widget_object_id[object_array_index].inputbox.selection_id))
             
                // for some odd reason nothing happens. there is NO USE OF let_me_alone or signal_action!
                signal (widget_object_id[object_array_index].inputbox.selection_id, s_kill);
               
                // workaround for bug. the process is not killed so, the process must kill itself.
                widget_object_id[object_array_index].inputbox.selection_kill_trigger = TRUE;
             END
             
             clear_clipboard (TRUE);
             textclipboard.text_selected = FALSE;
          END



Both processes are part of this file: "src/core/dyko_gui_textinput_routines.prg".

[SplinterGU]

you must wait to the current frame is complete for all process for real kill a process...

if you send a kill in a process... and in the next process you send other signal to same process, then your process will go back to the life... but if you use, before this signal, between the kill signal and the new signal, exists or getid functions you will get 0, because the process is killed but not really destroyed yet... then, when all frames in all process are complete, then your killed process will be destroyed.

I'm sure that you have a signal (massive or direct) that go back to the life this process.

[handsource-dyko]

Ahh... that explains it. So the order in wich I send signals to the processes is conflicting with each other? Maybe it has something to do with the tooltip process because that one freezes the widget (I choose for that design to prevent the tooltip from "flickering" when you keep the mousepointer on a widget for a long time).

I thought there was something strange going on. There are quite a lot of processes involved, each little detail is handled by a dedicated process.

Btw, I know bennu supports defining up to 31 regions (DIV legacy). I don't know if it's hard or complicated to support more regions in the future.
Is that number an sdl limitation or is it just based on the fact that div only had 31 regions?

I use regions for clipping the text in a textinput, but now I'm limited by the amount of regions. right now the library supports up to 27 textinputs on the screen at the same time, eventhough technically my lib can handle a 1000 widgets in total.

[SplinterGU]

only div limitation.

about signal issue, I did a fix some time ago, that only is in svn, that avoid that we can send signal to killed process... but it don't is on public releases.