By default, when your DAC-application is running, BareED refuses to allow modifications for the archive (project). Such behaviour is good for things like exporting a text file into an other format, or just to make printouts, but it's not useful in case your application should react to/on user inputs. If you encounter such a "challenge", BareED offers you to run your application next to him without blocking him, using a simple "TAG": /* Ask to run beside BareED... NOTE: There cannot be an error - BareED will only reset some internal values - and thus allowing this program to run next him */ PsMsg->pm_ChangeAttr( DAC_ASYNC_RUN, TRUE, TAG_END); It's not wise to toggle the state of your program while at run - because it would confuse the user. If you need BareED non-blocked, use DAC_ASYNC_RUN once and don't toggle it anymore! If you terminate your application there is no need to toggle the state from asynchronous to synchronous. BareED knows - in case your program terminates - how to handle this. You should be aware of BareED's behaviour when your application runs asynchronously to him: BareED doesn't wait for any sign of live from your application - which means that you (respectively your application) is responsible for the information you want to obtain. To clarify this. Once your application runs asynchronously to BareED, BareED completely ignores it, until you use one of BareED's DAC-port functions! In case your application runs synchronously to BareED, BareED doesn't allow any modifications until your application will be terminated. It exists one method to run the application asynchronously to BareED - but also getting informed if something was changed - and prevent BareED from doing modifications, until you again allow them. It was realized with a double buffered message system in conjunction with a "PageUpdate" request. This special "PageUpdate" request is the basic function in order to build syntax highlighting DAC-applications. This technique will be described later. |