M.i.v. deze Releasenote is het aansturen van MS-Word v.w.b. het maken van een Maatbrief drastisch gewijzigd. Aanleiding betreft een melding dat Profit 'hangt' danwel met meldingen komt dat een aktie niet kan worden voltooid omdat een ander programma bezig is.
Bron van de ellende is een bug in MS-Word waarop diverse fora wordt gediscusseerd. Wellicht een slimme wijze van werken, maar niemand weet er mee om te gaan.
In veel voorkomende gevallen verschijnen er ook foutmeldingen zoals "De RPC Server is niet beschikbaar".
Wij hebben de oorzaak gevonden :-)
Alles wat we in een pakket zien bestaat uit "Objecten". Een scherm is een Object, de controls (Labels, Textboxen, Comboboxen) zijn ook Objecten. Al dit soort Objecten kunnen aangestuurd worden vanuit coding.
Heel simpel gezien, stel dat we naar Wijzigen Relaties gaan, dan wordt er een Form Object (het wijzigscherm) opgebouwd, komen de Controls (Textboxen) op het scherm waarmee de gegevens kunnen worden weergegeven en overschreven, en zullen die Objecten worden gevuld met waarden (uit de database) en kunnen er definties zijn (DynScreen) die ervoor zorgen dat bepaalde rubrieken niet ingevuld mogen worden.
MS-Word is ook zo'n Object. We kunnen een Object "Word" aanmaken vanuit coding, en dit Word Object vervolgens opdrachten geven. "Maak Word zichtbaar, kreëer een nieuw document, vul deze met de gegevens van een documentmasker, sla het document op als ..." etc.
Een dergelijke procedure wordt gehanteerd bij het maken van een Maatbrief welke we via MS-Word maken. Omdat we ná het maken van de maatbrief nog een aantal aanvullende zaken willen uitvoeren (registeren dat het verslag klaar is, hoe laat het verslag klaar was, eventueel printen of mailen van het verslag) staat Profit net zo lang te wachten tot we klaar zijn met ons Word document. Profit maakt een Word-Object aan, en wacht tot deze niet meer 'live' is.
Toch werkt dit niet, vanwege een paar 'slimmigheidjes' in Word.
Stel dat we Word opstarten en een nieuw document aanmaken, dan hebben we 1 Word document geopend (noem deze maar eens A.DOC). Terwijl Word aktief is, kunnen we een 2e document openen door bijv. B.DOC te openen, danwel een nieuw document te openen (en op te slaan als B.DOC). Het mag voor iedereen logisch zijn dat MS-Word dan één keer is opgestart, maar dat er twéé documenten geopend zijn.
Normaliter is het anders als we naar Start gaan, en daar nógmaals Word zouden opstarten. Logischerwijs wordt dán MS-Word voor een 2e keer gestart, en hebben we 2x WINWORD.EXE in "Windows Taakbeheer" staan.
Niets is echter minder waar. Als we via Start, Programma's nogmaals Word opstarten, herkent Word dat ze al gestart is, en opent de reeds geopende Word taak het gewenste document, zonder zichzelf opnieuw op te hoeven starten. Inderdaad: slim !
Echter, dergelijke zaken werken ook zo bij OLE Automation, zijnde de wijze waarop wij vanuit Profit Word aansturen. Het Word Object welke vanuit Profit wordt aangemaakt, dan door het openen van een ander document 'live' worden gehouden. Normaliter als wij ons document zouden afsluiten, krijgt Profit de regie terug. Echter, als we ondertussen een ander document hebben geopend, blijft Word 'geopend', omdat de andere sessie MS-Word 'live' houdt.
Nog erger wordt het als we konstateren dat er ook situaties zijn dat het sluiten van het document welke buiten Profit om geopend is, er ook voor kan zorgen dat het document welke vanuit Profit geopend is gesloten kan worden, dit, terwijl daar vanuit Profit geen opdracht toe is gegeven. Objecten die vanuit een bepaalde toepassing zijn aangemaakt mogen in principe niet door andere toepassingen zomaar gesloten kunnen worden.
Het 'hangen' ontstaat nu al dat als we in Profit een maatbrief maken (en Word gestart wordt), en we daarna een ander Word document openen, vervolgens de maatbrief afsluiten, MS-Word (die door Profit geopend is) nog steeds 'levend' gehouden wordt door een inmiddels buiten Profit geopend bestand om. Zouden we ook dát document sluiten, dan gaat Profit weer verder.
Of we zoiets ook onder kontrole hebben op een Terminal Server kun je je afvragen, want ook daar kan het zijn MS-Word denkt "als een andere Gebruiker Word opstart, en WINWORD.EXE is al aktief, waarom zou ik mezelf dan nogmaals opstarten".
Het 'hangen' wordt op zich al opgelost door Profit niet te laten kontroleren of het aangemaakte Word-Object nog 'leeft', maar door te kontroleren of het document waarvoor ze werd aangeroepen nog geopend is. Zodra de maatbrief is afgesloten moet Profit weer de regie in handen krijgen, en zou Word best omwille van andere documenten geopend mogen blijven.
Niet meer blijven wachten Nog een stap verder is de eigenlijke reden voor het 'blijven wachten tot we klaar zijn in MS-Word'.
Sinds de introduktie van module
Profit-Mail is het zo dat als we een maatbrief maken, we éérst een brief typen, en zodra we deze opgeslagen hebben, dan volgt er een vraag of ons verslag kompleet is. Zo ja, dan gaan we verder met Printen, en worden de NAW gegevens gevraagd van de persoon ter attentie van wie de brief-/mail gestuurd moet worden.
Sedert de introduktie van externe editors om een maatbrief te maken, die meer volgens een "what you see is what you get" principe werken, wordt er (instelbaar) vóóraf om de NAW gegevens gevraagd, welke gegevens middels een MailMerge bestand beschikbaar worden gesteld aan de editor (DHTML editor, MS-Word, Wordperfect etc). en waarna de aan te roepen editor al meteen de hele briefopmaak bevat met NAW gegevens, aanhef etc.
Ook als we onze maatbrief via Word maken, zal vooraf om de NAW gegevens worden gevraagd. Deze worden al in de maatbrief gemerged, en feitelijk zodra we ons Word document voor onze neus krijgen zouden we al klaar zijn. We kunnen Word dat document (de maatbrief) laten openen, en het opslaan puur aan Word overlaten. Waar wachten we dan nog op ?
Tsja... eigenlijk op maar één ding: de melding dat we klaar zijn met het verslag.
Het enige wat er op dat moment feitelijk gebeurd is een vlaggetje opzetten "dat we klaar zijn". Een vlaggetje welke ooit bedacht is, maar zeker voor die externe editors niet echt meer gebruikt wordt.
Voor normale verslagen geldt al dat of we nu klaar zijn of niet, we kunnen het document toch wel printen of mailen als we daartoe opdracht geven. En, helemaal als we de brief in Word maken, dan hebben we het niet eens in de hand wat de gebruiker allemaal rechtstreeks vanuit Word print of mailt. Het blokkeren van dit soort funktionaliteit "omdat het verslag nog niet klaar is" heeft weinig zin.
Een tweede is dat formeel een datum-/tijd laatste wijziging geregistreerd wordt. Stel dat iemand om 09:00 met zijn brief begint, en 10:30 klaar is, dan staat 10:30 geregistreerd als eindtijd. Maar ja, is dát nu zó belangrijk ?
Het pas registeren van het kontakt zodra deze klaar is, heeft als voordeel dat andere gebruikers kunnen zien dat een verslag 'in de maak' is. Tsja... dat kán handig zijn.
Keerzijde is wel dat als een gebruiker om uit zo'n 'hang' situatie te komen zijn Profitsessie kilt, de link tussen Profit en het Word document weg is, en daarmee de gebruiker niet meer bij zijn verslag kan.
Resumerend is derhalve per heden gesteld dat voor dit soort externe editors (zoals Word) waarbij vooraf al om de NAW gegevens zijn gevraagd (en die via MailMerge beschikbaar worden gesteld aan die toepassing) er
niet meer wordt gevraagd of het verslag klaar is!
D.w.z. dat het Kontakt direkt wordt aangemaakt met de verwijzing naar bijv. het Word document, en U vanuit Word uw document al dan niet opslaat.
Extra groot voordeel (en medebepalend voor deze keuze) is dat Profit daarna direkt beschikbaar komt, en ook weer gebruikt kan worden voor andere doeleinden.
Hoewel wel direkt in Profit verder kunnen gaan, is het niet per definitie gesteld dat we ook meteen een tweede Word-Document (maatbrief) kunnen openen. In theorie, technisch gezien, is het geen probleem Word een 2e keer op te starten en daarin een andere brief te lezen. Het loopt echter fout op het Samenvoegbestand.
Iedere brief die we openen zal met hetzelfde samenvoegbestand (TROEPBRIEFNAW) werken, en daarvan kunnen we geen nieuwe genereren zolang de vorige nog door een andere brief (Word document) geopend is, immers die zorgt ervoor dat het samenvoegbestand niet overschreven kan worden voor het nieuwe dokument.
Ook bij het gebruik van dat Samenvoegbestand moeten we terug naar de basis:
Elimineren Samenvoegbestand Toen we vroeger met de DOS editor onze verslagen typeten, hoefden we alleen de tekst van het verslag in te typen. Tijdens het printen werden de NAW gegevens wel bijgevoegd in het document. En, zouden we de gegevens willen aanpassen, dan kon dat alleen via een popup vlak voor het printen waarin om de gegevens moest worden gevraagd.
Sinds de introduktie van de externe editors is dit mechanisme zo overgenomen, maar, omdat i.g.v. Word die NAW gegevens ook al naar het Word document zijn gekopieerd, kunnen we dáár er wél voor kiezen e.e.a. in het Word document te wijzigen. Dat hoéft dus helemaal niet meer vanuit Profit (die het vervolgens weer door moet vertellen aan Word).
Met deze aanpassing derhalve ook een grote wijziging inzake het gebruik van de MailMerge bestanden. Deze (de BRIEFNAW.TXT) wordt nu alleen nog maar gebruikt in de DocumentMaskers (de bronbrieven). Zodra er een échte brief wordt gemaakt, dan worden de NAW gegevens van het Kontakt-/Maatbrief verwerkt in dat DocumentMasker, en daarna wordt het document gemerged naar een nieuw document, zijnde onze brief. De brief zelf bevat daarna géén MailMerge bestand meer !
Dit heeft een aantal voordelen:
* het Mailmerge bestand blijft niet geopend door de brief, en dus kunnen we direkt weer een nieuwe brief maken
* tijdens het maken van een Maatbrief, kunnen we een andere openen om iets uit te kopieren
* zouden we een brief nu buiten Profit om openen (omdat we weten waar deze worden opgeslagen), dan hebben we daar altijd de juiste NAW gegevens in staan ! (in de oude situatie kon je weliswaar het worddocument openen, maar het haalde de NAW gegevens van de laatst bekeken brief in Profit op, en kon daarmee totaal andere NAW gegevens tonen boven de brief).
Er is ook een nadeel:
* Zonder Mailmerge bestand kunnen we niet gebruik maken van Word's "Merge to Email" funktionaliteit. Als we een Maatbrief zouden maken en deze zouden adresseren aan "
persoon@ontvanger.nl", dan was ook het Emailadres van de ontvanger een van de samenvoegvelden uit het MailMerge bestand. Bij het gebruiken van "Merge to Email" kon dan worden ingesteld dat het document moest worden gemaild naar het email adres welke in samenvoegveld "Email_ontvanger" beschikbaar werd gesteld. Omdat het nieuwe document nu geen samenvoegbestand meer kent, is dat niet meer mogelijk.
De hiervoor gestelde oplossing is het opnemen van het Emailadres in het document zelf (die door de Merge naar nieuw dokument dan vanzelf wordt opgenomen in het nieuwe dokument), en deze dan te knippen-/plakken.
Merk overigens op dat de nieuwe methode waarbij er wordt samengevoegd naar een nieuw dokument om deze reden
niet operationeel is bij Mailingen van zgn. Standaard Dokumenten. Dit, omdat als we een mailing zouden maken naar 200 Relaties, het kiezen is tussen òf wél met een Samenvoegbestand werken en met 1 handeling een email naar 200 geadresseerden te kunnen sturen òf zónder Samenvoegbestand te werken en daarna zelf nog 200 keer een emailadres moeten knippen en plakken en versturen. Dat laatste is sowieso niet werkbaar.
De nieuwe methode geldt daarmee alleen voor Maatbrieven en normale Kontaktverslagen, wat ook impliceert dat alleen op dát niveau we meerdere documenten tegelijk geopend kunnen houden (omdat deze niet het Samenvoegbestand in gebruik houden).
Escape Hoewel het mergen naar een nieuw dokument (zonder Samenvoegbestand) de nieuwe standaard is geworden, is het toch mogelijk om dit weer uit te schakelen. Bij de Windows Editor is een rubriek opgenomen waarmee kan worden aangegeven dat Kontakten en Maatbrieven toch gewoon met een Samenvoegbestand moeten werken. Hiermee kan dan wel weer een mailmerge naar Email worden uitgevoerd, maar vervalt de mogelijkheid om meeerdere Word documenten tegelijk geopend te hebben die met een Samenvoegbestand werken.
| Funktie | Omschrijving | Dtm.Vl.Wyz | Dtm.L.Wyz |
| LOTXWG | Weergeven tekst | 27-02-2014 | 01-05-2014 |
| PKKOKA | Omschrijving (nog) niet bekend | 28-03-2012 | 01-05-2014 |
| PKKOWITV | Toevoegen Kontakt | 26-10-2005 | 01-05-2014 |
| PMBNGN | Omschrijving (nog) niet bekend | 15-07-2011 | 01-05-2014 |
| PMMBTV | Omschrijving (nog) niet bekend | 29-03-2012 | 01-05-2014 |
| PMPRBKML | Printen Brief | 29-03-2012 | 07-05-2014 |
| PMPRBV | Omschrijving (nog) niet bekend | 14-05-2010 | 07-05-2014 |
| SYFMDF | Omschrijving (nog) niet bekend | 05-10-2012 | 01-05-2014 |
| SYSS | Omschrijving (nog) niet bekend | 25-04-2014 | 01-05-2014 |
| SYTX | Tekstmechanisme | 24-12-2013 | 30-04-2014 |
| SYWERA | Raadplegen WIN Applikaties | 06-05-2014 | 07-05-2014 |
