[Gambas-user] Very strange printing problem + SHELL

Eilert eilert-sprachen at ...221...
Thu May 4 12:08:15 CEST 2006


Benoit Minisini schrieb:
> On Wednesday 03 May 2006 12:05, Eilert wrote:
>> Benoit Minisini schrieb:
>>> On Wednesday 03 May 2006 09:52, Eilert wrote:
>>>> Hi everybody,
>>>>
>>>> After having been searching for this bug for months, I've found it at
>>>> last.
>>>>
>>>> In one of my apps, when the user makes an entry into a customer's
>>>> account for instance and has it saved, the program won't print anymore.
>>>> The printing dialog appears, and everything runs through as expected,
>>>> but there is no output to the printer. If I restart the program, it will
>>>> print as usual.
>>>>
>>>> Now, this appears to be the reason:
>>>>
>>>> In the saving SUB I found I had included a SHELL command changing the
>>>> file's mode to 660 after writing so every member of the group can write
>>>> into this file.
>>>>
>>>> When I comment this SHELL command out, the app runs as expected. As soon
>>>> as it is activated, however, the bug appears: Whenever the SHELL is
>>>> called, printing will fail afterwards.
>>>>
>>>> Here is one of the critical parts in code:
>>>>
>>>>    OPEN datei$ & "konto" FOR WRITE CREATE AS #dtnr
>>>>      FOR i = 0 TO ktNr.Count - 1
>>>>        IF ktModus[i] = "N" THEN BREAK
>>>>        PRINT #dtnr, "    account" & Chr$(13)
>>>>        PRINT #dtnr, "        number=" & CStr(i + 1) & Chr$(13)
>>>>        PRINT #dtnr, "        date=" & SpeicherDatum(ktDatum[i]) &
>>>> Chr$(13) PRINT #dtnr, "        text=" & Str2Tag(ktText[i]) & Chr$(13)
>>>> PRINT #dtnr, "        debit=" & ktSoll[i] & Chr$(13)
>>>>        PRINT #dtnr, "        credit=" & ktHaben[i] & Chr$(13)
>>>>        PRINT #dtnr, "        mode=" & SpeicherModus(ktModus[i]) &
>>>> Chr$(13) PRINT #dtnr, "    end account" & Chr$(13)
>>>>        PRINT #dtnr, " " & Chr$(13)
>>>>      NEXT
>>>>    CLOSE #dtnr
>>>>    SHELL "chmod 660 " & datei$ & "konto" WAIT
>>>>
>>>> Does anyone here have an idea why this SHELL line might keep the printer
>>>> from printing? Is there another way of having the chmod 660? Or did I
>>>> implement the SHELL command wrong?
>>>>
>>>> Thanks for all ideas!
>>>>
>>>> Rolf
>>> I think there is a clash between interpreter process management and qt
>>> process management, used for running 'lpr'.
>>>
>>> Try to print to a postscript file, and send this file to the printer with
>>> SHELL or EXEC. It should work.
>>>
>>> Regards,
>> Yes. In my app, there is a printer dialog. If I choose "print to file",
>> it prints a standard ps file.
>>
> 
> You must do it by code, with:
> 
> Printer.File = XXX
> 
>> Hm. Is deviating the printing through a ps file + SHELL to lpr really
>> the only way of getting rid of this problem?
> 
> This is almost exactly what does the qt library: creating a postscript file, 
> forking and running lpr in the background, and piping the file to it.
> 
> But it seems that the interpreter process management breaks the qt library lpr 
> management. Of course, this does not use the qt process management classes!
> 
> Mmm... The qt library seems to have been designed so that you cannot use any 
> other library!
> 
> So printing to a file, and sending it to lpr is not a shame. And you can even 
> send it to kprinter instead of lpr to have more power!
> 
> Regards,
> 

This turned out much too complicated, as my printing module is way too 
large and has many (strange) ways of printing here and there... ;-)

Instead, I found ACL and could get rid of the SHELL command by setting a 
default mask for those directories for all users of the group using the 
files.

It appears that the SHELL command is also causing errors in another 
application although some earlier version of Gambas should fix this bug. 
I've recompiled this app but it still doesn't run for a long time. 
Sometimes it dies after a minute, sometimes after an hour. But it never 
survived a whole afternoon. This program uses the SHELL for invoking a 
"who" every 10 seconds and building a list of users currently logged in.

I think you know that program, we've discussed this before. I just 
wanted to tell that it still doesn't run flawlessly.

Regards

Rolf




More information about the User mailing list