Introduction My goal has always been becoming a researcher. This has been the main driving force throughout my studies. But being a scientist means more than just processing a certain knowledge and doing experiment, it also involves developing many competences and being able to face up to the challenges this profession has to offer. These include being able to conceive, create and adapt the material required for experimentation. The tasks required of a scientist are varied and can go from programming and electronics to plastic or wood crafting. As a scientist I want to be as polyvalent and self dependent as possible. As such my Master II “Compétence Complémentaire en Informatique” has given me the opportunity to greatly develop my computing skills. Among others I have acquired significant experience in several programming languages and I have learned how to carry out a computer project. The end of semester internship was the perfect opportunity to put my abilities to the test and see how I could fair in a real life situation. My internship was done at the scientific laboratory INSERM Unit 666: Clinical Physiopathology of Schizophrenia. My main task was to fully computerize the experimental protocol of a scientific research project. In other words, I had to create software providing an interface through which an upcoming scientific experiment could be carried out. In parallel, I would be carrying out more typical research work with the real prospect of continuing my studies in the form of a thesis. Throughout this report I will relate the various stages of development and challenges overcome during the realisation of the project up to the conception of the final program: “Grain Size 2008”
Context INSERM Unit 666: Clinical Physiopathology of Schizophrenia is a research laboratory affiliated to the Civil Hospital of Strasbourg. Forming part of the Psychiatry branch it specializes, as its name suggests, in the study of the mechanism underlying the syndrome of Schizophrenia. Directed by Professor Jean-Marie Danion the laboratory comprises of two research teams with a staff total of five researchers, four PhD students and six interns and technicians. For the purpose of my internship I integrated the team under the supervision of Doctor Elisabeth Bacon in the dual position of programming technician and voluntary research aid (intern). Our particular field of study was the investigation of the particularities of metamnesic processes in the schizophrenic patients. The concept of metacognitions refers to the supra-ordinate mental processes involved in the elaboration, monitoring and control of other subordinate cognitions. They are essential for the initiation of basic cognitions (such as memory, thought, perception…) as well as ensuring the smooth progress of the associated functions. We talk of meta-memory as the metacognitions related to memory. They have an unsuspected yet essential role in proper memory functioning. Whereas basic mnesic processes (encoding, storing and retrieval) are used to call up souvenirs and knowledge, it is through the underlying meta-mnesic processes that we are able to initiate the search of souvenirs, control their veracity and select the most adequate souvenir to be included in our conscious line of
1
thought. Meta-memory is also commonly referred to as “knowledge about knowledge” as it depicts our capacity to evaluate and chose the most appropriate stored thought out of the myriad of thought a person possesses. Our research is centred on subjects afflicted with schizophrenic syndrome. Schizophrenia is can be defined as a group of psychotic disorders characterized by disturbances in thought, perception, affect, behaviour, and communication (DSM IV). With schizophrenic patients, impairments in memory have constantly been reported throughout scientific literature. These subjects show lower memory scores in a series of test. But it is actually debated if these lower scores reflect effective memory loss or if they can at least be partially imputed to inefficient metamnesic processes. The aim of the forthcoming study is to explore further metamnesic processes and more specifically to determine their particularities in schizophrenic patients as compared to normal subjects. To do so, an experimental protocol was devised whereby we create a situation where subjects are given either limited or full control of their response following a general knowledge question (adapted from Goldsmith and al. “Strategic Regulation of Grain Size in Memory Reporting”. Journal of Experimental Psychology 2002 , Vol. 131, No. 1, 73-95). The aim being to explore how subjects react and adapt their answer in terms of precision (Grain Size), latency (Reaction Time) and perceived accuracy (Confidence Level). The experiment will be done in two phases. Initially schizophrenic as well as normal subjects will be confronted to a series of general knowledge questions to which they could respond quite liberally, even giving approximate answer covering any desired range (Phase 1). Than in a second phase, we constrain the response criteria by allowing only exact answers to the same set of questions. After each question, once an answer is given we also evaluate how confident the subject felt about their previous answers (Confidence Level) in terms of a self evaluated percentage of correctness. Generally normal subjects tend to adjust their answer in function the knowledge that they perceive to have concerning a topic. Their answers are more precise (finer Grain Size) and they use less time reflecting on questions when they feel that the answer is known to them. As mentioned earlier, this ability to access ones knowledge, control the precision of response and produce what one considers as the most adequate response depends extensively on their meta-cognitive aptitude. Do schizophrenic patients share the same abilities? This study will try to find out. Our hypothesis is that given a less effective meta-cognitive process, schizophrenic patients, will fail to adapt their answer with response constraints. Although not necessarily less accurate (the answers may be correct), their answers may be inadequately imprecise (very large grain size) and may show little or no relation to their perceived knowledge of the subject (as measured by their confidence level). They may also fail to adapt strategy or precision when confronted to same question but with higher constraints. Lack of control over answer with the new demand may also lead to reaction times and answer precision no different from that of the first condition.
2
Programming Prerequisites As a programming technician my task was to conceive a program capable of automating the experimental procedure presented above. In such I was to carry a complete computer project from conception to modelling up to final implementation. This software would afterwards be used to assist the experimentator in carrying out the experiment. As my director was not particularly concerned with programming, my internship took the form of a commissioned project. My actual presence at the laboratory for this task being dispensable this aspect of the internship essentially constituted in home-based programming. This provided me the chance of working in a familiar environment and offered a certain freedom in organizing my work. Nevertheless, I was to be assisted by Patrick Gries, lab information technician at INSERM 666. Whenever I faced a technical difficulty I could contact or meet Mr Gries for invaluable help and advice. The necessary tools were also provided by the hospital. The required program was ordered and laptop computers were put at my disposition to facilitate my task. Clarifying the Demand of the Program The first step to the project was to clarify the demand for the application. After a couple of discussions with my internship director we had managed to outline the general structure of the program. Through these discussion several functional requirements were identified which I have listed below; -
In essence the software would provide an interface to display a set of questions, record the experimental results and provide a neat structured résumé of the results obtained at the end.
-
The interface was required to be simple and intuitive at use, such that “…even a computer novice could actually run the program.”. Yet the program had to be sufficiently professional so as to be credible, and also offer a certain degree flexibility and performance.
-
The general look was to remain sober so as to seem authentic and so not as to daunt somewhat impressionable schizophrenic patients.
-
A specific interface was to be provided for collecting information concerning the subject. This would take the form of a screen with a series of text fields to fill in and check boxes to choose from. This screen would later be referred as Subject Info Screen.
-
There would be two contiguous phases to the program during which the same set of questions would be presented. In the first phase a ranged answer would be tolerated whereas in the second phase only exact answers were permitted. Although visually similar, the two phases would programmatically differ in the way given answer would be treated. The program would have to be able to account for the various types of
3
answer (ranged, exact) provided according to the phase of the experiment it was performing. -
After each question the confidence level attributed to the answer (as a percentage) was to be determined. A scale would be provided for answering.
-
Question items to be used in the experiment were to easily accessible and modifiable. An Excel sheet (QuestionFile.xls) would provide the list of questions as well as other relevant data. The program was to offer the possibility of adding or removing questions simply appending this file.
-
The answers collected would actually be manually inputted by the experimentaor (after verbal response of subject), according a three step procedure as demanded by the director (discussed below).
-
At the end of the experiment, all results, reaction times and confidence level scores were to be compiled in an excel sheet.
Other less fundamental aspects of the program were discussed such as the addition of a demonstration mode; so as to familiarize the subject to the protocol before the real experiment, as well as the possibility of an interrupt function (escape key) as judged practical. The latter would permit temporary or complete suspension of the experimental procedure any time during the experiment. Finally we pursued with the establishment of the general layout of the program. Shown below (Fig 1.) is a representation of how the application was conceived with respect to the program requirements. The images are actually those used during the program and can also be referred for as a visual representation of the software.
Introduction Screen
Show question
Subject Information Screen
Main Experiment ScreenInput answer
Confidence Level Choice
Figure 1: Visual representation of the major steps of the application. Are shown are the Introduction screen, the Subject information Screen and the three steps of answering a question during the Mian Experiment.
4
Choice of programming language Having determined what was expected of the program and its general layout, the next step was obviously to choose of programming language to be used to make it all possible. This critical choice would determine the entire structure of the program and the way it would generally function. The choice was based on my actual proficiency and preferences concerning various programming languages as well as how adapted each language seemed at meeting the required demands. In the end it came down to a choice between three different programming paradigms; Java’s object-oriented programming, Visual Basic’s event-driven programming or C-code imperative programming. Based only on preference, I would probably have gone for C code. It is by far my most appreciated programming language and one with which I feel particularly at ease. But since the software in creation would seem to be particularly graphic intensive, I have declined doing so as its graphical programming in C code could turn out to be quite strenuous given my actual level. As far as object-oriented languages goes, Java language handles graphical programming quite elegantly. The various graphical libraries (Classes) proposed, would be quite sufficient for the needs of the program. But having considered the fact that the program also required extensive connectivity with other programs, and particularly Microsoft Excel and Windows, Microsoft Visual Basic (event-driven) would seem to the best candidate was. This programming language is reputed for creating graphic interfaces. And being a Microsoft program, we can expect a large support for inter-program communication (Java would have been just as efficient at communication but less dedicated to those particular applications). As I have never really programmed in Visual Basic (VB) I also consider that through this choice, I would have a good opportunity to learn a totally new programming language. Discovering VB Albeit my modest knowledge of BASIC and a few minor Excel macros, I could hardly say that I knew how to program Visual Basic. I was left to discover a whole new way of programming. My first step was to document myself through the VB dedicated literature so as to get a general idea of the Visual Basic programming style. I initially went through a couple of books (“Visual Basic 6”. Rougé ,D (1998). Paris: Sybex) regarding VB, but this proved to be disappointing experience. The literature I found merely covered the very basic of the programming language; aspects that I already knew or could have deducted via my knowledge of other programming languages. When it came down to tackling real practical problems, books provided little aid. So at a certain point I decided to take a more direct approach to discovering VB. I decided to learn through experimentation. By this I mean I would learn to program in VB by actually trying out programming. This more or less trial and error style would have me creating more and more complex procedures until I considered that I sufficiently understood specific aspect of VB. In doing so, a significant part of my internship was dedicated to trying and testing out various commands and functions that I considered relevant to the project. The internet proved to be an invaluable source of knowledge. The various VB dedicated sites found provided thorough explanations to nearly every aspect of the VB language.
5
Fortunately, VB also offered a really clear and clean integrated development environment (IDE). It was simple to jump right into programming and a special note must also be made concerning the extremely powerful debugging capacities offered by VB. Both of these largely contributed to making my progressive learning experience possible. Although such a frontal approach might have seemed risky at first, in the end it proved to be quite a gratifying experience as I progressed with each achievements. I personally believe that I have actually learned more this way than I would have, had I stayed to the more classical academic approach. Presenting VB Visual Basic (VB) is a high level event-driven programming language from Microsoft Corporation. Visual Basic was derived from BASIC and enables the rapid development of graphical user interface applications. VB provides support for a range of functions such as databases access (OBDC) and basic object-oriented control. Being a high level program VB has been designed to be easy to learn and use. A high degree of inter program connectivity is assured through the use of OLE (Object Linking and Embedding) and DDE (Dynamic Data Exchange) protocols, giving access to the use of external program templates as well as a large list of external command libraries. Windows API (Application Programming Interface) are also available for using Windows type applications. As an event-driven programming language the flow of the program is determined by sensor outputs to user actions (mouse clicks, key presses). These actions or events lead to the initiation of specific code implemented by the programmer (event handler routines). In other words, event oriented programs generally start by simply providing an interface and than waits for an action to be committed. Depending on the action (if several are possible) specific event handler routines are performed until the activation of the next sensor event. A typical example would be a window with a button (interface with a sensor component) which stands idle on the screen. Clicking the button (Button_Click event) calls upon a code sample which may fore example bring about another window with another series of sensor components to chose from. This approach makes for a very user oriented flow of the program and seems to be ideal for inter-active graphical applications such as the project at hand. VB programming architecture is structured around the creation of interconnected forms (windows). Within each form the programmer can add various components (buttons, text field, check boxes…) which act as action listeners each having their own sets of eventhandlers. Generally each form is designed to assess one major aspect of the program. This is partially due to the exceptive nature of such programs. For more complex programs a form will usually do its task and then call upon the next form to progress along the program. The basic event-handling routines are all provided by VB. The programmer writes additional lines of code for more functionality to each of these events.
6
Conception Program architecture As mentioned earlier, VB program architecture is Form centred. A program is constituted of a series of interconnected forms portraying each major step of the application. Each of these steps is (generally) associated to a graphical interface where the user can control function initiation and program progression. Displayed below (fig 2.) is the overall program architecture devised for Grain Size 2008. In the figure we can see the sequence of each Screens/Forms (depicted as square boxes) as well as a series of functions sub routines (oblong shape) associated to each of them. The program starts with an Introduction Screen giving access to the various functions of the program. Various MenuBar_Click listeners will pick up the experimentators demand and initiate the actual experiment or other accessory subroutines. The experiment launches with the Subject Info Screen where the experimentator can fill out information regarding the subject. On validation (Button_Click) certain subroutines will verify the format of the inputted, store the various data if correct and finally initiate question upload. The Question Recovery and Sorting form will then access the Excel question file and recover the questions and other relevant information. The questions list obtained is also sorted if necessary before the program moves on to the next step of the experiment. This form operates in the background and is not seen by the subjects. Once its task over, it creates an auto-event loading up the subsequent form. Once in the Main Experiment Screen all the questions will be presented to the subject and answers recorded for that phase (Form_Keypress, Textbox_Change and Button_Click listeners). As expected progress was generally linear up to this point. The Main Experiment Screen on the other hand initiates certain loops reflecting the iterative nature of question presentation and data collection protocol Only afterwards will the Inter-Phase Screen be loaded (hiddenButton_Click ; see below) and all results saved to a formatted Excel file. The Inter-Phase Screen will redirect the program back to Main experiment Screen if all the phases have not been done or terminate the program otherwise. With the overall program architecture determined I could finally consider starting the actual coding of the functions. From the architecture itself (fig 2), it was relatively easy to recognize most functions which required implementation; • • • • • • • • • •
Interface creation Data collection and transfer routine File access routine to upload questions Question presentation routine Application of answering protocol Reaction time control and uptake Verification and collection of given answers Confidence Level interface creation Inter-phase form creation Creating Result file
7
Progress
Inroduction Screen - Function choice - Launch - Demo - Edit Questions - Set Save file
Edit Questions
Demo Intro Screen
Set New Savepath
Check Age Format
Subject Info Screen - Filled in subject info - Confirm Button pressed
Questions File
Subject info Screen Check Name Format subject info Store Store date info
1
Access Questions - Invisible Question Recovery form
Sort Get Numer of questions Store Question list Store Question info Create Result set with Question Info
If Randomisation set
Question Recovery and Sorting
Main Expeiment Screen
Experiment Screen
- Enter pressed (1st)
|Response Text Box If EnterCount = 2
Inkey : Timer 2 Off
- Response Box activates - input characters (stops timer)
- Validate with Enter (3rd) - Confidence Level interface shown - Next question shown - Repeated until out of questions for phase
If EnterCount = 1
Enter Key : Show question Timer 1 On
If EnterCount = 3
- Shows question - Subject reads out - Enter pressed (2nd)
If out of questions
Enter Key : Verify and cut Answers Reset Timers Activate CL Set Next question
Enter Key : Timer 1 Off Timer 2 On Activate response Textbox
Store Reading Time
CL Button Choice
Store Reflex ion Time Recover inputted answers Recover Inputted CL Append Result Set
8
Re-activate Main experience Screen with phase count incremented
If out of questions
- Answers for phase saved in Excel Worksheet in backround
Inter-phase - Shows inter-phase message - Continue button clicked
Save Results : Create or Activate Excel Workbook Format WorkSheet Transfer Result Set to Workbook Move to next Phase
Inter Phase Screen
- passes to next phase and reactivates Main Experiment form unless last phase done - Message of thank shown - Button ckick to End experiment
If not final Phase
End
Figure 2. General schema of the program showing the order of form activation (Rectangles), the main functions (Round edged Rectangles) and the information flow (small text). The flow chart covers only the progress of an actual experiment but other functions (Demonstration, Edit question and change save path) are displayed as sub functions of the Intro Screen form. Important sections of the flowchart are marked by numbered bullets and will be discussed further on. We may notice that the program is generally linear, except at the Main Experiment form (bullet number 5), where in an inner loop flow is determined by the number of times the Enter key has been pressed (alternates between 1 and 3) and an outer loop which controls the question count (flows out only when all questions have been presented). On the far left, there is description of the progress of the experience as seen by the experimentator.
9
Function implementation Now that the overall programming scheme had been determined I was able to concentrate on tackling individual programming codes. In the sections below I will be addressing each of these functions individually. Creating a graphical interface (or screen) One of the main strength of VB is the facility with which one can create graphical interfaces. Most aspects can be dealt through its own user interface. One simply has to add a new form to the project and drag and drop various constituents (such as text boxes, labels, buttons….) from the toolbox into the form. At runtime a window containing all the components will be automatically created. Each component would have its own set of properties (size, font, caption….) which were modified through the programming interface or by using dedicated code. Event handler could be added to each component (linking operated by VB) into which routines coded to ensure proper response to actions. Generally defining the layout of the form with all needed components was the first step to creating a form, prior to any programming. Sometimes little or no programming was required for interface creation apart from manual adjustments of size and position. Most characteristics of a particular form/screen would be summed up in the Form_Load event such as the sample code shown from the Introduction Screen Private Sub Form_Load() ‘Remark: Used to centre and size the screen. Left = (Screen.Width / 2 - (Width) / 1.75) Top = Screen.Height / 2 - (Height / 1.5) Height = 6000 Width = 8000
‘Screen.propety refers to System Screen
‘Remark: Resize image component and loading a background image into it Image1.Height = 5375 Image1.Width = 7875 Image1.Picture = LoadPicture(App.path & "\Grain Size\Paramétrage\Pictures\BKpic.jpg") ‘Remark: Screen title Caption = "Projet INSERM Métamémore 2008" ‘Remark: Setting other variables to default ORDRE = False SAVEPATH = App.path & "\VBResultFile\"
‘Randomization function set OFF ‘Save path set to default
End Sub
10
Collecting and transferring inputted data Once the program initiated, most interaction with the software involved interacting with buttons, text fields or check boxes. Most of these components have properties returning their own values making data collection quite straightforward. For a textbox, it would be the “text” property (textbox1.text return a string), while buttons and option boxes have a “value” property (commandbutton1.value). Where necessary, scripts were added to the component event handlers to enhance their data recuperation performance. Related information were regrouped and stored in dynamic arrays so as to facilitate handling afterwards. These arrays were global variables (declared at the beginning of the Module Form) making them easily transferable throughout the entire project. The justification was to avoid what can considered a bug inherent to VB hindering normal data transfer between forms and functions which will be discussed a bit latter. Some of the data collected had to be treated prior to storage using dedicated functions. This was the case for example when collecting subject data (Subject Information Screen) or subject response (Main Experiment Screen – see below). The format of the name and age given in the text fields had to be verified so as to coincide with the naming protocol used by the laboratory, before storage. In the program the on button validation (Button_Click event) the program would call upon ‘checkNameFormat’ and ‘checkAgeFormat’ function before returning the results. Essentially, these functions use the embedded isNumeric(string) function and a created isAlphabetic(string) to verify each character of the inputted text. '********************************************************************* 'Function that verifies that string is composed only of alphabetic characters 'returns true if all characters in a string are alphabetical 'returns false otherwise or for empty string Public Function IsAlphaBetical(TestString As String) As Boolean Dim sTemp As String Dim iLen As Integer Dim iCtr As Integer Dim sChar As String sTemp = TestString iLen = Len(sTemp) If iLen > 0 Then For iCtr = 1 To iLen sChar = Mid(sTemp, iCtr, 1) If Not sChar Like "[A-Za-z]" Then Exit Function Next IsAlphaBetical = True End If End Function
11
While data transfer from components was relatively easy, the transfer of normal variables in between Forms and functions (event handlers) caused much more problems. Contrarily to what is stated in the manual, simply declaring a variable at the beginning of a form does not render it accessible to the entire project. This made interactions between and inside forms quite annoying and rendered navigating through forms quite difficult. A simple variable x declared in one form could not easily be read in another form or in any other part of the event handler. The result was that each event handler was rendered quite isolated in function. Forms tended to be large chunk of code handling all the events occurring at that time while ignoring other forms. Critical information such as actual phase count or question number could not be retrieved unless within the same form. Even passing variables as form arguments would occasionally fail. Finally I resorted to using global variable (declared at the beginning of the Module Form) to transfer data. While I would have preferred using small separate functions to deal with each programming task, I had to rely on with longer codes dealing alternatively with several aspects of the program. This was quit obvious when at a certain stage the program had to format an Excel sheet to be use as a result file. There was no practical way of putting all the formatting code in a single function to be called upon. I rather had to place each part of code in a major form dealing with question presentation (Main Experiment Screen form). This would seem to be a recurring problem with Visual Basic, as it has been encountered on many forums on the internet. Although various ‘tricks’ are proposed to counter this limit (such as sending the variable in a fake textbox and using the text property afterwards) I reframed from using them as they were barely adaptable to this project and I do not particularly like the principle of having to fool a program to have it work for you (Thank you Microsoft!).
Accessing data files
The program required getting data from certain external sources and particularly from an Excel worksheet named QuestionFile. This file was to be located in a folder appending the actual program exactable. It contains the list of all the questions that are to presented during the experiment as well as other information concerning these question (true answer, title, rank of presentation…). The Question Recovery and Sorting form is dedicated to accessing this file. To do so required a connections to an Excel application and then to the desired worksheet. A template and macro data access technique was applied using Object Linking and Embedding (OLE) protocol. OLE allows association and communication between applications. It works on the principle of server-client model and creates an OLE object (an Excel template in this case) within the client (the project). The benefit is that the incorporated template will processes all the characteristics of the actual server’s application and will have access to its libraries and hence to all the commands associated with that application. In such it can be considered as an instance of the actual program inside the project. First linking was assured by adding the Excel object library (through a menu selection) to the project. An instance of Excel application was created through a variable declared and recognized as such in VB and the desired worksheet loaded (the template; open property of Excel object). Then by using typical Excel macro function (Range, Value, Select…) on the template, desired actions could be performed on the worksheet. As such one can leisurely browse through the worksheet and extract values.
12
The number of questions used in the experiment was not definite. Anytime an experimentator could add or remove a question from the database and the program would still need to function properly. So after having opened an instance of the worksheet, the next step was to count the actual number of questions in the list. This was done using a simple loop function (countQ()) going through the data file, on the question column and counting each line until an empty cell was found. The variable obtained (NQ) would be used throughout the program and stored as a global variable. Similarly questions (and afterwards information) were extracted by flowing down the sheet and saving the questions to the global dynamic string array: qlist(). It was also at this stage that a Record Set was created (and partially filled) which would latter be used to regroup all information gathered throughout the experience prior to saving (see corresponding chapter). ( Dim rs As Recordset ; Set rs = New Recordset ) Finally, the Excel application and the Worksheet, being of no use until the next phase of the experiment, were closed using the appropriate properties (.quit and .close respectively). This stage of the program did not involve the user and as such was performed in the background (.visible property set to false). Once its task complete it would call up an event (Button_Click) on one of its own sensors which would allow the program to move on to the next form Below we see a large extract of the Question Recovery and Sorting Form and countQ function code illustrating the previous topics. Private Sub Form_Load() '*************************************************** ' Opening Excel Question file Dim path1 As String path1 = App.path & “\Parameter\QuestionFile” Dim ExcelApp As New excel.Application Dim ExcelWb As excel.Workbook Dim QuestionFile As excel.Worksheet Set ExcelWb = ExcelApp.Workbooks.Open(path1) Set QuestionFile = ExcelWb.Worksheets(1) '**************************************************** 'Extracting questions in a list : qlist() NQ = countQ() ‘NQ for number count. Is global Dim i As Integer 'qlist() declared as Public in module so as to be transferable For i = 1 To NQ ReDim Preserve qlist(1 To NQ) qlist(i) = QuestionFile.Cells(i + 1, 2) Next
‘dynamic array with data conservation
'************************************************** 'Closeing workbook without saving and exiting excel ActiveWorkbook.Close False 'False ensure no saves or confirmations ExcelApp.Quit End Sub
13
Public Function countQ() As Integer '************************************************************* 'Function used simply to count total number of questions 'It assumes a setup question file has already been linked to an Excel setup Qfile. NQ = 0 Range("B2").Select Do Until (Len(ActiveCell.Value) = 0) ActiveCell.Offset(1, 0).Select NQ = NQ + 1 Loop countQ = NQ
'This replaces Return NQ; in C
End Function
Main Experiment Form Once all information necessary for carrying out the experiment had been gathered, the program proceeded to the Main Experiment Form. This form constitutes the major part of the program and handles almost all aspects occurring in and around the experiment. But before delving deeper into the program, let up recapitulate certain of the program requirements: In each phase the program has to iteratively present a list of questions. As explicitly demanded questions are to be answered along a three step protocol, each one concluded by a key press of the Return key. The first press indicates that the subject had completely read out the question and his Reading Time was recorded. The experimentator presses again when the subject starts answering and the Time of Reflexion was recorded. The third key press validates the inputted answer in and initiate the Confidence Level scale. Afterwards it also brings about the loading of the following question. Finally the answer was recovered to be analysed (type of answer), edited accordingly and saved to a line of the record set. So how can one control all theses processes simultaneously? As mentioned earlier, event-directed programming is not particularly adapted at handling multiple processes (its treatment is linear). The sheer of number of action listener required and the difficulty of transferring data between processes would render coordination very complex. A neat alternative was to regroup all the events into one single sensor, in this case, a command button (unseen by the user). This invisible command button would contain all the functions for the every other event. The other event related component would simply activate this button when called upon. As such the invisible button acts as relay and coordinator for every action occurring within this form. As an added benefit, command buttons action listeners are a bit more responsive than those of other types of component, hence rendering the program itself more reactive. Below the flowchart depicts event organization within the Main Experiment form. Rectangular boxes represent actions and functions whereas bullet shaped boxes stand for action listeners. From the schema we can clearly how almost every action in this form is under the authority of the invisible command button.
14
These actions are organized within two imbricated loops. The first inner loop controls the Enter Count. It is incremented every time the Enter key is pressed and repeats itself between the values 1 to 3. Depending on Enter count the invisible action button will initiate a series of procedures. The second outer loop handles the question number count. At each step, a counter will be incremented before going through the inner loop. The counter determined which question was to be displayed from the question list array (qlist(i)). Only once the counter reaches a value equivalent to the number of question in the experiment (global variable NQ) does the program leave the loop for saving of the results for this phase. Iterative questions presentation with Multiple Enter press protocol
Outter loop Out of questions for phase
Inner loop InKey Listenr : Enter Press
° Activate hiden Command button ° Enter Count +1
If EnterCount = 1
° Close Form ° Create/Open Excel sheet °transfer rs
° Label = qlist(i) ° timer1.enable
If EnterCount = 3
Out of phases If EnterCount = 2
Text Change Listener: Key press
° timer1.enable °record TR1 °Responsetexbox. enable
° timer2.enable i+1 ° deactivate textbox ° append results in Record set ° activate Confidence Level scale
Button Listener: CL
15
More specifically actions listeners send an activate signal to the invisible command button. The program is then redirected (IF commands) to specific events according to a static variable EnterCount. Each of these events was designed to be terminated by a Return press (key press listener rendered sensitive to the Enter key). At the end of these events, the variable EnterCount was incremented by one (up to a maximum of 3 whence it would be reset to 0). This ensured that each Enter key press would have a distinct function in the program. The first key press displayed the question would and activated a timer TR1. The second one would turn TR1 and record its value in the result array. A second timer would TR2 would then be turned and the answer text field was would be enabled (could inscribe an answer). The final press would stop and recorded the value of TR2 as well as send (as argument) the inputted answer to a function to be verified before transfer to a result array. It would also activate the interface baring the confidence level scale. Each time the program finished the inner loop and passed into the outer loop, a counter ‘i’ was incremented by one. A label in the form Main Experiment form would then display the corresponding question from the question list array qlist(i). Only once out the outer loop (question count ≥ number of questions; i ≥ NQ) does the next screen activate. If i < NQ Then
'major loop start'
EnterCount = EnterCount + 1 If EnterCount = 1 Then Timer1.Enabled = True questionLabel.Caption = qlist(i + 1) anwerTextbox.Enabled = False End If If EnterCount = 2 Then Timer1.Enabled = False resultArray(5) = TR1 TR1 = 0
'Reading out loud
'Start answering
Timer2.Enabled = True anwerTextbox.Enabled = True anwerTextbox.SetFocus End If If EnterCount = 3 Then Timer2.Enabled = False resultArray(6) = TR2 TR2 = 0
'Validate Answer
anwerTextbox.Enabled = False 'Answer analysis and recording actually done in response to he answer Text box event CL_inputFrame.Visible = True CL_inputFrame.Enabled = True EnterCount = 0
'Confidence Level buttons 'Reset Eneter Count
16
i=i+1
'Next question
Else
'major loop alternative i.e when out of Q ………. 'Create a new or load workbook in Excel 'Formatting the worksheet 'Transfering data to Excel worksheet 'Saving and closing worksheet Unload MainExperimentForm Load InterphaseForm
End If
'major loop end
Timer control Timer components were added (drag and drop) to the form, to record all reaction times. These are time based components which will continuously repeat a certain routine at regular intervals. To create an actual timing mechanism they were coded so as to regularly increase an integer variable by 1. The interval property was set 10ms so as to have sensitivity of the order of the hundredth of a second. This value would temporarily be stored in the variable TR1 before being picked up into the result array. The timer components could then be turned on or off at convenience (timer.enable property) to record desired time intervals. '************************************************** 'Stopwatches TR1 '(in hundredth of a second) Private Sub Timer1_Timer() Timer1.Interval = 10 TR1 = TR1 + 1 Text2.Text = TR1 / 100 End Sub
'to display in units of seconds
Verifying and cutting Answers The answers given by the subjects were obtained through the string entered in the answer text field by the experimentator. Only numerical answers were expected. Different phases of the experiment could accept different types of answers. In phase one the answers could span over a long range of values. Whereas in phase two, only exact answers were accepted. But in some cases, the subject could also refuse or not be able to provide any answer at all. In scientific jargon, this is known as a Non Response and had to be accounted for by the program. Finally the experimentator himself may also desire to put a small remark concerning the response given. For example if he judges that the subject performance was not in line with the experimental demands. Hence before storage, the given answer had to be verified and split where necessary. This was done by passing the given answer (as an argument) to cutAnswer() function. There the constituting character were analysed to determine to which answer type it belonged to. 17
Fist the occurrence and position of answer ‘delimitators’ (separating two answer segments) would be determined using the instring command (InStr). Their presence would indicate that the program was dealing with a ranged answer (rangeflag set on) and henceforth would have to cut the answer into two constituent variable minans and maxans. In the case of an exact answer the whole string would be stored in the minans variable only (maxans was filled with “n.a” for non available). Trimming functions (RTrim, LTrim and Trim) were previously used to eliminate excess empty spaces. This was necessary as a single empty space between answer segments was accepted as a valid delimitator. The next step was to determine if the answers was numerical in format as required. The isNumeric function was used. Failing this test would reconsider the answer as a remark and the answer would encapsulated in a // symbol to be easily recognizable in the result sheet. If the given answer was numeric and ranged, the range length would also be computed as the difference in minans and maxans values. Finally if no answer was given the program would note a Non Response (NR) as answer. The answers (minans, maxans and rangelength) would be stored in a dedicated global array to be used later on in the program. Further on another small code sample would verify if the answer given was correct or not. It would simply verify that the real answer (recovered from question info array) was larger or equal to the minimal answer given but still less than the sum of the minimal answer and the rangelength (zero if an exact answer). The result (true or false) would be stored in the final result array. This routine was located in the Main Experimental form (after 3rd Enter press: Answer validation) as the question count variable ‘i’ was necessary and would have been difficultly accessible otherwise, again due to VB’s reluctance to transfer variables. '*************************************************************************** 'Function that cuts an answer from the textbox entry if delimitators are present Public Function cutAnswer(NQ As Integer, answer As String) As Boolean Dim ans As String Dim minstr As String Dim maxstr As String Dim minans As Integer Dim maxans As Integer Dim rangelength As String Dim rangedflag As Boolean rangedflag = False Dim delimitators(1 To 6) As String delimitators(1) = " " delimitators(2) = "-" delimitators(3) = "/" delimitators(4) = ";" delimitators(5) = ":" delimitators(6) = "à" ans = answer ans = Trim$(ans) For Each D In delimitators If (InStr(ans, D) > 0) Then rangedflag = True pos = InStr(ans, D) D=6
'stops at first delimitator found
18
End If Next D If rangedflag = True And PHASE = 1 Then minstr = Left$(ans, pos - 1) minsrt = RTrim(minstr) maxstr = Right$(ans, Len(ans) - pos) maxstr = LTrim$(maxstr) If IsNumeric(minstr) And IsNumeric(maxstr) Then maxans = Val(maxstr) minans = Val(minstr) rangelength = Abs(maxans - minans) ElseIf minstr = "" Or minstr = "Answer" Then minstr = "NR" 'signifiant Non réponse maxstr = "" rangelength = "" Else minstr = "//" & minstr & " " & maxstr & "//" 'signifie note maxstr = "" rangelength = "" End If Else 'that is, if not phase one or not ranged answer minstr = ans If IsNumeric(minstr) Then maxstr = "n.a" rangelength = 0 ElseIf minstr = "" Or minstr = "Answer" Then minstr = "NR" maxstr = "" rangelength = "" Else minstr = "//" & minstr & "//" rangelength = "" End If End If cutAnswer = rangeflag givenAnswer(1) = minstr givenAnswer(2) = maxstr givenAnswer(3) = rangelength End Function
'************************** 'Verifying if answer correct ….. Dim realAns As Integer Dim givenMinAns As Integer Dim givenRayon As Integer
19
givenMinAns = Val(givenAnswer(1)) givenRayon = Val(givenAnswer(3)) realAns = qinfo(i, 3) If givenAnswer(3) = "" Then resultArray(4) = "NR" ElseIf realAns >= givenMinAns And realAns
