Author | Topic: Strange program behaveour | |
---|---|---|
Toma Grom | Strange program behaveour on Wed, 25 Sep 2013 08:13:25 +0200 Hello there! After decades of programming in xBase++ I have encountered a strange functioning inside my program. It has over 150 working modules and works well. But my new module causes trouble. If I link it in a smaller developer version, so only few tens of .PRG involved for the linkage speed purpose, everything works fine. But when linking it into main program, it works fine only first time, just after compilation and linking, and even if I do not close the entire program, but only that problematic working module and start it again, the problem arise. When start if the next time form the shortcut icon, it does not run well even first time. The error is not enocuntered inside the compiler, linker or main menu frame of the program, but only after a certain program line inside the problematic working module, that test EOF() of opened data table. The main difference between running mudule inside small and big program is that in smaller version program performs a normal module call, and huge one stars it inside a new thread. The error: When I put a certain .DBF file into relation to another one and then test its OEF() or LASTREC(), it causes error and reports, that 'Parameter has a wrong data type'. But the alias is there and can be seen from Dc_msgbox(WorkSpaceList()), for example, and no trouble has been reported when opening it. If I ignore the error and proceed, further errors arise inside DCREAD GET part of the program - Refreshing error because parameter has a wrong data type. That working module looks equal to many tens of symilar others, that don't cause any trouble. I tried to check many things and now run out of ideas, so I am asking anybody here, if you can suggest me, what should be done (checked) next. What could be interfering a new module that much, it reacts so unpredictable and also unequal in firs and that following call iterations. xBase++ 1.9.331 eXpress 1.9.249 ADS 8.1 (RDD is ADS engine, and DBF/CDX tables are connected into dictionary) Best regards Toma | |
Toma Grom | Re: Strange program behaveour on Wed, 25 Sep 2013 08:15:35 +0200 Sorry - behavior - functioning.... BR Toma | |
Toma Grom | Re: Strange program behaveour on Wed, 25 Sep 2013 08:25:18 +0200 One more observation... New module works fine even inside a big program, If I do not run the program inside a new thread ... So thread seem to be problematic. Why, and why elsewhere not, I have no idea.... | |
Toma Grom | Re: Strange program behaveour on Wed, 25 Sep 2013 10:00:07 +0200 I think I found the answer, but it remains still very strange. I was needed to open certain data table twice, like: USE (MyFile) VIA (oSessionServer) NEW SHARED USE (MyFile) VIA (oSessionServer) ALIAS (MyFileTemp) NEW SHARED READONLY Then I skip through the MyFile and in between do some investigations into its alias clone. It goes all right whether I encapsulating the working module (data areas) into separate thread, or not, but if I did, problem have arised just little later. EOF() error report was namely not reported in connection to that problematic table, but other tables, that were also opened and are in relation, and not in relation with this one, but the third one. Now I changed the structure of the module code so I do not use an alias clone of that table any more. Even if I let it stay as it is, opened, it does not cause any trouble unless I use it. Anyway, I throw it out now ... Really really unpleasant situation. Whole day spent ... and only with God help ... Any comment ? Best regards Toma |