[delphi 6] op win 2000 compilen voor 98

[douweh]

Hoi allemaal,

klein probleempje, programmatje gescreven voor iemand, of eigenlijk een heleboel programmetjes, die 1 simpele bewerking uitvoeren op verschillende tekst bestandjes..

Wat is het idee, ik heb in flash een soort quiz gemaakt, het aantal keer dat gestemd wordt houdt hij bij in allerlei textbestandjes...

formaat (antwoord1a.txt)----

code:

stemmen=3

Omdat flash geen paramters meer mee kan geven aan externe programma's heb ik dus voor elke antwoord mogelijkheid een exe gemaakt, en een txt bestandje.

ook is er nog een centraal beheer programma, dat alle stemmen uitleest, en grafiek van maakt enzo.


probleem is nu dat ik het spul werkend heb gemaakt in delphi 6 op windows 2000, en nu blijkt het te moeten draaien op 98..
is daar nog wat aan te doen?

[jelmervos]

Moet toch gewoon werken? Met Delphi maak je toch gewoon Win32 applicaties?

[OZ-Gump]

Als je een installatie maakt met eventueel benodigde bestanden (vooral als je het vinkje bij 'Build with runtime packages' hebt aanstaan ) is er geen enkel probleem om jouw progjes te draaien op een Win98 bak.

Zou lekker worden als je elke applicatie op elke Windows versie apart zou moeten compileren

[douweh]

krijg net van de gebruiker door,
flink klote hij is ergens anders met de win98 pc, en ik kan er niet heen,
dat zo'n programmatje een "Kan het Field niet vinden " oid error geeft.

Komt daat iemand bekent voor?

[OZ-Gump]

Maak je gebruik van een database? En zo ja, heeft de gebruiker de laatste versie met de juiste veldnamen in alle tabellen?

Enige wat je nu op afstand waarschijnlijk nog kunt doen is aan de gebruiker vragen wanneer de fout zich voordoet (welke handeling wordt uitgevoerd) en dan in je code kijken welke dingen er daar gebeuren en welke de fout zouden kunnen veroorzaken. Wij kennen de progjes sowieso al niet, dus we kunnen je niet helpen. Al helemaal niet zonder code of een plaats waar iets fout gaat...

Wanneer je gebruik maakt van bijvoorbeeld ADO is het in ieder geval aan te raden de gebruiker MDac 2.8 en Jet 4.0 SP 8 te laten installeren. Dit omdat daar ook nog wel eens rare dingen met databasetoegang in willen zitten.

[ Voor 12% gewijzigd door OZ-Gump op 07-01-2004 11:28 ]

[douweh]

ik zal ff de code van het programmatje opsturen, het doet echt niks bijzonders,,
enige dat het doet is het openen van een bestandje, en het weer wegschrijven van het bestandje nadat het aantal stemmen met 'e'en verhoogd is

delphi code:

Delphi:

procedure TForm1.FormCreate(Sender: TObject);
var F: TextFile;
s,s2: String;
i: Integer;
begin
  AssignFile(F, 'antwoord3c.txt');
   Reset(F);
  Readln(F,s);
  s2:='';
  Rewrite(F);
  For i:=9 to Length(s) do s2:=s2+s[i];
  Writeln(F, 'stemmen='+IntToStr(StrToInt(s2)+1));
  CloseFile(F);
  Application.Terminate;
end;

Ik weet het beetje omslachtig, om dit met een form applicatie te doen, maar ik had toen ff geen zin om een console te schrijven, wist niet meer goed hoe dat moest, en moest snel voor elkaar..

[OZ-Gump]

Ik zie een paar enge dingen in je applicatie. En dat zijn de volgende:

1. Je Assigned de file zonder pad. Je gaat er dus van uit dat de file in dezelfde map staat als de executable. Wanneer je een desktop shortcut aanmaakt, en de applicatie van daar start, wordt vaak de 'Starten in' van de shortcut niet ingevuld. En dus wordt het bestand niet gevonden. Denk hier aan ExtractFilePath in combinatie met Application.ExeName
2. Je gebruikt een for-loop in combinatie met vaste lengtes. Als daar dus iets verandert of niet klopt, werkt je app niet meer. Waar niet Pos en Copy gebruiken?
3. Je doet NIETS aan foutafvanging. Wat gebeurt er als er een waarde in S2 komt die niet te StrToInt-en is? (bijvoorbeeld)
4. Ik neem dat je S2 daar initialiseert op een lege string? Of zet je er echt een spatie in?

Misschien dat het verschil uitmaakt als je hier eens een beetje naar gaat kijken. En de precieze foutmelding is natuurlijk ook wel nuttig....

[douweh]

je hebt volkomen gelijk, zijn allemaal slordige fouten, maar is dus gewoon omdat het snel in elkaar moest, aan alle benodigde voorwaarden wordt ook voldaan op de win98 pc, hier kan het probleem dus niet in zitten..

Nog iemand een ander idee,
ik zal ff de preciese foutmelding proberen te achterhalen

[curry684]

OZ-Gump schreef op 07 januari 2004 @ 11:13:
Zou lekker worden als je elke applicatie op elke Windows versie apart zou moeten compileren

Bij ieder Service Pack worden ook vrijwel alle Windows systeem-DLL's vervangen. Je moet dus ook recompilen voor alle 6 NT4 SP's, 4 Win2K SP's etc.

[Creepy]

OZ-Gump schreef op 07 januari 2004 @ 11:40:
• Je Assigned de file zonder pad. Je gaat er dus van uit dat de file in dezelfde map staat als de executable. Wanneer je een desktop shortcut aanmaakt, en de applicatie van daar start, wordt vaak de 'Starten in' van de shortcut niet ingevuld. En dus wordt het bestand niet gevonden. Denk hier aan ExtractFilePath in combinatie met Application.ExeName

Het is zelfs nog leuker. Als je je applicatie start, gaat het goed. Op een later moment wordt er weer zo'n bestand zonder pad ingelezen, en gaat het ineens mis. Wat blijkt: een andere applicatie heeft doodleuk de huidige directory aangepast (welke globaal is voor het systeem ).

[curry684]

Creepy schreef op 07 januari 2004 @ 11:53:
[...]

Het is zelfs nog leuker. Als je je applicatie start, gaat het goed. Op een later moment wordt er weer zo'n bestand zonder pad ingelezen, en gaat het ineens mis. Wat blijkt: een andere applicatie heeft doodleuk de huidige directory aangepast (welke globaal is voor het systeem ).

LOL dat zou wat zijn, dan zou je vanuit het ene command-window de CD van de andere kunnen veranderen

Nee hoor, gelukkig is daar door de baas beter over nagedacht:

Remarks
Each process has a single current directory made up of two parts:
• A disk designator that is either a drive letter followed by a colon, or a server name and share name (\\servername\sharename)
• A directory on the disk designator

[OZ-Gump]

Toch meen ik me ook iets dergelijks te kunnen herinneren. Het kan echter zijn dat die herinnering teruggrijpt op een applicatie die zelf een Open- of SaveDialog aanriep, en dat derhalve de Current Directory van de applicatie gewijzigd werd. Daarom mijn conclusie: jullie hebben dus allebei gelijk

Het is applicatie-afhankelijk, maar kan wel fout gaan in combi met open- of savedialogs.

[curry684]

OZ-Gump schreef op 07 januari 2004 @ 12:05:
Toch meen ik me ook iets dergelijks te kunnen herinneren. Het kan echter zijn dat die herinnering teruggrijpt op een applicatie die zelf een Open- of SaveDialog aanriep, en dat derhalve de Current Directory van de applicatie gewijzigd werd. Daarom mijn conclusie: jullie hebben dus allebei gelijk

Het is applicatie-afhankelijk, maar kan wel fout gaan in combi met open- of savedialogs.

Kan niet fout gaan in combi met dialogs, ook die kunnen alleen de current dir van hun eigen process veranderen, en zelfs dat alleen als je 'm daar expliciet opdracht toe geeft

Wat had je in gedachten bij een Dialog die in een andere process space draait of zoiets?