SeekTake - version_tracker.txt ---------------------------- Version numbers are stored in: (1) .iss file (influences setup display, Control Panel) (2) .rc file (About box) (3) g_strVersion (4) web site whatsnew.shtml (5) help (.hm3) Version history: 1.0 ============================= * Written 26-28 July 2000. * There's a slight dilemma with the parameters dialogue. The natural way to program would be to embed a CSeekTakeConfig structure in the dialogue, and have the dialogue box populate this class. That's how SecondOrder works. Unfortunately, this breaks the ClassWizard. So I'm doing it the messier way here. * Test on different screen resolutions and redraw dialogue boxes if necessary. Goes wrong on 1024x768 as well as 800x600. Is the problem that I have large fonts installed on the development machine? Yes, that was the problem. Have had to go back to small fonts. * The RI ticker timer runs all the time. Simpler than turning it on and off. * Q. Why the hell is the Dipper Normally Down check box not being ticked? A. Because it wasn't being assigned in CSeekTakeConfig::operator=(). * Having problems with crashing at the moment of database access, but only when building in Debug mode. A right pain in the arse. Why? - specifically, an access exception error pops up from mfc42d.dll - in CTime::GetYear(), which is this: _AFX_INLINE int CTime::GetYear() const { return (GetLocalTm(NULL)->tm_year) + 1900; } at this point, "this" is {time=-858993460}, which is wrong. - called by RFX_Date(CFieldExchange*, const char*, CTime&): pts->year = (SWORD)value.GetYear(); at which point, time is negative - called by CRecordSet_SeekTake_Config::DoFieldExchange(CFieldExchange* pFX): RFX_Date(pFX, _T("[DateTimeCode]"), m_DateTimeCode); - called by CRecordset::LoadFields() - called by CRecordset::UpdateInsertDelete() - called by CRecordset::Update() - called by me - CSeekTakeConfig::WriteToDatabase(...) - and at the moment of the call out of WriteToDatabase, m_DateTimeCode: {time = 964825316} rs.m_DateTimeCode: {time = -858993460} despite having just gone through rs.m_DateTimeCode = m_DateTimeCode; (and both m_DateTimeCode and rs.m_DateTimeCode are of type CTime.) - This looks to me like a COMPILER BUG. But it's quite consistent - a trivial code order reorganization didn't fix it. Is it a size problem? 964825316 = 111001100000100001000011100100 -858993460 = 11001100110011001100110011001100 -- note the regular pattern so not obviously. - Forced that one (the Config table) to zero; cancelled all the "null primary key" errors; got the same crash again from CCycleRecord::WriteToDatabase(...). This time, true value is 964826028, but wrong value is still {time=-858993460}. - So something's overwriting the CRecordSet-derived field. - Have spotted something. In CRecordSet_SeekTake_SessionData, the AFX_FIELD_INIT block has six variables being initialized, and m_nFields = 9; there are three (uninitialized) date fields. But in Config and CycleRecord, -- ah, no, the same is true of all the recordsets. - SO NO BLOODY IDEA. BUILD IT IN RELEASE MODE (remembering to switch optimization off to avoid the *other* compiler bug). - 12 Apr 2001: problem avoidable if CTime structures initialized in CRecordSet constructor: m_DateTimeCode = CTime(0); and doing this also makes the m_nFields value correct. Ah, good. I like it when the debug builds don't crash. :-) * 30-Jan-2001 Dan starting to use the task. Reported bugs: - "Max reinforcers = 0" doesn't give no limit but a limit of 1. Fixed 30-Jan-2001 (in AdvanceSchedulePhase). - When timeouts are set to 24 min, they aren't always. Has noticed odd overall session times (e.g. 10 reinf with 24 min TO shouldn't finish before 4h, but did) but also abnormal timeout durations (e.g. explicit 4-min TO test run; was some variation - perhaps on cycles other than the first?) Possible causes: - Timeout_Finished code being executed inappropriately, e.g. by fall-through? Can't see a reason for that. - Other events being inappropriately processed (e.g. seeking response getting through as the levers are being retracted?) Can't see it... - Server mistiming events? Hmm, hope not! - Bug in RequestTimerEvent or Minutes_ms? Very unlikely. No. - m_config.m_fTimeoutDuration being rewritten during execution? No... * Found it! Timer was running on infinite reloads. (Fixed in AdvanceSchedulePhase.) (Instantly apparent when you see it running!) * 31-Jan-2001 - RI schedule now requires a single press to start it... so you can't complete the schedule without a total of 2 presses. This is as the Acorn/Arachnid code (SEEKTAKE, in/around FNDSlever_count), and is confirmed by Tony to be what he wants. Implemented in the "RI_tick" event handler (within IncomingEvent). FR and VR code unmodified. - FI schedule: same thing. (See RespondedIsCurrentScheduleComplete, Seeking_Lever event handler, ClearSchedule.) * FI schedule asterisk (indicating schedule primed) doesn't appear because no event calls regularly to check it. Never mind, eh? * Tell Dan: I have little idea of what rates he really wants to measure (incl. in situations when there are/aren't two levers). So I've stuck a few in as pre-calculated measures; the rest should be accessible by SQL. * Get Dan to check it with real equipment, and also make sure all the varieties of schedule work properly. Also check default parameters, and one-click-config parameters. * NOTE - actual, precise times of noncontingent CS presentation are not presently recorded. Ask Dan if that's important. -- Yes, it's OK as it is. 1.3 ? ============================= * 10-Apr-2001 - Further **** modifications. # Dan and Maria want the following: - to retain the current "noncontingent CS, timing random with respect to cycles" option - to PRECEDE the SEEKING phase with something. That something might be 1) a CS reinforcement CS+reinforcement Specify - the time from the start of the CS to the start of the seeking cycle; - the duration of the CS. This allows them to overlap, or have a gap between the two, or whatever. or 2) the taking lever, +/- a CS, +/- requiring a single response on it, +/- reinforced, +/- a delay afterwards before the seeking schedule starts. - option of using the central light as the CS. - want the option for NO cycles to do this, or EVERY cycle, or ALTERNATE cycles, choosing whether the session starts with a CS or a no-CS cycle. If a RANDOM option goes in, would need to record what happens for each cycle. Yes - Cella used it - need at least a semi-random option. (Randomize in pairs?) - RECORDING. If CSs (whatever) aren't on in every cycle, they need to know whether the CS is on in any given cycle. They need no other data to be recorded. Specifically, they don't care about recording whether the CS is on when particular responses are made, etc. # So I shall implement their requests like this: - add new RR schedule option for Tony, if we can establish exactly what he wants - call the thing that precedes the seeking phase the PRIMING phase - define drug-CS as (light-over-take-lever [usual] / centre-light / light-over-seek-lever [abnormal] - define priming/noncont.-CS as (light-over-take-lever [usual] / centre-light / light-over-seek-lever [abnormal] - have completely desynchronized noncont.-CS or not - prime no cycles, every cycle, alternate cycle (starting with Y/N?) / randomized in pairs - priming event = COMPLETELY NONCONTINGENT ? CS ? taking lever ? reinforcement ? duration of CS (NB reinf. duration specified elsewhere) ? time from START of CS to START of next phase (NB can overlap the two) PARTIALLY CONTINGENT - present taking lever and require one press ? present CS with taking lever ? reinforce press ? give CS contingent upon press ? duration of CS ? time between press and start of seeking phase - record whether each cycle is primed or not #MRFA April 2001 - Bug Fix - Failure to claim the Centre Light now fixed. not needed? * RNC 23/7/2002 Modifications as requested by Dan Hutcheson and Louk van der Schuren (or Vanderschuren, in this modern age?) Code modifications are marked "RNC 23/7/2002". 1. to present the seeking lever for a fixed time (e.g. 30s), unreinforced. In cycles, presumably. (Dan) 2. to present the taking lever for a fixed time (e.g. 30s), unreinforced. In cycles, presumably. (Dan) 3. to present the taking lever for a fixed time, but reinforced, so that if the rat responds in that time it gets drug and lever retraction after which it gets the lever back (though with typical drug timeouts the 30s would have elapsed by then), and then presumably to repeat this in cycles. (Dan) 4. to presend the seeking lever for a fixed time, with or without a noncontingent CS during that period. To run in cycles with the noncontingent CS present on some cycles and absent on others within the same session. Not reinforced. (Louk) My notes/queries: --- Adding a simple "fixed time" option to the seeking and taking aspects of the task would satisfy (1) and (2) - the lack of reinforcement can be obtained by switching off the "reinforce" part of the task as usual. Option (3) is a hybrid - "present for a fixed time unless the rat responds, in which case terminate the presentation" Option (4) is a Pavlovian-instrumental transfer test. The current RI(/FI) behaviour was confirmed by Tony to be what he wanted, so I won't modify that. Assuming you're both sure that you want these implemented within the seeking-taking task, rather than as standalone tasks... Q1. Louk, you said that you wanted to present a tone/light CS. Is this CS different from all other stimuli currently implemented in the S-T task? (I presume they're your shock CSs.) Q2. Louk, would you ever want to run your proposed "CS during seeking" task in combination with the existing option to present desynchronized noncontingent CSs throughout all phases of the task? (Please say no. :-) ) Q3. Louk, what parameters of CS presentation would you want? Any flashing malarkey, or just "on" for the whole length of the seeking phase? Q4. Louk, in what way would you like some seeking cycles to have a CS played, and some not? Options for all/none/alternate? Or just alternate CS/no-CS cycles? Randomly, or specifying some sort of order? Any other complication? --- Dan happy with the above. Louk's comments: a) The CSs I'm using now are tones. I might use a light or flashing light/tone compound sometime, but for now it'll probably be tones. The CSs implemented in ST task are lights, not? Right now we have the tone plugged into the 'light above seeking lever' option. Does this answer your question? b) Not likely so. However, saying 'no', as you requested, would mean 'never' here, and I'm not going to say that :-) c) For now just 'on'. Perhaps flashing things when I use a flashing light/tone compound, in the future. Is a flashing option difficult to add later? d) An all/none/random/alternating option would be best, in which I also have control over if the first cycle is a CS or a no-CS cycle. -- - Added "Ext-Timeout" and "FR1-Timeout" schedule options. This deals with problems 1, 2, 3. No config file/database changes required. Total coding/debugging time ~45 min. - For modification 4... the complicated one... User should select Ext-Timeout. Then need additional "CS during seeking" phase - Additional button on params screen + further dialogue box (w. associated class) - Options: - CS during seeking Y/N - CS all/randomized/alternate - if alternate, first seek cycle DOES have CS Y/N - CS: light over taking lever / centre light / light over seeking lever / tone (c'd add hard-coded further options here for whatever flashing combinations Louk eventually settles on) (don't try to soft-code the flashing, w'd be right pain in arse) (have text-based config output for such future expansion) - add those 4 options to config file, text summary, database add new table "SeekTake_SessionConfig2" to avoid breaking existing database; users can paste in this new table to existing databases to enable new functions - new recordset for that table - code task itself - distribute code/new database - new version now requires TONE to be defined or aliased to a nonexisting (fake) line. - no guarantees as to what happens if the same CS is used in the desync. noncontingent CS option and the PIT option simultaneously caveat emptor - logging of whether an individual cycle had PIT during seeking arse, database *is* modified, though this is a simple extra boolean (CyclePIT) in SeekTake_CycleData - coding/debugging time 140 min Things to do - maybe, maybe not - not done yet, at any rate ============================= * Tony spoke of replacing VR schedule with RR (fixed probability of reinforcing each response)... ... but only count 1 response per second towards the schedule. Tony also spoke of configuring this by specifying a "multiplication factor"... will have to ask him again what this means. 2.0 ============================= - From point of introducing "default ODBC DSN" system, 15 Aug 2002. - 22-Sep-2002 Integrated HTML Help 2.1 ============================= - fixed missing UpdateData(TRUE) bug 2.2 ============================= - horiz scroll listbox - about button 2.3 (22 Nov 2003) ============================= - writes version number and compilation date to summary file 2.4 (19/22 Oct 2004) RNC ============================= - Requests from Kim Hellemans: * Experimental design: - seektake training - pair CS with withdrawal (specifically, CS -> naloxone injection -> more CS) ... CS should be {tone, houselight} flashing e.g. 5s on/5s off ... total CS time approx. 15 min ... not necessary to have computer-controlled pause; simply inject 2min into a ~15min CS-presentation session as that minimizes time between CS and naloxone to improve pairing; still want CS present after naloxone given so naloxone-induced state can be associated with the CS - but, unlike Shwen's version, ensure CS precedes (predicts) naloxone. ... no levers present during conditioning phase - test: present same CS with seeking/taking levers present ... probably with seeking lever still producing taking lever but taking lever not producing reinf. (so seeking responses extinguish less and yet no primary reinforcer delivered) ... CS cycles desynchronized from seeking/taking cycles (so no reason for rats e.g. to respond more when CS on to get the CS over with!) ... e.g. 2min CS on, 2min CS off, alternating * Therefore, modifications to SeekTake task needed: - ability to use tone/houselight as the "noncontingent" stimulus, [m_bPrimingCS_UseTone, m_bPrimingCS_UseHouselight, m_bReinfCS_UseTone, m_bReinfCS_UseHouselight] [blissfully easy thanks to aliasing system] [conflicts with devices simultaneously in use are the User's Problem] ... with defined on/off flash times [feature was already in there; see the desync. noncont. CS dialogue] - ability to use the "desynchronized noncontingent CS" facility in the absence of *any* levers (for the Pavlovian phase) [m_bAllowNoLevers] [Existing facility for presenting "desynchronized noncontingent CS" with seeking +/- taking levers enabled (but no reinforcer enabled) will work for the test phase.] - XML configs, damn it. - Hmm. It seems that strEventSessionFinished was never used; absolute string hard-coded instead. Fixed. Same for strEventLocoBinFinished. 2.5 (11 Nov 2004) RNC ============================= - for each response, record whether noncontingent CS on/off (for which, noncontingent CS code rewritten a bit) 2.6 (8 March 2007) RNC ============================= - easier compilation for users 3.0 (12 Jan 2009) RNC ============================= - Server default changed from "loopback" to "localhost" (Windows Vista compatibility and more general standardization). 3.1 (14 Apr 2015) RNC ============================= - Rebuild to use WhiskerClientLib 4.62 with new socket code. - Define WINVER as 0x500. - Compile cleanly with full warnings. 3.2 (14-16 Mar 2020) RNC ============================= - Bugfix: RI schedule looks like it would not have operated correctly for the Taking phase (not that anybody uses that, I suspect). - New option for contingency degradation (for Chiara Giuliano): - Option for noncontingent delivery of reinforcement ... on an FT or RT schedule ... during the seeking phase only ... with no timeout ... and an optional CS [let's decide: the "reinforcer-associated" CS] [the "noncontingent" CS is used for a different purpose, namely priming and desynchronized noncontingent CSs] - This is a little like the PIT option (whose master switch is m_bPITDuringSeeking, determining m_bPITThisCycle). But different. - New variables: m_bNoncontReinfDuringSeeking -- deliver reinf.? m_bUseCSForNoncontReinfDuringSeeking -- use CS? m_iNoncontReinfDuringSeekingSchedule -- schedule type m_fNoncontReinfDuringSeekingScheduleParam1 -- time (s) for FT/RT schedule - "NRDS" in code means noncontingent reinforcement during seeking. - Columns added to SeekTake_SessionConfig2 table. - Done: config recordset database: config table dialogue boxes task event recording SeekTake_CycleData.NoncontingentReinfsDuringSeeking new "Response" option in SeekTake_ResponseEvent help testing