[Non conseillé] Existe-t-il un moyen de savoir si l'impression est terminée?

berfisberfis Membre
décembre 2013 modifié dans API AppKit #1

Bonsoir,


 


Je reviens sur un problème que je n'ai toujours pas réglé: supprimer temporairement la sélection dans une NSTableView que j'imprime.


 


Il est facile de voir lorsque l'impression commence. J'override



- (NSPrintOperation *) printOperationWithSettings:(NSDictionary *) ps error: (NSError **) e

et je mets une propriété du NSDocument _isPrinting à  YES. Lorsque la tableView se redessine (car elle le fait) elle supprime la sélection.


 


Il ne reste plus qu'à  savoir quand je remets ma propriété à  NO.


 


Une idée?


Réponses

  • Je pense que c'est juste impossible à  savoir, tu n'as en effet aucune garantie que ton impression soit traité dans l'instant, CUPS a une file d'attente autonome capable de conserver le fichier en attente d'impression une fois transmit même si ton application ferme.


     


    Si tu nous expliquait l'utilité de ton histoire, car très franchement je ne vois pas l'intérêt de la chose.


  • berfisberfis Membre
    décembre 2013 modifié #3

    C'est bien ce que je pensais. J'ai bien cherché dans toutes les notifications, du côté des delegates, et je n'ai rien trouvé. Céroce m'a conseillé de dériver une NSView en reformattant le contenu de la NSTableView pour en faire une impression indépendante...


     


    L'histoire: J'ai un calendrier dans ma NSTableView, avec des dates de début et de fin pour chaque ligne. A l'affichage, le programme sélectionne la ligne qui comprend la date courante, pour faciliter la lecture. Mais à  l'impression, cette sélection n'a pas de raison d'être.


     


    C'est ce que fait Calendrier: à  l'écran, il marque le jour actuel, mais si tu imprimes, la sélection disparaà®t.


     


    Je pensais utiliser une sorte de propriété de la vue, voire de la fenêtre, pour savoir si elle était "key view" ou "first responder" (vu que le dialogue d'impression passe au premier plan) mais rien...


     


    PS: joli bug dans Mavericks (mais déjà  signalé par d'autres): une NSTableView à  l'impression se retrouve "flipped" (donc inutilisable) mais si tu rajoutes une autre NSTableView invisible dans la fenêtre, le problème disparaà®t.


  • Quand on imprime, il y a une sheet qui s'affiche sur la fenêtre, et qui disparaà®t quand le spooling est lancé (ou son équivalent OSX) ou que l'impression est annulée.


     


    J'ai donc cherché de ce côté-là . J'ai fini par faire ça:



    BOOL hasSheet = ([_mainWindow attachedSheet] != nil);
    if ((!hasSheet)&&([today compare:firstDate] == NSOrderedDescending)&&([today compare:lastDate] == NSOrderedAscending))
    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, 0.0), dispatch_get_main_queue(), ^(void)
    {
    [_dutyController setSelectedObjects:@[;line]];
    });


    ça marche: la sélection revient dès que le dialogue d'impression disparaà®t, et la sélection n'apparaà®t pas à  l'impression. Et ce n'est même pas trop tordu comme solution.


     


    Toujours ce problème de devoir dispatcher des instructions... je devrais finir par m'y habituer...


  • En fait tu prend le problème dans le mauvais sens.


     


    La bonne manière de gérer une impression n'est pas de capturer ce que tu as à  l'écran mais de le redessiner dans un contexte dédié à  l'impression, hors affichage.


     


    De fait tu n'auras aucun problème de savoir si oui ou non la journée du jour doit être sélectionnée ou non.


  • CéroceCéroce Membre, Modérateur
    Tout à  fait d'accord avec Yoann. Ce que je suggérais était de redessiner la table en traçant des lignes et le texte toi-même. C'est certes du travail, mais tu as ainsi un contrôle total, alors que ce n'est pas le cas si tu essayes d'imprimer une NSTableView.
  • @ Yoann et Ceroce,


     


    Je suis bien d'accord avec vous, la doc est même claire à  ce sujet, et dans la vue principale (la NSTableView est une vue secondaire) je passe par le -drawRect et je teste si je dessine à  l'écran ou non: je n'ai donc aucun problème de sélection. Mais je voulais éviter de dériver NSTableView.


     


    Votre solution sera appliquée dans la version 2.0, si l'application rencontre le succès attendu. Cela me permettra de résoudre un autre problème, celui de la hauteur de ligne par rapport au format A4. Pour l'instant je me bats avec le -setIntercellSpacing pour garder le texte centré sur la ligne dans une table de hauteur fixe mais à  nombre de lignes variable (ça c'est à  l'écran).


     


    Je voulais juste tenter de résoudre ce problème par curiosité. Une fixette, en quelque sorte. Merci de vos sages et prudents conseils, sachez que je finirai par les appliquer " je suis borné mais pas au point d'être stupide (quoi que...)


     


    J'ai clos le sujet en mettant [Non conseillé] au lieu de [Résolu], ça me parait intellectuellement plus correct.


Connectez-vous ou Inscrivez-vous pour répondre.