Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Switching DataSession's
Message
General information
Forum:
Visual FoxPro
Category:
Coding, syntax & commands
Environment versions
Visual FoxPro:
VFP 6 SP5
OS:
Windows XP SP2
Database:
Visual FoxPro
Miscellaneous
Thread ID:
00968641
Message ID:
00968805
Views:
7
>>i've tried to form.enable=.f. - makes no difference.
>>
>>to pass the table name to the method would not work either, because i am obviously not in the correct ds, and the fox would not find the table again.
>>
>>because the debugger is obviouly lying, i've changed my 'ds switching' block to the following:
>>WAIT WIND TRANS(SET("datasession"))   && shows 1
>>IF TYPE("_screen.ActiveForm.DatasessionId") = "N"
>>	CurrentDS	= SET("datasession")
>>	CallingFormDS	= _SCREEN.ACTIVEFORM.DATASESSIONID
>>	_SCREEN.ACTIVEFORM.ENABLED = .F.
>>	IF CallingFormDS <> CurrentDS
>>		ResetDS = .T.
>>		WAIT WIND   && this shows too
>>		SET DATASESSION TO &CallingFormDS
>>	ENDIF
>>ENDIF
>>WAIT WIND TRANS(CallingFormDS) + ", "+ TRANS(SET("datasession"))   && shows 2, 1
>>
>>
>>so, obviously the ds does not get switched; question is why, both ds are available, the private ds form is active, visible, etc.
>>
>>so - i don't get it.
>>
>>>I meant the alias or the table name, whatever you needed.
>>>
>>>You said that the alias name was correct and I've done session changing [though the manual does say it should not be issued when a form is active].
>>>
>>>hmm, maybe the form holding the datasession needs to be inactive? It could be that being in the debugger makes the form inactive.
>
>
>There are times when the debugger does not behave well; for example, when dealing with ActiveX controls. Whenever I suspect the debugger to be reporting incorrect information I stop relying on it and use the command window instead. The command window seems to be much more accurate in terms of the current state of the system and with intellisense on it is easy to 'discover' otherwise hidden properties. Assign objects to variable references that are suspect and either view them (the variable assigned from the command window) in the debugger or print to screen suspect properties. There are unlimited variations when you are sitting at the command window for debugging things.
>
>The other way around suspicious debugger issues is to embed a messagebox where you might suspend and simply report to screen the information you are trying to look at from the debugger.


i agree with you. often i use wait windows or messageboxes within the code to get an accurate snapshot.
Previous
Reply
Map
View

Click here to load this message in the networking platform