SeekTakeShock - version_tracker.txt ---------------------------- Version numbers are stored in: (1) .iss file (influences setup display, Control Panel) (2) .rc file (About box) (NOT IN THIS ONE... 3) g_strVersion (4) web site whatsnew.shtml (NOT IN THIS ONE... 5) help (.hm3) Things to do ______________________________________________ * Query for Dan: are you sure you only want the stimulus light on *during* reinforcement? Maybe for the pump, but pellet/dipper? --- Dan checking. (Second-Order: stays on longer.) * Tony wants to replace 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. ANOTHER TIME ____________________________________________ * Want option to extend BOTH levers, respond for a CS on (one, both) levers in extinction. This should be a SEPARATE TASK - bears no resemblance to main schedule. REVISION HISTORY ____________________________________________ * 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. * 10-Apr-2001 - Further sodding 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? # Seek-Take Shock version MRFA June 2002 - Many things to change, and not back compatible, so cannot sensibly make a single executable to do both versions. Pat & Barry want the following: 1) Shocks to the seeking response on a proportion of trials -shock should be in place of the usual outcome (taking opportunity). 2) Concurrent VI for sucrose with nosepoke AVAILABLE THROUGHOUT This needs some changes - - option to disable the whole seek-take cycle - no option for anything except infusion as +ve rnf for taking # version 1.4 MRFA August 2002 Tony D noted the need for a more configurable 'shock' option. Previous version (1.3) had seeking phases which ended in shock terminating the cycles. Seeking cycles can now either :go onto taking/rnf cycle :go directly to timeout depending on whether they are shocked or not. # version 3.1.5; 3.1.6 MRFA 2003/4 Minor changes to the structure of the task, including new options for shock. Error in design of 3.1.6: taking cycles got drug or shock AND drug # version 3.1.7 MRFA June 2005 Corrected 3.1.6 for shocking the taking cycles (shock OR drug). Updated help files. # version 3.1.8 MRFA March 2006 The constraint to make the first trial 'no shock' made optional. This requires a new field in the database. #version 3.1.9 MRFA August 2006 A new option (RT) for the seeking and taking schedules. This gives the same schedule as a RI option, but non-contingent (at the end of the interval, the schedule ends). #version 4.0 RNC Jan 2009 - Server default changed from "loopback" to "localhost" (Windows Vista compatibility and more general standardization). - whiskersdk file references fixed #version 4.1 RNC 15 Apr 2015 - Rebuild to use WhiskerClientLib 4.62 with new socket code. - Define WINVER as 0x500. - Compile cleanly with full warnings. #version 4.2 RNC 2 June 2015 - Bugfix: crash at the point of starting the task - in live task: crashed without further detail ... Windows 8.1, 64-bit ... e-mail to self of 2 June 2015 - using default config for testing - unrelated bug occurring at same time in debug build: crash from vector code from CSeekTakeTask::ScheduleShocks(): while( it ++ < m_vbShockedCycles.end()) strList += (*it) ? "S" : "N"; ... which is code that will test the iterator, increment it, then operate on an iterator where it == somevec.end(), and thus fail. - however, that is in the "#ifdef _DEBUG" build! And the release-mode code was not running it. - fixed that - added vector-length checks to CanInsertAShock() - still crashing in release mode - fixed dialogue tab order - added About button so version number visible - added StatusMessage calls - implement CSeekTakeTask::StatusMessage - CHScrollListBox - #pragma once - Bug found and fixed. It was: - ScheduleShocks() generated a random number between 0 and the vector size of m_vbShockedCycles; - so for a size-10 vector, it could be 10; - it passed that to CanInsertAShock(here); - ... which used m_vbShockedCycles[i] as a test, where i == here - ... so might test m_vbShockedCycles[10] when the maximum index is m_vbShockedCycles[9]. - A genuine MRFA bug; don't get many of them! :) - Database problem was: ShockTaking } fields missing from SeekTake_SessionConfig table NeverShockFirstCycle }