Hi John, I use Innosetup, you may have a look at this link for how to do it: http://www.jrsoftware.org/iskb.php?bde
Also, I install BDE under "c:\pf" (or other path) instead of normal "C:\Program Files". When I run BDE Administrator, I use admin (run as administrator) right. I have a few clients using Win7 + BDE without problem. Hope it helps. Regards Rodney Chan -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Wednesday, 16 May 2012 3:18 p.m. To: [email protected] Subject: Delphi Digest, Vol 103, Issue 13 Send Delphi mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit http://listserver.123.net.nz/mailman/listinfo/delphi or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of Delphi digest..." Today's Topics: 1. Re: Hang during Sleep (Jeremy Coulter) 2. BDE installer Windows 7 (John Bird) 3. Re: Hang during Sleep (Jolyon Smith) 4. Re: MSSQL DBGrid Refresh (John Bird) ---------------------------------------------------------------------- Message: 1 Date: Wed, 16 May 2012 14:33:15 +1200 From: Jeremy Coulter <[email protected]> Subject: Re: [DUG] Hang during Sleep To: NZ Borland Developers Group - Delphi List <[email protected]> Message-ID: <cagyhmgg7hwr3s6nykgnqegggmp7fehsn1qv1j9vis3gdjoi...@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" so Jolyon , what would YOU use in this scenario in place of sleep? You indicated Sleep was prob. not the best solution, but didnt indicate what would be a GOOD solution :-) Jeremy On Wed, May 16, 2012 at 9:05 AM, Jolyon Smith <[email protected]> wrote: > > Still wondering how a sleep can hang. > > This is actually quite easily explained. > > Sleep() is an indication to the Windows thread scheduler that your > thread is willing to relinquish whatever timeslice it currently has. > Whether and when that thread get's another bite at the CPU is now in > the hands of the Windows Scheduler. > > "Sleep(100)" comes with no guarantee that your thread will resume > execution after 100 milliseconds, all it ensures is that your thread > stops running and absolutely won't run again for AT LEAST that time > (give or take, subject to clock resolution). If there are other > higher priority threads demanding access to the CPU then your thread > can easily find itself being shunted to the bottom of the queue until > those threads have done ALL their work. > > Given the nature of the application you describe, which seems to > involve some sort of multimedia content, I am guessing that even > within your process - never mind anything else that might be running > on the same machine - you have one or more other threads that you have > most likely set to higher than normal priority - the nature of > multimedia being what it is, you may even have a "realtime" priority thread in the mix somewhere. > > That would easily explain why when you relinquish your main UI > thread's timeslice it doesn't get a look-in until much, much later > than you are expecting. > > _______________________________________________ > NZ Borland Developers Group - Delphi mailing list > Post: [email protected] > Admin: http://delphi.org.nz/mailman/listinfo/delphi > Unsubscribe: send an email to [email protected] > with > Subject: unsubscribe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://listserver.123.net.nz/pipermail/delphi/attachments/20120516/ae23e125/ attachment-0001.html ------------------------------ Message: 2 Date: Tue, 15 May 2012 16:48:17 +1200 From: "John Bird" <[email protected]> Subject: [DUG] BDE installer Windows 7 To: "NZ Borland Developers Group - Delphi List" <[email protected]> Message-ID: <F3826953BEDD4330893D3B2B54702132@JohnSony2> Content-Type: text/plain; charset="utf-8" A firm with legacy software using BDE from Delphi 5 is upgrading workstations to Windows 7, or will as soon as they can find an installer for the BDE. We know the BDE will run on Windows 7, as it is part of D2007 and XE2 and is on my Windows 7 PC here, installed as part of later Delphi. Its even the exact same version of the BDE as far as I recall, unchanged from Delphi 5. The problem is only the installer ? (it does forbidden things I suspect such as putting configuration files under the Program Files folder). They are also upgrading to later Delphi, but the replacing workstations comes first. Does anyone know of a separate installer for the BDE alone for Windows 7? (In D2007 it?s buried in the huge IDE install). John Bird -------------- next part -------------- An HTML attachment was scrubbed... URL: http://listserver.123.net.nz/pipermail/delphi/attachments/20120515/5d4cbe31/ attachment-0001.html ------------------------------ Message: 3 Date: Wed, 16 May 2012 15:12:47 +1200 From: Jolyon Smith <[email protected]> Subject: Re: [DUG] Hang during Sleep To: NZ Borland Developers Group - Delphi List <[email protected]> Message-ID: <calxexorhtv16vce6twxre9m9fq2pbhbcvzk2huc56tvmgjx...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" Um, yes I did - I suggested either a waitable timer or an event. It's impossible to say with certainty what would be the "right" way without more intimate knowledge of the code. The main thing would be to refactor the worker code into a thread and keep the UI thread doing what it's best at - maintaining the UI - with whatever mechanism is necessary to allow the UI to obtain the information it needs to maintain currency w.r.t the activity in the worker thread(s). On 16 May 2012 14:33, Jeremy Coulter <[email protected]> wrote: > so Jolyon , what would YOU use in this scenario in place of sleep? > You indicated Sleep was prob. not the best solution, but didnt > indicate what would be a GOOD solution :-) > > Jeremy > > On Wed, May 16, 2012 at 9:05 AM, Jolyon Smith <[email protected]>wrote: > >> > Still wondering how a sleep can hang. >> >> This is actually quite easily explained. >> >> Sleep() is an indication to the Windows thread scheduler that your >> thread is willing to relinquish whatever timeslice it currently has. >> Whether and when that thread get's another bite at the CPU is now in >> the hands of the Windows Scheduler. >> >> "Sleep(100)" comes with no guarantee that your thread will resume >> execution after 100 milliseconds, all it ensures is that your thread >> stops running and absolutely won't run again for AT LEAST that time >> (give or take, subject to clock resolution). If there are other >> higher priority threads demanding access to the CPU then your thread >> can easily find itself being shunted to the bottom of the queue until >> those threads have done ALL their work. >> >> Given the nature of the application you describe, which seems to >> involve some sort of multimedia content, I am guessing that even >> within your process - never mind anything else that might be running >> on the same machine - you have one or more other threads that you >> have most likely set to higher than normal priority - the nature of >> multimedia being what it is, you may even have a "realtime" priority thread in the mix somewhere. >> >> That would easily explain why when you relinquish your main UI >> thread's timeslice it doesn't get a look-in until much, much later >> than you are expecting. >> >> _______________________________________________ >> NZ Borland Developers Group - Delphi mailing list >> Post: [email protected] >> Admin: http://delphi.org.nz/mailman/listinfo/delphi >> Unsubscribe: send an email to [email protected] >> with >> Subject: unsubscribe >> > > > _______________________________________________ > NZ Borland Developers Group - Delphi mailing list > Post: [email protected] > Admin: http://delphi.org.nz/mailman/listinfo/delphi > Unsubscribe: send an email to [email protected] > with > Subject: unsubscribe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://listserver.123.net.nz/pipermail/delphi/attachments/20120516/ed550204/ attachment-0001.html ------------------------------ Message: 4 Date: Wed, 16 May 2012 15:17:28 +1200 From: "John Bird" <[email protected]> Subject: Re: [DUG] MSSQL DBGrid Refresh To: "NZ Borland Developers Group - Delphi List" <[email protected]> Message-ID: <9748CB3360E840A581DD21120043B512@JohnSony2> Content-Type: text/plain; charset="iso-8859-1" You could try DBGrid.Datasource:=nil; DBGrid.Datasource:=ADOTable1; //this should force a redisplay, as nilling it clears the grid. Thats a tip I saw in the help for KBMemTable (superset of ClientDataSet) which had all sorts of tips for speeding up loading and displays. That tip will speed up posting lots of data etc as the DBGrid will not be showing the updates (which also can cause flickering). Turning it on afterwards shows the current state after all the updates have finished. John Bird From: Eric A Sent: Tuesday, May 15, 2012 8:51 PM To: [email protected] Subject: [DUG] MSSQL DBGrid Refresh I am using a DBGrid with an ADOQuery component for display, with modifications to table data (edits, deletes, adds) being done using a ADOTable component. CRUD operations are done using the table methods rather than raw SQL code. There's a lot of fields in the database table so coding the operations in SQL would be a pain. Despite trying to refresh the data in the DBGrid by closing then re-opening both the ADOTable and the ADOQuery component the data in the DBGrid is not updated (unless I exit the application and restart. I've seen this problem mentioned in various postings but haven't yet seen a solution. Can someone supply the elusive technique to get the DBGrid data to refresh after the ADOTable data is changed? Eric. ---------------------------------------------------------------------------- ---- _______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: [email protected] Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [email protected] with Subject: unsubscribe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://listserver.123.net.nz/pipermail/delphi/attachments/20120516/2c07e2a2/ attachment.html ------------------------------ _______________________________________________ Delphi mailing list [email protected] http://listserver.123.net.nz/mailman/listinfo/delphi End of Delphi Digest, Vol 103, Issue 13 *************************************** _______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: [email protected] Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to [email protected] with Subject: unsubscribe
