How do I hide an error pop-up window?



I think the problem is because what you input to hour and minute is not an integer, but the strings and strings you input are strange. :roll_eyes:

Seems the Screen1.ErrorOccured does not capture that runtime error....?

Wouldn't it be better to just find the source of the garbage data upstream and stop the pollution causing your errors?

Show us your sketch and your exported .aia file.


im sorry but this app is for private to client... ofc i want to show and solve problems with easy way but they are not allowing :cry:

and we tried to solve the garbage data from bluetooth but the goods is ready-made and they are denying our request to cooperate

so we decide to "lets just ignore errors! its not occuring any 'substantial' problems. just showing."


i guess my project file(?) is corrupted at "language bug(ver.nb185)"

information of nb185 : Blocks are missing

but also its happening same with new project. am i doing wrong with that "ErrorOccured"?

i think you are not reading what i asking at all?
or im asking wrong way :confused:
i know i have to insert integer in hour and minute!

so i dont need to (even i cannot)solve the errors. just i need to hide errors.

even tho they can ignore it by click on black space.

so im asking the way with "blocks for occuring errors"

Salman, i really appreciate for your helping and supporting.

but i remember that you tried racism at my "file path topic" some ago.
i asked "how to save the files to random directory" but you told me "korean language path is wrong path" at fakepath. even i showed 3 times that name of path is fake by app and real path is not korean, exactly real path was what you told fix it to.

I'm c++/VB programmer. i know sometimes definite key of problem is in unforeseen part so always thinking I have to explain it in as much detail as possible as problems.
but im confusing you really know the problems and trying to solving right way.

If im acting rude, im so sorry. I know you are a good developer and trying to solving much complex problems. i just wish you know what exact question is.

1 Like

Alright, i think im asking wrong way..

here is aia file to solve..

how can i hide error window after when i click "LET's ROLL"button?

FORYOU (1).aia (1.8 KB)

Mok - you should listen to the advice of ABG. Just ignoring a Bluetooth error is a folly - your App memory will get corrupted and the App will lockup or crash. Worst, Bluetooth errors can crash the device/phone.

It is strange that any device would output poor data and the manufacturer not wish to fix the problem. However, since you know what is garbage and what is not, you should be able to code around that accordingly - currently your code is just using the data without verifying that it is OK.


Hi Chris!

thank you and your(and ABG's) advice is defenitely right.
but this is not corrupted data as bit, just sending buffer data cutting weird part.

for example, device sending string as

  • DATA1,intdata1,intdata2\n
  • DATA2,intdata1,intdata2\n
  • ...
    and cutting every each lines each buffer.
    app is recieving and processing each line data as [start] [data][int][int] [end]

but very occasionally, device is sending like

  • DATA1,intdata1,intd
  • ata2\nDATA2,intdata1,intdata2\n
  • ...
    when buffer timing is delayed(?)
    then my app processing [start] [ata2\nDATA2][intdata1][intdata2] [end]

we asked to device developer to fix it, but they said "most of ppl using it well already. if we fix it to only for you, it may be make more massive problems. even we never heard like that error." ....or paying ton of cost :tired_face:
even we dont need to fix the lines bcz device sending data each second. (i dont need to renewal every seconds)

almost this is showing just "hey, just push [End Application] button!" to user, you know.
ofc i can make a else part for waste corrupted line but it will be make a worthless massive work, if i could hide error message window. so decide to hide it.

okay I understand

Thank you @Mok_Ryun

Really, hmm you look like old programmer :face_with_monocle:

You don't need to apologize to me,:sweat_smile:
actually I have to apologize for giving answers that do not fit what you expect

1 Like

Hi Mok,
maybe you have already tried what i'm saying, but just two hints:

  1. to hide completely any Error popup, you have to apply, as Salman said, the Screen Error pupup empty, without any message. In this case the popup does not appear at all.
  2. Since it seems that the buffer that you receive is corrupted in the middle, are you setting correctly the end of (BT) buffer character ? Have you set the \n character as buffer termination in your BT receiving routine in your app ?
    Something like:
    When you want that your app wait for the complete buffer, normally you set -1 as number of bytes, then you set a \n as terminator in the Designer as below:

Maybe it helps.

Hi uskiara!
i tried right ago with several form(?) of "Screen.ErrorOccured". ofc


but not worked. i guess this block is for high level errors, not low-level. bcz my error is operating not accepted arguments of [ai2]... im sorry..

Surely i set. but this error is pop up when sender sending corrupted.
and as i said

i can make "do not process if ender words are over 2", but there are cases of using two or over... then it will be make works that redesigning whole project. so worthless massive work if i can make it dissappear :sweat_smile:

my BT algorithm :

if (\n in buffer)
    split buffer at [\n]
    int Number = number of [\n] in buffer
    for (int n=0;n<number;n++)
            string dummy = nth string
            if ( [,] exist)
               parsing and make list
               command = 1st of list
               data1~ = 2nd of list~
              command = nth string;

about this. idk its correct :joy:
whatever there is function for make parsing ender word already.
but in this case,

it makes error like as "string in integer" or just corrupted data.

thank you :slight_smile:

Hi Mok,
Ok, but the correct buffer should be as below:

this means that every message should end with a \n, and the \n is set as the ending character (isn't it ?)
So why in you BT algorithm are you splitting the received buffer at \n ?
If this is true, a correctly received buffer should contain only 1 \n so you can discard a buffer with more than 1 \n. without writing so much code.
Otherwise if your buffer is collecting more messages each one ended by a \n (but in this case the \n cannot be the receiving termination character), you can use the "start at" block

to verify whether the position of the first \n is too little and discard that buffer, before parsing the list, so avoiding to assign a string to an integer (or visa versa).
Keep in touch. :smirk:

PS... and what about the
block, again before parsing each element ? If is not a number you skip that buffer...

It is not a massive work to verify incoming data. Can you give a verbatim example of data received ('good' data)?

Hey Uskiara, the delimiter byte is more commonly 10 rather than 13. Since Mok has no control over what the sending device, trial and error is necessary to discover the delimiter, if indeed there is one.

However the issue is not likely to be with the device as Mok has assumed. It is highly likely that the App is not processing the data fast enough, causing an 'overlap' of data in the buffer.

Hi Chris,

Yep !!!
But, according to what he has written, any message should be ended by a \n, so by setting a \n as the stop receiving character should exit the receiving function.

  • DATA1,intdata1,intdata2\n
  • DATA2,intdata1,intdata2\n
    But it seems that is not the case.

Perhaps he could modify the receiver: instead of waiting for a terminator character, he could wait until the buffer is completely emptied...

Anyway, I'm with you, by solving the problem why the data are corrupted would be the best solution, but since he asks for a "quick and dirt" solution... :slight_smile: :slight_smile::slight_smile:
Ciao, ugo.

1 Like

Beware of CR (13). That is used mostly in Windows and devices that expect to talk to Windows.

yes I agree with both of you but, as Chris said, if the device is sending just the CR as message terminator, Mok has no chances. So my suggestion is to wait until the transmission ends for a while and gives a breath to the app...
(probably... :grin:)

The device sends data very well. The problem is that you receive this data badly and process it badly, and this is where the problem arises.