|
Title: Technische versie 4.14l Windows Post by: Heart Informatisering B.V. on August 07, 2001, 03:16:02 pm Deze technische versie voor Windows, 4.14l, Class-versie 0.99z omvat de volgende aanpassingen die i.h.a. kunnen worden omschreven als cosmetisch :
- Forms met Tabbladen toonden de Tab's op onjuiste positie in bepaalde gevallen. Dit is nu opgelost. - Een gemaximaliseerd Form met Tabbladen toonde de "kaders" op onjuiste plaatsen. De Kaders konden hierbij zelfs dwars door gegevens heen komen te staan. Dit is opgelost. N.b.: De oorzaak van dit euvel heeft waarschijnlijk ook veroor zaakt dat bij het werken onder een resolutie van 800 x 600 eveneens van alles door elkaar kon komen te staan aangaande Kaders. Zeker is dit niet, dus dit kan nog steeds in voorkomende gevallen fout gaan. - Forms met Tabbladen die a.g.v. het vertikaal niet passen (zie ook vorige punt) rechts een Scrollbar krijgen, konden in bepaalde situaties weer zaken "door elkaar" tonen. Dit is nu opgelost. Ook is bij Forms met een Kop (het zwarte gedeelte bovenin het Form), de Scrollbar meer verantwoord geplaatst, evenals de OK-button op het Form met Tabbladen. De Kop is ook doorgetrokken tot boven de Scrollbar, c.q. de Scroll bar begint nu lager (begon feitelijk te hoog). - Grid's en Forms t.b.v. het Toevoegen en Wijzigen van gegevens kunnen nu als "gemaximaliseerd" bij de gebruiker worden vastgelegd middels de Button met het "slotje" in de HoofdToolbar (links). Hiervoor moet het betreffende Form eerst worden gemaximaliseerd, en vervolgens worden "vastgelegd" met genoemde Button; Het Form zal nu iedere keer in gemaximaliseerde toestand opstarten. Maar let op : Net zoals gebruikelijk bij dit Vastleggen, wordt dit alleen gedaan voor de kombinatie van het gewenste te maximaliseren Form met het Form (de funktie) van waaruit het Form wordt aangeroepen. - In bepaalde gevallen kon het voorkomen dat de Kaders op het Form onterecht aanwezig waren, met het gevolg dat deze door andere Kaders dan wel gegevens heen kwamen te staan. Dit is nu opgelost, met de opmerking dat het in theorie zo kan zijn dat Kaders nu andere "rariteiten" vertonen. N.b.: Dit betreft een ander punt als de eerder genoemde punten aangaande de Kaders. - In bepaalde situaties werd een Form met Tabbladen onjuist opgebouwd (zaken door elkaar) op het moment dat het werd versleept. Dit is opgelost. - Indien een (vertikale) Scrollbar op het Form verscheen a.g.v. het niet (meer) passen van het Form in de hoogte, kwam het bij bepaalde funkties voor dat de Kaders de gegevens rechts deels overschreven, althans daar doorheen kwamen te staan. Dit is nu opgelost. - Het aktiveren van Grid's is verbeterd, in die zin dat een Grid de aktieve regel nu kan tonen onderin het Grid, waar dit voorheen immer bovenin het Grid stond, en de regels erboven niet zichtbaar waren omdat ze buiten het Grid vielen, maar met onder de aktieve regel verder niets omdat het het laatste record in de betreffende tabel betrof (betreft). Een aktieve regel het de laatste record in de tabel betreft, kan nu onderin het Grid worden getoond, met (de) andere records erboven. N.b.: Dit wil niet zeggen dat er geen enkele situatie meer is dat het Grid slechts 1 (bovenste) regel toont, maar dan is dit ook zo bedoeld, en zou in de Dos-versie ook zo werken. - Indien in een Grid ^PgDn werd gedaan, dan kon het voorkomen dat het laatste record in de betreffende tabel niet als de aktieve regel werd getoond, dan wel dat op andere wijze niet werd getoond dat logischerwijs werd verwacht. Dit is nu opgelost, en betrof deels een situatie die slechts tijdelijk aanwezig is geweest (vanaf begin juli 2001), maar ook deels een situatie die immer zo (onlogisch) heeft gewerkt. Is niet hetzelfde als het voorgaande punt. - Een h**kel punt betreft immer het Printen, wat voor een goed deel buiten onze macht ligt, aangezien het "Windows" is wat dit complex maakt; Deze versie bevat de oplossing voor meerdere "rariteiten" die ontstonden a.g.v. voor Profit onverwachte situaties, met als voorbeeld het ooit onder een NT-machine hebben geprint (van een Print-funktie), die vervolgens door dezelfde gebruiker wordt opgestart onder een W95/98 machine, alwaar alles anders wordt afgehandeld. Het gevolgd (ook weer slechts een voorbeeld) kon zijn dat het systeem meldde dat een Printer niet bestond, dus om een te selekteren printer vroeg, gevolgd door weer dezelfde melding en het terugkeren naar het Hoofdmenu. Een aantal van dit soort onderkende zaken zijn nu opgelost. - Het selekteren van een Printer middels de daarvoor bestemde Button in de HoofdToolbar (links) (printertje) loopt nu via de standaard Printerselektie van Windows, gevolgd door het Grid wat voorheen meteen werd opgestart als deze Button werd gebruikt. Daarnaast toont het Grid dat verschijnt ter bevestiging F4___ dan wel F5___ van de eerder geselekteerde Printer (en Driver) nu de geselekteerde Printer met Driver bovenaan in het Grid. N.b.: Deze werkwijze zal in de nabije toekomst nog weer kunnen wijzigen, en hangt op zich af van de rariteiten die nú weer kunnen ontstaan, en die ook niet kunnen worden voorspeld a.g.v. alle kombinaties in Netwerk-OS en PC-OS. - Gesteld mag worden dat Profit (ook Dos) geschikt is voor Windows 2000, wat weliswaar hier en daar door gebruikers al werd toege past, maar nu formeel door ons is getest en goedgekeurd. Wel de volgende opmerkingen : * MS heeft de "standaard" kleuren van Windows aangepast, en wat zich met name in een andere schakering van grijze tinten uit. Dus, de standaard is veranderd, met het gevolg dat in Profit op een aantal plaatsen de standaard van voorheen (donkerder grijs) zichtbaar is tussen de standaard van nu (lichter grijs). Bijvoorbeeld de Menu's tonen dit onmiddellijk, evenals de Buttons. Een echte oplossing hebben wij nog niet, doch het advies is om bij de Monitor-Eigenschappen en dan "Vormgeving", als Schema "Windows-klassiek" te kiezen. Nu is alles weer zoals gebruikelijk. * Als Profit via een icoon op de desktop wordt opgestart met daarin de verwijzing naar een Batchfile (.BAT), zal de Dos-box die hier door wordt geaktiveerd zichtbaar blijven staan, totdat Profit weer wordt afgesloten. Dit kan worden verholpen door de gebrui kelijke regel in de .BAT <d:>FOXSYSYPPPROFIT.EXE) te veranderen naar START <d:>FOXSYSYPPPROFIT.EXE ... Verder kan in de eigenschappen van de icoon bij "Snelkoppeling" worden aangegeven bij "Uitvoeren" dat in geminimaliseerde toestand moet worden opgestart, en wat alleen voor de .BAT zal gelden. Merk op dat dit niet alleen voor Windows-2000 geldt maar zie ook het volgende punt. * Let op : Als gevolg van voorgaande, zal de Command-interpreter van Windows-2000 meteen doorgaan naar de volgende regel, en die dus ook uitvoeren ! Voor die gebruikers die het "netjes" doen, en die in de .BAT een CALL C:TROEPCMND.BAT hebben staan (benodigd voor Upgrades !) geldt nu dus als voorgaande punt wordt doorgevoerd, de CMND.BAT meteen wordt uitgevoerd (kan geen kwaad) maar ook dat deze bij afsluiten van Profit niét meer wordt uitgevoerd (kan wel kwaad !). Aldus, iedereen die dit zo heeft, en die van de Taak met deze Batchfile af wil (voorgaande punt), zal dit moeten veranderen; Op welke wijze dit ook gebeurt, de CMND.BAT kan dan dus niet meer worden uitgevoerd, wat ertoe heeft geleid dat Profit nu zelfstan dig de CMND.BAT kan uitvoeren, maar ... ook zàl uitvoeren. Dit op zich houdt in dat de CMND.BAT niet meer màg worden aangeroepen door de Batchfile; in een volgende versie zal Profit er voor zorgen dat CMND.BAT leeg wordt gemaakt meteen nadat ze is uitgevoerd. N.b.: Wij kunnen momenteel niets herkennen wat echt fout zou zijn om twee keer uit te voeren, dus vooralsnog zal dit per abuis dubbel uitvoeren geen kwaad kunnen. * Het werken in een Dos-editor is zo mogelijk nog slechter (lees : trager v.w.b. het tonen van getypte characters) dan onder NT4. Wij hebben nog niet onderzocht of dit verbeterd kan worden, wat onder NT4 nog enigszins mogelijk was. * Het klikken met de muis kent op de e.o.a. manier een reaktie snelheid die niet juist is; dit lijkt alleen het geval voor juist standaard Windows-zaken, en niet voor Profit-buttons. Bijvoorbeeld, het maximaliseren van een Form middels de standaard Windows-button "maximaliseren", lukt alleen goed als de muis wat rustiger wordt ingedrukt en losgelaten; wordt er te snel geklikt, dan volgt er geen reaktie. * Verwacht mag worden dat het in Windows-2000 niet meer nodig is om bij "zwaar gebruik" (door de ene gebruiker op de ene PC) op regelmatige basis de PC opnieuw te moeten opstarten, opdat het geheel weer wat snelheid krijgt (heeft te maken met onjuiste afhandeling van de Windows-swapfile in zowel W95/98 als NT4 -> beiden op een andere onjuiste wijze). Wel lijken wij te konstateren dat in bepaalde situaties netwerk-aktiviteit trager is onder Windows-2000, en wat in elk geval in de Dos-versie van Profit kan worden bemerkt. - De FormToolbar werd immer weergegeven na een bepaalde "timeout". en wat gebeurde om de (processor)tijd die dat kost, opdat het betreffende Form zo snel als mogelijk kon worden weergegeven, en de FormToolbar later "op een rustig moment". Echter, de PC's van tegenwoordig zijn dermate snel, dat het niet verantwoord meer wordt geacht om deze werkwijze te hanteren, die immers een suggestie in zich heeft van "lang moeten rekenen" voordat de Toolbar kan worden getoond. Aldus wordt vanaf heden de Toolbar onmiddellijk getoond, behoudens die voor de Menu's, die immers altijd eenzelfde inhoud hebben v.w.b. de Toolbar (Esc). N.b.: Omdat niet iedereen voldoende snelle PC's heeft wat volgens bovenstaande het uitgangspunt is, kan de tijd dat het duurt voordat de Toolbar verschijnt (nog steeds) per PC worden overruled. Dit werkt niet anders als voorheen, alleen voorheen was de standaard waarde 2000 ms, waar dit nu 1 ms is. Zie SY-Trefwoord CONFIG.HRT onder TimerFormToolbar. - Rechts bovenin het scherm kan een grijs kader verschijnen met "xxxx is geen Object in CLWYFRM.InitForm", wat een aanduiding betekent van een afgevangen foutsituatie; Een belangrijke oorzaak hiervoor is per heden opgelost, met de kans dat deze melding nu niet meer verschijnt (was sowieso zeldzaam).
|