Re: [DUG] Installing Delphi 7 onto laptop with no CD drive
40GB ? Wow, I'm guessing that's all the iOS/Android FireMonkey/FireDAC cr**, uh, extras ? XE4 Pro (Win32/64 only) consumes less than 10% of that! On 10 August 2015 at 09:55, Jeremy North jeremy.no...@gmail.com wrote: I only have 14GB left on my SSD - gone are the days when 8GB was big enough for everything I needed. You need around 40GB free on C drive to install the newer IDE releases. Very ordinary. On Mon, Aug 10, 2015 at 7:45 AM, Steve Peacocke st...@peacocke.net wrote: Hi Guys, Yes, Gary reminded me that it was on a very, very old email address that I registered that old D7. Does anyone know if I can install XE2 onto an external drive? I only have 14GB left on my SSD - gone are the days when 8GB was big enough for everything I needed. Steve On Mon, Aug 10, 2015 at 9:41 AM, Willie wil...@compliant.co.nz wrote: M it shows all of mine, well back to Delphi 7 at least, which I apparently registered in 2003. Maybe you registered it under a different company? *From:* delphi-boun...@listserver.123.net.nz [mailto: delphi-boun...@listserver.123.net.nz] *On Behalf Of *Steve Peacocke *Sent:* Monday, 10 August 2015 9:37 a.m. *To:* NZ Borland Developers Group - Delphi List delphi@listserver.123.net.nz *Subject:* Re: [DUG] Installing Delphi 7 onto laptop with no CD drive Hi Willie, Gret though and went there - but it only shows XE2 upgrade registration, even though I joined this when I registered with D2007 (CodeGear then). Steve On Mon, Aug 10, 2015 at 9:30 AM, Willie wil...@compliant.co.nz wrote: Hi Steve, Log into your embarcadero account (I think you can do this through the developer network home page) then select the My Account link at the top of the page, and in the left hand side you should see My member Services/My Registered Products – that lists all of your products and gives serial numbers – quite handy in such situations. *From:* delphi-boun...@listserver.123.net.nz [mailto: delphi-boun...@listserver.123.net.nz] *On Behalf Of *Steve Peacocke *Sent:* Monday, 10 August 2015 9:15 a.m. *To:* NZ Borland Developers Group - Delphi List del...@delphi.org.nz *Subject:* [DUG] Installing Delphi 7 onto laptop with no CD drive Hi Everyone, I need to create a few small applications on my work computer that is a laptop with no CD drive. I figure Delphi 7 is all I need to create the few small apps that I need to manipulate some XML here and as my work laptop has a small SSD drive, D7 will be far better to install than XE2. I have 2 questions: 1. Where can I legitimately download D7 onto a computer without a CD drive? 2. Without the original CD, where will I find my D7 serial number? - I have it on the original CD, but finding that will mean opening up all of the old boxes taking up that side of the garage as I've moved numerous times since I bought the original D7 CD with the serial number. Only later versions (my e.g. XE2) emailed the registration, previous versions had it printed on the CD or box, I legitimately own both D7 and XE2 (Professional, both versions). I logged into CodeCentral and downloaded Delphi7 but that download is only to burn a CD. As mentioned, I don't have a CD drive, I've got a small SSD with only 14GB left. I do have an external 1TB drive, but expect that Delphi, like everything else, will insist on installing onto C: drive. I was told that having XE2 will allow you to download all previous versions but that link simply states this promotion is over - so another dead end there. Steve Peacocke Mobile: +64 220 612-611 Linkedin Professional Profile http://nz.linkedin.com/pub/steve-peacocke/1/a06/489 ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post:
Re: [DUG] EMBARCADERO MY GRIPE
Well I tried installing Xamarin in order to rebuild my simple app using that, to do a precise like-for-like comparison both in terms of performance and development experience. But Xamarin insisted that I didn't have the necessary components of the Android SDK or JDK, despite pointing it at my current installations. The installations that are supporting my current Android development perfectly adequately. The Xamarin installer insisted that it was necessary to update these installations but wouldn't tell me exactly what it was going to do to them and since I didn't wish to risk breaking my current development stack I've had to postpone this exercise until I can spare the time to stand up a sandbox for the Xamarin environment. By comparison with Elements, when you install that if you already have these SDK's it simply uses them. If you don't, it directs you to download and install them. Any impact on the environment is then no different than the impact on a platform native Android development stack. i.e. you can only target API levels and framework libraries etc that you have installed, which you use the Android SDK Manager to manage. If Xamarin has specific requirements that it requires in this area then it really should at least tell you what those are rather than just saying Not good enough, I'm going to change things without saying how. Not a good first impression. On 3 August 2015 at 09:57, Leigh Wanstead leigh.wanst...@gmail.com wrote: Good morning Jolyon, I think that what you want is a benchmark to measure gui performance. In our case app written in java or c# Here is the url http://www.phonearena.com/news/TouchWiz-speed-test-Does-Samsungs-interface-really-lag_id66407 I tried that tool gamebench and it does not test code written in xamarin android. Regards Leigh On 30 July 2015 at 12:51, Leigh Wanstead leigh.wanst...@gmail.com wrote: Hi Jolyon, To be honest, I do not have the time to develop app in java and c# just for benchmark purpose. I can only rely on google. :-) All I can say is the app I developed in Xamarin android is fast enough. To get a server call from Sydney, Australia to North Shore city Auckland, nz takes around 70ms is good enough for me. Without network call, working on local database on the samsung tab 2 tablet, the app's gui response is instant. Regards Leigh On 30 July 2015 at 12:26, Jolyon Smith jsm...@deltics.co.nz wrote: A DSP filter ? Again, focussing on execution efficiency of a highly specialised algorithm, not real world application performance. And there is no reason why you could not incorporate C code in an application where appropriate, even if the bulk of your application does not require or benefit from it. You keep coming up with numbers for what appear to me to be highly artificial benchmarks. These are interesting from a compiler implementation perspective, but not so relevant to real world applications in relation to which you seem to be limited to guess, feel, think. If the advantage were as clear cut as you seem to think then there would be no benchmarks in which the exact opposite were established, yet there are. All we can say then is that the benchmarks are not the whole story. After all (dragging this back peripherally to Delphi), FireMonkey is also a native code solution, but a google of FireMonkey performance does not yield a litany of praise for the advantage of native code (other than from Embarcadero's marketing department). ;) Unless you develop an application in both Xamarin AND in Java and then compare them to each other, you really have no idea whether what you feel is representative or not. The bottom line is that if your application performance is acceptable, then great. That's all you really need be concerned with. But this does not on it's own, nor even in conjunction with unrelated benchmarks, lead to the incontrovertible conclusion that it is the best it could possibly be. imho. ymmv. On 30 July 2015 at 11:52, Leigh Wanstead leigh.wanst...@gmail.com wrote: Hi Jolyon, Android ART is not end of the story. Compare to native c code, android art is slower. Here is the benchmark http://www.learnopengles.com/a-performance-comparison-between-java-and-c-on-the-nexus-5/ It is still around double slower than native c code for android art. You mentioned about bridge issue, I guess it is not a big deal. It is just like network call. Network call is expensive. Any api call to network just increase a little amount of overhead and can be ignored :-) But I am surprised that xamarin async call is half seconds faster than java android in the benchmark I mentioned. :-) I guess the extra time overhead to update title text/ set font size is ignored compared to do the real work. I do not feel slower in my application using xamarin android related to extra overhead api call. I think it is faster than builtin java code in android framework. Regards Leigh
Re: [DUG] EMBARCADERO MY GRIPE
If it's the first/only Android development tool you install (or if you don't care about any existing tools) then I am sure it is straight forward. But if an installer is going to change existing components of some other product/component then it should tell you what changes are required/involved. Also I should have mentioned that the installer failed to detect the Android SDK initially (again, no such problem with Elements) so I had to tell it where the SDK was installed, at which point the installer appeared to be intending to install it's own copy of the SDK *AND* update the existing one. The identified, existing SDK was listed in *addition* to the proposed new installation. First impressions last, as they say. On 3 August 2015 at 11:23, Leigh Wanstead leigh.wanst...@gmail.com wrote: Good morning Jolyon, That is strange. I recall around four or five years ago I installed xamarin android the experience was quite straight forward. It was easier than eclipse to do development. You need to run android sdk manager to get everything up to date of course. Xamarin android rely on google android sdk. Regards Leigh On 3 August 2015 at 10:58, Jolyon Smith jsm...@deltics.co.nz wrote: Well I tried installing Xamarin in order to rebuild my simple app using that, to do a precise like-for-like comparison both in terms of performance and development experience. But Xamarin insisted that I didn't have the necessary components of the Android SDK or JDK, despite pointing it at my current installations. The installations that are supporting my current Android development perfectly adequately. The Xamarin installer insisted that it was necessary to update these installations but wouldn't tell me exactly what it was going to do to them and since I didn't wish to risk breaking my current development stack I've had to postpone this exercise until I can spare the time to stand up a sandbox for the Xamarin environment. By comparison with Elements, when you install that if you already have these SDK's it simply uses them. If you don't, it directs you to download and install them. Any impact on the environment is then no different than the impact on a platform native Android development stack. i.e. you can only target API levels and framework libraries etc that you have installed, which you use the Android SDK Manager to manage. If Xamarin has specific requirements that it requires in this area then it really should at least tell you what those are rather than just saying Not good enough, I'm going to change things without saying how. Not a good first impression. On 3 August 2015 at 09:57, Leigh Wanstead leigh.wanst...@gmail.com wrote: Good morning Jolyon, I think that what you want is a benchmark to measure gui performance. In our case app written in java or c# Here is the url http://www.phonearena.com/news/TouchWiz-speed-test-Does-Samsungs-interface-really-lag_id66407 I tried that tool gamebench and it does not test code written in xamarin android. Regards Leigh On 30 July 2015 at 12:51, Leigh Wanstead leigh.wanst...@gmail.com wrote: Hi Jolyon, To be honest, I do not have the time to develop app in java and c# just for benchmark purpose. I can only rely on google. :-) All I can say is the app I developed in Xamarin android is fast enough. To get a server call from Sydney, Australia to North Shore city Auckland, nz takes around 70ms is good enough for me. Without network call, working on local database on the samsung tab 2 tablet, the app's gui response is instant. Regards Leigh On 30 July 2015 at 12:26, Jolyon Smith jsm...@deltics.co.nz wrote: A DSP filter ? Again, focussing on execution efficiency of a highly specialised algorithm, not real world application performance. And there is no reason why you could not incorporate C code in an application where appropriate, even if the bulk of your application does not require or benefit from it. You keep coming up with numbers for what appear to me to be highly artificial benchmarks. These are interesting from a compiler implementation perspective, but not so relevant to real world applications in relation to which you seem to be limited to guess, feel, think. If the advantage were as clear cut as you seem to think then there would be no benchmarks in which the exact opposite were established, yet there are. All we can say then is that the benchmarks are not the whole story. After all (dragging this back peripherally to Delphi), FireMonkey is also a native code solution, but a google of FireMonkey performance does not yield a litany of praise for the advantage of native code (other than from Embarcadero's marketing department). ;) Unless you develop an application in both Xamarin AND in Java and then compare them to each other, you really have no idea whether what you feel is representative or not. The bottom line is that if your application performance
Re: [DUG] EMBARCADERO MY GRIPE
But Leigh, network round trip times have little or nothing to do with Mono / Dalvik / ART. I shall leave the last word on Xamarin to someone else... http://www.whitneyland.com/2015/07/xamarin-review-2015.html I would also recommend reading the earlier post from the same author. Worth noting in these round-ups is the point about the lack of community assistance when it comes to finding Xamarin solutions to common platform issues (as opposed to the bugs and issues in Xamarin itself). As mentioned before, RemObjects Elements avoids this problem due to the fact that the solutions for Java / Objective-C from the native communities for those platforms, can be applied *directly* in Elements projects in a way that is not often possible with Xamarin. On 29 July 2015 at 15:57, Leigh Wanstead leigh.wanst...@gmail.com wrote: Hi Jolyon, It seems that we are going through the benchmark way :-) I tried to run the app in the url you mentioned and it crashed. How about you look at this url? http://magenic.com/Blog/Post/4/Mobile-Development-Platform-Performance My work is getting data from server which is similar to test 3. java version shows 2.369s and xamarin version shows 1.738s in that url. That is around half seconds difference. I sometimes got around less than 70ms round trip time in my own test to get data from server in sydney, Australian in north shore, Auckland, nz if the server is not busy. That is amazing fast using Xamarin android. Most customers are in Australia. I guess that they might get around 50ms round trip time. Regards Leigh On 29 July 2015 at 14:42, Jolyon Smith jsm...@deltics.co.nz wrote: ... and if only I had a million dollars I would be rich. As for Xamarin performance, consider the source. By which I don't mean the code, I mean who is making what claims. http://stackoverflow.com/questions/17134522/does-anyone-have-benchmarks-code-results-comparing-performance-of-android-ap Any advantage is only seen in an Intel Android VM. On ARM (by far the most prevalent in terms of actual Android hardware), Dalvik beat Xamarin almost every time, until Xamarin.Android 4.7.11. What is odd about this is that these results are from 2013, over a year after Xamarin posted their claims about *astonishingly* superior performance vs Dalvik. It is interesting that Xamarin do not disclose what environment their benchmarks were run in. Also interesting that they do not compare themselves to ART which is the more relevant comparison going forward. In any event, I don't think there is any chance that Google will drop ART any time soon (they already dropped Dalvik) in favour of a Mono based implementation of Android. ;) On 29 July 2015 at 13:51, Leigh Wanstead leigh.wanst...@gmail.com wrote: Hi Jolyon, I mentioned to you before in the thread. If google choose to use mono framework in android, xamarin apk size can reach several kb too. The reason for me to use Xamarin is the app developed by Xamarin using mono framework is faster than dalvik before ART time. The load time for the app is not my main concern. I care about the speed running the app for whole lifecycle. Here is the url https://blog.xamarin.com/android-in-c-sharp/ Regards Leigh On 29 July 2015 at 13:40, Jolyon Smith jsm...@deltics.co.nz wrote: What a fabulous attitude. It's thanks to that sort of thinking that we now need machines with quad core 2.5GHz processors and 8GB of RAM just to run frikkin MS Word. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] EMBARCADERO MY GRIPE
Real world performance of code is more complicated than whether it is compiled native or not, especially when you are talking about a virtual machine running within or on top of a foreign environment. Xamarin.Android code may well be native code, but how efficient that code is comes down to the original compiler and then also the JIT compiler. In addition, most Android applications will spend a lot of time invoking services of the Android platform.itself, so the performance of the code calling those services may have only a very slight bearing on the overall performance of the application. Far more significant is the efficiency of calls made between the application code and the platform services. For any non-platform native approach (Xamarin, FireMonkey) there is necessarily a bridge between the application code and the platform, so any performance advantage of the native code on one side that bridge has to offset the overhead of that bridge before it can offer any real advantage. And with ART, the platform native application code is now also native code so any advantage there is now - theoretically - entirely lost, leaving only the overhead of the runtime/platform bridge. Xamarin's benchmark tests execution efficiency of their generated code in isolation. This is a meaningless benchmark since it entirely ignores the real world impact of the overhead necessarily incurred by having to constantly bridge from their execution environment to the platform services on the device. Maybe Xamarin is faster there too, but if so why not publish some benchmarks demonstrating that to be the case, rather than benchmarks which have no relevance ? Again: Consider the source. Similarly mobile apps tend to spend a lot of time making network calls. As you yourself observed, that can make a big difference in perceived performance which has nothing what-so-ever to do with the execution efficiency of the code *making* the network call. More importantly, all software has bugs - the more software you involve in a solution, the greater the chance of encountering a bug that will adversely affect your application and the harder it could be to identify which component is responsible and obtain a resolution from whichever vendor is responsible for that particular component in your stack. e.g. such as the codegen error in .net framework 4.6 which can introduce bugs even in existing applications. Consider the stacks: Xamarin: Xamarin / Mono compiler Xamarin + Mono frameworks Mono runtime Android Delphi:Delphi compiler FireMonkey framework FireMonkey RTL Android Elements: Elements compiler Android On 30 July 2015 at 11:11, Leigh Wanstead leigh.wanst...@gmail.com wrote: Hi Jolyon, The fastest code on android is native code which is compiled by c code. Xamarin Android is based on runtime library which I guess is compiled in C too. Microsoft's net framework is compile .net code into native code before run the byte code on the real device. Regards Leigh On 30 July 2015 at 11:07, Leigh Wanstead leigh.wanst...@gmail.com wrote: Hi Jolyon, If network round trip time has little or nothing to do with framework, how you explain that url get different time from different framework? I will assume that they will get similar time spent to get data on all framework. Dalvik platform is slow which is agree by google. Dalvik is slower than Sun's jdk on mobile platform I read somewhere on internet. The consideration for dalvik is not speed, but app size. Regards Leigh On 30 July 2015 at 09:06, Jolyon Smith jsm...@deltics.co.nz wrote: But Leigh, network round trip times have little or nothing to do with Mono / Dalvik / ART. I shall leave the last word on Xamarin to someone else... http://www.whitneyland.com/2015/07/xamarin-review-2015.html I would also recommend reading the earlier post from the same author. Worth noting in these round-ups is the point about the lack of community assistance when it comes to finding Xamarin solutions to common platform issues (as opposed to the bugs and issues in Xamarin itself). As mentioned before, RemObjects Elements avoids this problem due to the fact that the solutions for Java / Objective-C from the native communities for those platforms, can be applied *directly* in Elements projects in a way that is not often possible with Xamarin. On 29 July 2015 at 15:57, Leigh Wanstead leigh.wanst...@gmail.com wrote: Hi Jolyon, It seems that we are going through the benchmark way :-) I tried to run the app in the url you mentioned and it crashed. How about you look at this url? http://magenic.com/Blog/Post/4/Mobile-Development-Platform-Performance My work is getting data from server which is similar to test 3. java version shows 2.369s and xamarin version shows 1.738s in that url. That is around half seconds difference. I sometimes got around less than 70ms round trip time in my own test to get data from server in sydney
Re: [DUG] EMBARCADERO MY GRIPE
A DSP filter ? Again, focussing on execution efficiency of a highly specialised algorithm, not real world application performance. And there is no reason why you could not incorporate C code in an application where appropriate, even if the bulk of your application does not require or benefit from it. You keep coming up with numbers for what appear to me to be highly artificial benchmarks. These are interesting from a compiler implementation perspective, but not so relevant to real world applications in relation to which you seem to be limited to guess, feel, think. If the advantage were as clear cut as you seem to think then there would be no benchmarks in which the exact opposite were established, yet there are. All we can say then is that the benchmarks are not the whole story. After all (dragging this back peripherally to Delphi), FireMonkey is also a native code solution, but a google of FireMonkey performance does not yield a litany of praise for the advantage of native code (other than from Embarcadero's marketing department). ;) Unless you develop an application in both Xamarin AND in Java and then compare them to each other, you really have no idea whether what you feel is representative or not. The bottom line is that if your application performance is acceptable, then great. That's all you really need be concerned with. But this does not on it's own, nor even in conjunction with unrelated benchmarks, lead to the incontrovertible conclusion that it is the best it could possibly be. imho. ymmv. On 30 July 2015 at 11:52, Leigh Wanstead leigh.wanst...@gmail.com wrote: Hi Jolyon, Android ART is not end of the story. Compare to native c code, android art is slower. Here is the benchmark http://www.learnopengles.com/a-performance-comparison-between-java-and-c-on-the-nexus-5/ It is still around double slower than native c code for android art. You mentioned about bridge issue, I guess it is not a big deal. It is just like network call. Network call is expensive. Any api call to network just increase a little amount of overhead and can be ignored :-) But I am surprised that xamarin async call is half seconds faster than java android in the benchmark I mentioned. :-) I guess the extra time overhead to update title text/ set font size is ignored compared to do the real work. I do not feel slower in my application using xamarin android related to extra overhead api call. I think it is faster than builtin java code in android framework. Regards Leigh On 30 July 2015 at 11:36, Jolyon Smith jsm...@deltics.co.nz wrote: Real world performance of code is more complicated than whether it is compiled native or not, especially when you are talking about a virtual machine running within or on top of a foreign environment. Xamarin.Android code may well be native code, but how efficient that code is comes down to the original compiler and then also the JIT compiler. In addition, most Android applications will spend a lot of time invoking services of the Android platform.itself, so the performance of the code calling those services may have only a very slight bearing on the overall performance of the application. Far more significant is the efficiency of calls made between the application code and the platform services. For any non-platform native approach (Xamarin, FireMonkey) there is necessarily a bridge between the application code and the platform, so any performance advantage of the native code on one side that bridge has to offset the overhead of that bridge before it can offer any real advantage. And with ART, the platform native application code is now also native code so any advantage there is now - theoretically - entirely lost, leaving only the overhead of the runtime/platform bridge. Xamarin's benchmark tests execution efficiency of their generated code in isolation. This is a meaningless benchmark since it entirely ignores the real world impact of the overhead necessarily incurred by having to constantly bridge from their execution environment to the platform services on the device. Maybe Xamarin is faster there too, but if so why not publish some benchmarks demonstrating that to be the case, rather than benchmarks which have no relevance ? Again: Consider the source. Similarly mobile apps tend to spend a lot of time making network calls. As you yourself observed, that can make a big difference in perceived performance which has nothing what-so-ever to do with the execution efficiency of the code *making* the network call. More importantly, all software has bugs - the more software you involve in a solution, the greater the chance of encountering a bug that will adversely affect your application and the harder it could be to identify which component is responsible and obtain a resolution from whichever vendor is responsible for that particular component in your stack. e.g. such as the codegen error in .net framework
Re: [DUG] EMBARCADERO MY GRIPE
Are you sure about that Leigh? According to Xamarin themselves, selecting Release build specifically turns OFF any shared runtime capability. You can then use smart linking to only include references assemblies to keep the amount of duplicate baggage in that applications copy of the runtime to a minimum. But it is still a copy of the runtime and as far as I can tell, the smallest possible (Hello World) release app in Xamarin is still almost 3 MB (2.9MB to be precise). Of which only 6 KB is the application. The rest is baggage. Those are Xamarin's own numbers, btw. For comparison, consider my fully functional, useful (albeit very simple) TXT-2-PARK app, which weighs in at a massive 20 KB That's not a typo... 20 KILO bytes https://play.google.com/store/apps/details?id=itchbox.txt2park.pro Which is just one reason why truly native apps provide the best UX on mobile devices... a 20 KB app is going to be loaded and running far faster (20KB = virtually instant on!) than an app which has to drag in and bootstrap a runtime engine before it can even start to do the work that the user wants of it, never mind the amount of waste involved in constantly bridging between the runtime and the platform API's. On 29 July 2015 at 11:36, Leigh Wanstead leigh.wanst...@gmail.com wrote: Hi Jolyon, You can select to use share runtime in release build too in xamarin. I don't use it. It is just like delphi build app. One exe contains everything. :-) Regards Leigh On 29 July 2015 at 11:31, Leigh Wanstead leigh.wanst...@gmail.com wrote: Hi Jolyon, In debug build, the xamarin app does not embed mono runtime engine. The runtime engine installed as a separate apk. I guess that is what you want. Google can select .net to replace java dalvik. This way no need to embed mono in each app. But they don't. That is the war between oracle now by using java interface api. https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google,_Inc. Regards Leigh On 29 July 2015 at 11:08, Jolyon Smith jsm...@deltics.co.nz wrote: Yes Leigh - the mono runtime that Xamarin relies on supports it at the technology level, but the OS X platform is not available at the INDIE tier of Xamarin subscription. And the idea of a platform levelling runtime required to be embedded within each application is specifically why I think Xamarin and FireMonkey are fundamentally flawed. You don't build Android and iOS apps with Delphi or Xamarin, you build FireMonkey and Xamarin apps that happen to run on Android and iOS. It's a subtle but (to me) important difference. Apart from anything else, it leaves you beholden to and often waiting for the tools vendor to provide and maintain support for developments in the platforms themselves. On 29 July 2015 at 10:01, Leigh Wanstead leigh.wanst...@gmail.com wrote: Hi Jolyon, I think that mono support OS X which you can write c# code to run on OS X. Regards Leigh On 29 July 2015 at 09:56, Jolyon Smith jsm...@deltics.co.nz wrote: Yes, there is no denying that it would be a hard sell to get elements introduced into an enterprise or even ISV setting. But for the enthusiast/hobbyist/independent ObjectPascal (in particular) developer it has much to offer against the likes of Delphi or even FPC (which ime is frustratingly lacking in the polish you may be used to from commercial dev tools and falls *far* short of the just works goal when it comes to mobile dev... I suppose if you enjoy spending more time getting your compiler to even work than you do developing apps, then it may appeal). Even if you are keen on (or willing to suffer C#) Elements has some advantages even compared to the comparably affordable version of Xamarin, not least being complete platform support (Indie Xamarin does not support OS X or System.SqlClient, for example). And using Elements I am at least also learning the platform SDK's, so if I ever am asked to do Android or iOS development properly, everything I am learning in the meantime can be applied directly (I am no stranger to Java / Eclipse or Objective-C / X Code, I just prefer ObjectPascal). On 29 July 2015 at 08:13, Jeremy Coulter jscoul...@gmail.com wrote: I guess for me, not ever seeing a role advertised that requires RemObjects experience, I would be confined to tinkering with the free version of the Silver tool. And given its not main-stream, it would be hard to get it into our development environment. Thats not saying it itsnt a good tool, just the commercial reality. However, like all of you, I am getting a little concerned about EMB. direction. For me personally, having to re-install my controls every six months or so is just not economic. Instead of releasing new versions ever 6 months or so, do one a year with six month updates that doesnt require me to re-install all my controls. Jeremy On Wed, Jul 29, 2015 at 8:03 AM, Jolyon Smith jsm...@deltics.co.nz wrote: RemObjects # of users - sorry, I
Re: [DUG] EMBARCADERO MY GRIPE
What a fabulous attitude. It's thanks to that sort of thinking that we now need machines with quad core 2.5GHz processors and 8GB of RAM just to run frikkin MS Word. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] EMBARCADERO MY GRIPE
Yes Leigh - the mono runtime that Xamarin relies on supports it at the technology level, but the OS X platform is not available at the INDIE tier of Xamarin subscription. And the idea of a platform levelling runtime required to be embedded within each application is specifically why I think Xamarin and FireMonkey are fundamentally flawed. You don't build Android and iOS apps with Delphi or Xamarin, you build FireMonkey and Xamarin apps that happen to run on Android and iOS. It's a subtle but (to me) important difference. Apart from anything else, it leaves you beholden to and often waiting for the tools vendor to provide and maintain support for developments in the platforms themselves. On 29 July 2015 at 10:01, Leigh Wanstead leigh.wanst...@gmail.com wrote: Hi Jolyon, I think that mono support OS X which you can write c# code to run on OS X. Regards Leigh On 29 July 2015 at 09:56, Jolyon Smith jsm...@deltics.co.nz wrote: Yes, there is no denying that it would be a hard sell to get elements introduced into an enterprise or even ISV setting. But for the enthusiast/hobbyist/independent ObjectPascal (in particular) developer it has much to offer against the likes of Delphi or even FPC (which ime is frustratingly lacking in the polish you may be used to from commercial dev tools and falls *far* short of the just works goal when it comes to mobile dev... I suppose if you enjoy spending more time getting your compiler to even work than you do developing apps, then it may appeal). Even if you are keen on (or willing to suffer C#) Elements has some advantages even compared to the comparably affordable version of Xamarin, not least being complete platform support (Indie Xamarin does not support OS X or System.SqlClient, for example). And using Elements I am at least also learning the platform SDK's, so if I ever am asked to do Android or iOS development properly, everything I am learning in the meantime can be applied directly (I am no stranger to Java / Eclipse or Objective-C / X Code, I just prefer ObjectPascal). On 29 July 2015 at 08:13, Jeremy Coulter jscoul...@gmail.com wrote: I guess for me, not ever seeing a role advertised that requires RemObjects experience, I would be confined to tinkering with the free version of the Silver tool. And given its not main-stream, it would be hard to get it into our development environment. Thats not saying it itsnt a good tool, just the commercial reality. However, like all of you, I am getting a little concerned about EMB. direction. For me personally, having to re-install my controls every six months or so is just not economic. Instead of releasing new versions ever 6 months or so, do one a year with six month updates that doesnt require me to re-install all my controls. Jeremy On Wed, Jul 29, 2015 at 8:03 AM, Jolyon Smith jsm...@deltics.co.nz wrote: RemObjects # of users - sorry, I have no idea. Community support - there are two prongs to this... First, the RemObjects forums are quite active with contributions both from users and RemObjects staff thmselves. To give an example of the type of support you get, on one occasion during my early days with the product I encountered a problem using a particular aspect of the Android SDK which was traced to an esoteric bug in the compiler. This was identified in a few days and by the end of that week a build had been provided to me personally to test, before the fix was incorporated in a subsequent beta and later release build. As a subscriber you have access to the current and previous releases and betas and you also have a private downloads area where specific builds may be provided to you. Betas are updated on a more or less monthly basis with full releases usually coming quarterly, along with regular updates on the development plans (a roadmap if you like via the blog, as well as formal updates to those plans with each release (they tell you what the new release delivers and what they are working on next). http://blogs.remobjects.com/blogs/mh/2015/07/16/p7096 I should add that I am enjopying only *BASIC* support. Premium support is a cost-extra option, should you feel the need for it. Second, Community Support is also on offer from beyond the strictly delineated boundary of RemObjects Users itself. by virtue of the fact that you are developing directly against the platform SDK's. I have learned all my Android and iOS development from the Java and Objective-C examples online and by perusing questions and answers on Stack Overflow couched in terms of those platform native languages and API's. Applying that knowledge to RemObjects elements is a trivial exercise in syntax conversion. On the point of Java and one language everywhere something to bear in mind here is that when you compile RemObjects Elements code - whether ObjectPascal (Oxygene), C# or Swift - for Android, what the compiler emits is Java byte-code
Re: [DUG] EMBARCADERO MY GRIPE
RemObjects # of users - sorry, I have no idea. Community support - there are two prongs to this... First, the RemObjects forums are quite active with contributions both from users and RemObjects staff thmselves. To give an example of the type of support you get, on one occasion during my early days with the product I encountered a problem using a particular aspect of the Android SDK which was traced to an esoteric bug in the compiler. This was identified in a few days and by the end of that week a build had been provided to me personally to test, before the fix was incorporated in a subsequent beta and later release build. As a subscriber you have access to the current and previous releases and betas and you also have a private downloads area where specific builds may be provided to you. Betas are updated on a more or less monthly basis with full releases usually coming quarterly, along with regular updates on the development plans (a roadmap if you like via the blog, as well as formal updates to those plans with each release (they tell you what the new release delivers and what they are working on next). http://blogs.remobjects.com/blogs/mh/2015/07/16/p7096 I should add that I am enjopying only *BASIC* support. Premium support is a cost-extra option, should you feel the need for it. Second, Community Support is also on offer from beyond the strictly delineated boundary of RemObjects Users itself. by virtue of the fact that you are developing directly against the platform SDK's. I have learned all my Android and iOS development from the Java and Objective-C examples online and by perusing questions and answers on Stack Overflow couched in terms of those platform native languages and API's. Applying that knowledge to RemObjects elements is a trivial exercise in syntax conversion. On the point of Java and one language everywhere something to bear in mind here is that when you compile RemObjects Elements code - whether ObjectPascal (Oxygene), C# or Swift - for Android, what the compiler emits is Java byte-code. It is indistinguishable from the output of a Java compiler! The front end language syntax may be different, but the output is essentially Java. This applies equally to consuming other Java code. Classes etc from Java are simply consumed directly in your code by adding the relevant JAR to your project references. So in a way, RemObjects Elements is an active participant in that Java everywhere phenomenon - when compiling for a Java platform. In the Oxygene compiler they have cleaned up the syntax of some of the aspects of Java, whilst retaining this compatibility. For example. Java has no formal specification for the concept of a property. But you can still declare properties in Oxygene for Java - the compiler emits corresponding getXXX and setXXX methods as you would expect (even if you have not explicitly declared these accessor methods). Equally, if you consume a Java class (e.g. from the Android SDK) which implements get/set methods, then these can be accessed as if they were properties: Java methods:v = o.getName(); / o.setName(v); Oxygene:v := o.Name; / o.Name := v Similarly if provide your class implementing a read/write Name property to a Java developer (in a jar file) then they will see a class with getName and setName methods, just as they would normally expect. Equally when compiling for .net then Elements is an active participant in that ecosystem/platform. And ditto w.r.t iOS / OS X when compiling for those platforms. As I think I said, impressive and innovative technology. :) On 29 July 2015 at 00:25, John Bird johnkb...@paradise.net.nz wrote: I don’t know RemObjects C# or Oxygene. I read the site and their viewpoint on using native API’s is a worthwhile debate.I would have these queries: 1 – Where does it rate on the number of users? Community support, code snippets etc is as important as everything else. 2 – It is the opposite of “one language fits everywhere” yet the language currently scoring top on the Tiobe index of programming languages does just that – Java. http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html I noticed Delphi is up another few places, to 13. Pascal is rated separately too at 20. On the comments about the IDE, at work have used D5 , D2007, XE2 XE5 XE7 XE8 and each version was a definite improvement. *From:* Jolyon Smith jsm...@deltics.co.nz *Sent:* Tuesday, July 28, 2015 5:03 PM *To:* NZ Borland Developers Group - Delphi List delphi@listserver.123.net.nz *Subject:* Re: [DUG] EMBARCADERO MY GRIPE I'll say it one more time... RemObjects manage to provide very good support for good quality products with extensive, impressive and innovative technology that does indeed just work (as in effortlessly, not barely LOL) at a very reasonable price. $49 Turbo Pascal it certainly isn't, but lined up against the likes of Delphi and Xamarin and particularly
Re: [DUG] EMBARCADERO MY GRIPE
Yes, there is no denying that it would be a hard sell to get elements introduced into an enterprise or even ISV setting. But for the enthusiast/hobbyist/independent ObjectPascal (in particular) developer it has much to offer against the likes of Delphi or even FPC (which ime is frustratingly lacking in the polish you may be used to from commercial dev tools and falls *far* short of the just works goal when it comes to mobile dev... I suppose if you enjoy spending more time getting your compiler to even work than you do developing apps, then it may appeal). Even if you are keen on (or willing to suffer C#) Elements has some advantages even compared to the comparably affordable version of Xamarin, not least being complete platform support (Indie Xamarin does not support OS X or System.SqlClient, for example). And using Elements I am at least also learning the platform SDK's, so if I ever am asked to do Android or iOS development properly, everything I am learning in the meantime can be applied directly (I am no stranger to Java / Eclipse or Objective-C / X Code, I just prefer ObjectPascal). On 29 July 2015 at 08:13, Jeremy Coulter jscoul...@gmail.com wrote: I guess for me, not ever seeing a role advertised that requires RemObjects experience, I would be confined to tinkering with the free version of the Silver tool. And given its not main-stream, it would be hard to get it into our development environment. Thats not saying it itsnt a good tool, just the commercial reality. However, like all of you, I am getting a little concerned about EMB. direction. For me personally, having to re-install my controls every six months or so is just not economic. Instead of releasing new versions ever 6 months or so, do one a year with six month updates that doesnt require me to re-install all my controls. Jeremy On Wed, Jul 29, 2015 at 8:03 AM, Jolyon Smith jsm...@deltics.co.nz wrote: RemObjects # of users - sorry, I have no idea. Community support - there are two prongs to this... First, the RemObjects forums are quite active with contributions both from users and RemObjects staff thmselves. To give an example of the type of support you get, on one occasion during my early days with the product I encountered a problem using a particular aspect of the Android SDK which was traced to an esoteric bug in the compiler. This was identified in a few days and by the end of that week a build had been provided to me personally to test, before the fix was incorporated in a subsequent beta and later release build. As a subscriber you have access to the current and previous releases and betas and you also have a private downloads area where specific builds may be provided to you. Betas are updated on a more or less monthly basis with full releases usually coming quarterly, along with regular updates on the development plans (a roadmap if you like via the blog, as well as formal updates to those plans with each release (they tell you what the new release delivers and what they are working on next). http://blogs.remobjects.com/blogs/mh/2015/07/16/p7096 I should add that I am enjopying only *BASIC* support. Premium support is a cost-extra option, should you feel the need for it. Second, Community Support is also on offer from beyond the strictly delineated boundary of RemObjects Users itself. by virtue of the fact that you are developing directly against the platform SDK's. I have learned all my Android and iOS development from the Java and Objective-C examples online and by perusing questions and answers on Stack Overflow couched in terms of those platform native languages and API's. Applying that knowledge to RemObjects elements is a trivial exercise in syntax conversion. On the point of Java and one language everywhere something to bear in mind here is that when you compile RemObjects Elements code - whether ObjectPascal (Oxygene), C# or Swift - for Android, what the compiler emits is Java byte-code. It is indistinguishable from the output of a Java compiler! The front end language syntax may be different, but the output is essentially Java. This applies equally to consuming other Java code. Classes etc from Java are simply consumed directly in your code by adding the relevant JAR to your project references. So in a way, RemObjects Elements is an active participant in that Java everywhere phenomenon - when compiling for a Java platform. In the Oxygene compiler they have cleaned up the syntax of some of the aspects of Java, whilst retaining this compatibility. For example. Java has no formal specification for the concept of a property. But you can still declare properties in Oxygene for Java - the compiler emits corresponding getXXX and setXXX methods as you would expect (even if you have not explicitly declared these accessor methods). Equally, if you consume a Java class (e.g. from the Android SDK) which implements get/set methods
Re: [DUG] EMBARCADERO MY GRIPE
For most of what you need to do, INDIE Xamarin is all you need which is cheaper compared to the usable equivalent Delphi (Professional + Mobile Add-On + 30% SA, assuming you don't need FireDAC, not forgetting to factor in that this is increased by 5%, compounded, annually, if they stick to their t's and c's and provide the required notice). Even stepping up, Xamarin Business is cheaper in terms of initial outlay than Delphi Enterprise, although the annual renewal is cheaper thereafter. With Delphi Architect/Ultimate the cost advantage takes 2 or more years to weigh back in favour of Delphi after your initial eye watering outlay. And if VisualStudio hosting is a factor (as it is for some people) then worth noting is that you can't buy this for Delphi no matter how much you are willing to spend. And of course, you have to put up with Embarcadero's notion of quality, which in recent years is closer to a synonym for bad joke. But if we're measuring bang per buck, RemObjects Elements is way ahead of both. Comparable in cost to INDIE Xamarin but also supporting .NET and OS X development (and even WinPhone should you be so inclined) as well as Android and iOS with the option of either Visual Studio or Fire IDE's (OS X) plus you get to choose to stick with ObjectPascal (a way more advanced version than even current Delphi) or C# or Swift or mix and match to suit. And the answer to Tony's questions w.r.t RemObjects Elements are Yes and Yes. :) On 28 July 2015 at 09:17, Jeremy Coulter jscoul...@gmail.com wrote: have you seen the PRICE for Xamarin?? Delphi is certainly cheaper! On Tue, Jul 28, 2015 at 8:54 AM, Tony Blomfield to...@precepthealth.com wrote: Can anyone advise how to access the upgrades that I should be entitled to ? The issue I have relates to my account. Having finally been talked into the supposed benefits of a maintenance contract I purchased same back in January. They pestered the hell out of me about payment. Apparently their system could not process a Master card. Finally we got that resolved somehow, but I never received an invoice, licensing or anything else. After much tooing and froing I finally got a license and duly installed XE7. Never have I seen an invoice. Actually I have never upped anything to Xe7 because its such a major event to upgrade large projects in Delphi, and clearly it was just another WIP. Finally yesterday I decided to try out XE8 after hearing from this group that its usable. I went to my account and there is no sign of any XE8 upgrade or maintenance. I called Embarcadero all day and got no answer. I sent two Emails and at 11PM last night got a very vague and unhelpful response I am fed up with Embarcadero and the lies an deceit and the high cost of ownership. We are 50% .NET and 50% Delphi. Unless I get some solution on this today I am going to direct the company to move to 100% .NET over the next 12 months and use Xamarin. *From:* delphi-boun...@listserver.123.net.nz [mailto: delphi-boun...@listserver.123.net.nz] *On Behalf Of *Jolyon Smith *Sent:* Tuesday, 28 July 2015 7:50 a.m. *To:* NZ Borland Developers Group - Delphi List *Subject:* Re: [DUG] EMBARCADERO I think perhaps it's a question of context. They were pretty slow in responding when I had to contact them regarding an increase in my SA renewal in contravention of their own terms and conditions (the required notice was not provided, they simply presented an invoice with an increased amount). They took their own sweet time to respond and when they did they simply referred me to the clause in the terms and conditions allowing them to increase the renewal by up to 5%. This even included the required notice period which they had completely ignored !!! Yet for some reason they LOVE sending me marketing emails, frequently and often duplicated, even though I have specifically unsubscribed from all their spam lists and opted out of ALL communications in my EDN accounts. It's almost as if the Unsolicited Electronic Messages Act (2007) does not exist (and yes I have directed their attention to this and their violation of it, repeatedly). And yes, they are covered by that act since they are an organisation that carries on business or activities in New Zealand. (8.2.b in the act). As for the SA renewal, I eventually got them to retract their invoice and re-submit at the previous rate, which I then took great pleasure in declining to renew. Good luck. On 27 July 2015 at 20:02, Tony Blomfield to...@precepthealth.com wrote: OK Il wait. Maybe I am being too touchy. Thanks a lot. *From:* delphi-boun...@listserver.123.net.nz [mailto: delphi-boun...@listserver.123.net.nz] *On Behalf Of *Jeremy Coulter *Sent:* Monday, 27 July 2015 7:00 p.m. *To:* NZ Borland Developers Group - Delphi List *Subject:* Re: [DUG] EMBARCADERO Its not a holiday in Australia? I too have always found them pretty responsive. Jeremy
Re: [DUG] EMBARCADERO MY GRIPE
I'll say it one more time... RemObjects manage to provide very good support for good quality products with extensive, impressive and innovative technology that does indeed just work (as in effortlessly, not barely LOL) at a very reasonable price. $49 Turbo Pascal it certainly isn't, but lined up against the likes of Delphi and Xamarin and particularly after adjusting for inflation (for comparison with the $49 TP) it isn't far off. Cheap(er) = lower quality is *not* a rule, and certainly not a Universal Constant. On 28 July 2015 at 15:13, Marshland Engineering marshl...@marshland.co.nz wrote: have you seen the PRICE for Xamarin?? Delphi is certainly cheaper! Cheaper is the operative word. Which is better cheaper and full of problems and no support or expensive and just works. I now prefer the latter. As for me, no more tablets, smart TVs or phones or any other tech device for a while. They are all cheap but I've spent so much time getting them to work correctly, it is ridicules. Samsung Smart TVs - Ha. I'm now taking my time saving to be in the real world. Cheers Wallace ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] [Off topic] mobile handheld printer support android
Is google not working for you ? ;) For more specific advice/suggestions then you need to be a bit more specific about your needs. Do you need a label printer (if so, what dimensions?) ? A document printer (A4 / other) ? Does durable mean ruggedised or just portable ? Specific standards, e.g. Ingress Protection (IPxx) ? On 16 July 2015 at 09:49, Leigh Wanstead leigh.wanst...@gmail.com wrote: Good morning, Does anyone know a good mobile handheld printer support android which can buy easily? The condition is 1 Not too dear i.e. less than nz$100 2 Give program instructions on how to call from android app to print 3 light for handheld, carry use for 8 hours 4 durable TIA Regards Leigh ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] Question about running an app. across a network
As David says, access the INI file on the client is a simple matter of
deciding on a safe, reliable location (i.e. follow Windows guidelines for
such configuration files). However for a configuration file I would
suggest the use of AppData folder, rather than Documents.
Use SHGetFolderPath() (from SHFolder unit) using CSIDL_APPDATA (per user
settings) or CSIDL_COMMON_APPDATA (shared/system wide). If you do decide
to use the user documents folder then use CSIDL_PERSONAL instead.
NOTE: This is for supporting Windows versions pre-dating Vista. If you
don't need to worry about that and can use Vista+ specific API's then you
should use the newer Known Folders API instead (
https://msdn.microsoft.com/en-us/library/windows/desktop/bb776911(v=vs.85).aspx
).
Something else to bear in mind with this sort of approach is that if your
user suffers even a micro-outage to the file server where the application
EXE is located, this can result in a C006 exception if/when Windows
tries to page the EXE during that outage. Your app is then unrecoverable
from that point and requires a restart which may not otherwise be necessary
once the outage is restored. The outages involved can be so brief that the
user is otherwise unaware but can be catastrophic for applications running
from net drives.
To avoid this you can mark the EXE with a PE header attribute that directs
Windows to load the entire EXE into the workstation swapfile at launch,
avoiding the need to load any further pages over the network. If you are
using Delphi 7 or later (NOT XE7, just plain old 7) you can achieve this by
adding a SETPEFLAGS directive to your application (typically in the DPR):
{$SETPEFLAGS IMAGE_FILE_NET_RUN_FROM_SWAP}
NOTE: You will need to add this AFTER the uses clause, and you will need
the Windows unit in that uses clause since this directive sets attributes
based on numeric values of constants and IMAGE_FILE_NET_RUN_FROM_SWAP is
defined in the Windows unit.
On 8 July 2015 at 21:58, Jeremy Coulter jscoul...@gmail.com wrote:
Hi All.
I have an app that I will be running from a server location. However, I
want the app. to read an ini file that is located in a folder on a client
machine.
A Shortcut to the app on the server and the ini file will live in a folder
on the client machine, but I cant work out how to get the app, when its run
via the shortcut, to read the ini file on the client machine.
Anyone know how to go about doing this?
I have thought about dropping the INI and transferring the settings to a
database with a row for each machine that connects, but before I get that
carried away, I just wanted to see if someone had any ideas to do the above
with the ini file.
The reason I want an ini for each computer is about settings. Not all
machines have the same settings etc.
Thanks, Jeremy
___
NZ Borland Developers Group - Delphi mailing list
Post: delphi@listserver.123.net.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with
Subject: unsubscribe
___
NZ Borland Developers Group - Delphi mailing list
Post: delphi@listserver.123.net.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with
Subject: unsubscribe
Re: [DUG] Question about running an app. across a network
Re updating EXE's, this is do-able even without that flag.
The trick there is that the file system won't allow you to delete a file
that is in use, but it will allow you to *rename* it. So:
- Rename current file APP.EXE - APP.EXE.OLD
- Place new APP.EXE in location
- Delete APP.EXE.OLD
When you delete a file in use the file isn't actually deleted but is only
marked for deletion once all current handles are closed. Renaming the file
is OK since anyone still running the old copy is unaffected (their file
handle is attached to the *file itself*, not the file *name*) until they
quit the app and restart, at which point they seamlessly pick up the new
version.
You've already worked around the problem with that PE flag for EXE's on a
network, but this same technique can be useful in locally installed
applications e.g. auto-updating app EXE's.
On 9 July 2015 at 08:32, Jeremy Coulter jscoul...@gmail.com wrote:
Thanks Joylon. Yip already have that flag set.It also enables the Exe on
the server to be updated without having to get users to close down their
versions running on client machines.
I think the APPData (common) will be a better location given I expect
there may be multiple users on some machines.
I'll give that a poke and see howit works. Shouldnt be hard to replace the
instances of (ExtractFilepath(Paramstr(0))) with a variable to APPData
Common :-)
Thanks, guys.
On Thu, Jul 9, 2015 at 7:59 AM, Jolyon Smith jsm...@deltics.co.nz wrote:
As David says, access the INI file on the client is a simple matter of
deciding on a safe, reliable location (i.e. follow Windows guidelines for
such configuration files). However for a configuration file I would
suggest the use of AppData folder, rather than Documents.
Use SHGetFolderPath() (from SHFolder unit) using CSIDL_APPDATA (per user
settings) or CSIDL_COMMON_APPDATA (shared/system wide). If you do decide
to use the user documents folder then use CSIDL_PERSONAL instead.
NOTE: This is for supporting Windows versions pre-dating Vista. If you
don't need to worry about that and can use Vista+ specific API's then you
should use the newer Known Folders API instead (
https://msdn.microsoft.com/en-us/library/windows/desktop/bb776911(v=vs.85).aspx
).
Something else to bear in mind with this sort of approach is that if your
user suffers even a micro-outage to the file server where the application
EXE is located, this can result in a C006 exception if/when Windows
tries to page the EXE during that outage. Your app is then unrecoverable
from that point and requires a restart which may not otherwise be necessary
once the outage is restored. The outages involved can be so brief that the
user is otherwise unaware but can be catastrophic for applications running
from net drives.
To avoid this you can mark the EXE with a PE header attribute that
directs Windows to load the entire EXE into the workstation swapfile at
launch, avoiding the need to load any further pages over the network. If
you are using Delphi 7 or later (NOT XE7, just plain old 7) you can achieve
this by adding a SETPEFLAGS directive to your application (typically in the
DPR):
{$SETPEFLAGS IMAGE_FILE_NET_RUN_FROM_SWAP}
NOTE: You will need to add this AFTER the uses clause, and you will need
the Windows unit in that uses clause since this directive sets attributes
based on numeric values of constants and IMAGE_FILE_NET_RUN_FROM_SWAP is
defined in the Windows unit.
On 8 July 2015 at 21:58, Jeremy Coulter jscoul...@gmail.com wrote:
Hi All.
I have an app that I will be running from a server location. However, I
want the app. to read an ini file that is located in a folder on a client
machine.
A Shortcut to the app on the server and the ini file will live in a
folder on the client machine, but I cant work out how to get the app, when
its run via the shortcut, to read the ini file on the client machine.
Anyone know how to go about doing this?
I have thought about dropping the INI and transferring the settings to a
database with a row for each machine that connects, but before I get that
carried away, I just wanted to see if someone had any ideas to do the above
with the ini file.
The reason I want an ini for each computer is about settings. Not all
machines have the same settings etc.
Thanks, Jeremy
___
NZ Borland Developers Group - Delphi mailing list
Post: delphi@listserver.123.net.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with
Subject: unsubscribe
___
NZ Borland Developers Group - Delphi mailing list
Post: delphi@listserver.123.net.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with
Subject: unsubscribe
___
NZ Borland
Re: [DUG] Question about running an app. across a network
What data is in the INI ? How much data ? What type of data ? How is it used ? How would machines be identified in a database solution ? By name or network ID ? If by name, what happens if a machine name is changed ? Database or file are simply different technologies that could be used in an implementation. But technology alone rarely identifies the right (or best) way. Anyone that says otherwise is selling something. ;) imho On 9 July 2015 at 08:59, Leigh Wanstead leigh.wanst...@gmail.com wrote: Hi Jeremy, I think that your idea about dropping the INI and transferring the settings to a database with a row for each machine that connects is the correct way to do that. Regards Leigh On 8 July 2015 at 21:58, Jeremy Coulter jscoul...@gmail.com wrote: Hi All. I have an app that I will be running from a server location. However, I want the app. to read an ini file that is located in a folder on a client machine. A Shortcut to the app on the server and the ini file will live in a folder on the client machine, but I cant work out how to get the app, when its run via the shortcut, to read the ini file on the client machine. Anyone know how to go about doing this? I have thought about dropping the INI and transferring the settings to a database with a row for each machine that connects, but before I get that carried away, I just wanted to see if someone had any ideas to do the above with the ini file. The reason I want an ini for each computer is about settings. Not all machines have the same settings etc. Thanks, Jeremy ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] Question about running an app. across a network
Bottom line: No ONE mechanism is appropriate (let alone best) for ALL data. Machine specific information is best maintained *on the machine*. Otherwise you have the problem of identifying the machine in the database (or whatever shared location you employ) and there are very few characteristics with which to *reliably* identify a machine that are not subject to and vulnerable to change, however rarely or infrequently you might think that is likely to occur. ime it is the things that happen infrequently that are the *last* thing to be considered when a problem occurs and an explanation is being sought... Why has the system lost my settings ? Also, some information can be indirectly machine specific. e.g. Last window position/size might be thought of as a user preference/session datum, but if a user uses different machines and some machines have multiple monitors while others do not, or different resolution displays (or changes display configuration on the one machine they use), then this can easily lead to situations where a user finds that their windows are opening in inaccessible/inappropriate positions. Machine specific settings : COMMON_APPDATA Machine + User specific settings : APP_DATA Machine independent session/user settings : DB / File server / etc What you absolutely should do of course is implement a Configuration Manager class or framework, which removes the details of which setting is stored where from your application code and indeed allow you to *change* these details without requiring changes in the application, should you ever need to. +0.02 On 9 July 2015 at 10:55, Tony Blomfield to...@precepthealth.com wrote: My opinion is. 1. Config file should only hold definitions that are mandatory for app start up. EG end point connectivity definition. 2. All other configurations are best placed in a DB structure. Here you have central management, security, convenience, and it’s easy to make a nice Gui management tool. 3. As others suggested, store your config using the Win API. You will find it a very agreeable way. *From:* delphi-boun...@listserver.123.net.nz [mailto: delphi-boun...@listserver.123.net.nz] *On Behalf Of *Leigh Wanstead *Sent:* Thursday, 9 July 2015 9:56 a.m. *To:* NZ Borland Developers Group - Delphi List *Subject:* Re: [DUG] Question about running an app. across a network Hi Jeremy, In the end, it is your baby :-) Regards Leigh On 9 July 2015 at 09:22, Jeremy Coulter jscoul...@gmail.com wrote: a mere 20 years Leighso your still a newbie then :-) You are correct, but in this case whilst its not the best solution, it will suffice for now and will only require a function to find the correct folder location and then do a copy and replace as apposed to a rather larger potentially code-breaking changes. But I will definitely be changing the way it works.Its a matter of time- as always Jeremy On Thu, Jul 9, 2015 at 9:13 AM, Leigh Wanstead leigh.wanst...@gmail.com wrote: Hi Jeremy, You might be spend time to wondering what is going wrong if you deploy the easiest solution to your customer. From my 20 years experience, the easiest solution might require lots of more time and energy than better way. Just my 2 cents Regards Leigh On 9 July 2015 at 09:09, Jeremy Coulter jscoul...@gmail.com wrote: I too think it might be the better way too Leigh, but the above ideas are the easiest to implement now and I can spend the time later to add it to the database. Jeremy On Thu, Jul 9, 2015 at 8:59 AM, Leigh Wanstead leigh.wanst...@gmail.com wrote: Hi Jeremy, I think that your idea about dropping the INI and transferring the settings to a database with a row for each machine that connects is the correct way to do that. Regards Leigh On 8 July 2015 at 21:58, Jeremy Coulter jscoul...@gmail.com wrote: Hi All. I have an app that I will be running from a server location. However, I want the app. to read an ini file that is located in a folder on a client machine. A Shortcut to the app on the server and the ini file will live in a folder on the client machine, but I cant work out how to get the app, when its run via the shortcut, to read the ini file on the client machine. Anyone know how to go about doing this? I have thought about dropping the INI and transferring the settings to a database with a row for each machine that connects, but before I get that carried away, I just wanted to see if someone had any ideas to do the above with the ini file. The reason I want an ini for each computer is about settings. Not all machines have the same settings etc. Thanks, Jeremy ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email
Re: [DUG] dxGetTex and Report Builder.
I am curious ... is this an old project that you are working on ? Is it possible that the form has the OldCreateOrder property set TRUE for some reason ? This would have a potentially significant impact on the timing of the FormCreate event which might explain problems with code trying to process controls/components on the form at that point. This might also explain why you don't get the problem with an otherwise identical, freshly created form (where OldCreateOrder will be FALSE by default). On 30 June 2015 at 10:05, Willie wil...@compliant.co.nz wrote: An update, I started from an empty form and copied over components/code snippets from the original unit to see at which point the AV error was introduced, I managed to get the new unit completely built and operating without the AV error being re-introduced (with no obvious differences between the old and new version)…. M I would like to know what was actually wrong but it’ll just have to go in the unsolved mysteries box (it’s actually a warehouse) for now. So your stuff did fix the issue David, thanks very much for that. Cheers *From:* delphi-boun...@listserver.123.net.nz [mailto: delphi-boun...@listserver.123.net.nz] *On Behalf Of *David Brennan *Sent:* Monday, 29 June 2015 2:44 p.m. *To:* 'NZ Borland Developers Group - Delphi List' *Subject:* Re: [DUG] dxGetTex and Report Builder. Hi Willie, Strange. Many of our reports have sub reports and child reports too but we might be using them differently, or perhaps there is some other control you are using which we don’t. I don’t have any other suggestions I’m afraid and the fact that adding those ignores has fixed some AVs suggests you are on the right track. Cheers, David. *From:* delphi-boun...@listserver.123.net.nz [ mailto:delphi-boun...@listserver.123.net.nz delphi-boun...@listserver.123.net.nz] *On Behalf Of *Willie *Sent:* Monday, 29 June 2015 2:25 p.m. *To:* 'NZ Borland Developers Group - Delphi List' *Subject:* Re: [DUG] dxGetTex and Report Builder. Thanks heaps for that David, I’ve added your ignore list (I already had TppDBText,’DataField’ and TppDBRichText,’DataField’ to get it to display stuff properly in the report) but I’m still getting the AV. I have two reports (separate forms) in the project and one has the AV issue but the other doesn’t (if I exclude all of the ReportBuilder ignores then they both AV). The one that AV’s has a TppSubReport and TppChildReport (which the other one doesn’t) so I’m guessing it’s to do with those classes but can’t work out which properties of these to ignore exactly. I’ve tried DataPipelineName and DataPipeline but it must be something else… keep trying combinations…. *From:* delphi-boun...@listserver.123.net.nz [ mailto:delphi-boun...@listserver.123.net.nz delphi-boun...@listserver.123.net.nz] *On Behalf Of *David Brennan *Sent:* Monday, 29 June 2015 10:42 a.m. *To:* 'NZ Borland Developers Group - Delphi List' *Subject:* Re: [DUG] dxGetTex and Report Builder. Hi Willie, We use GnuGetText and ReportBuilder 14.08 in Delphi 2007/XE3/XE7. Our reports are now datamodule descendants instead of forms but that is a fairly recent change and it worked fine prior to that. So in datamodule/formcreate we have: gnugettext.TranslateComponent(Self); And our GnuGetText initialisation for ReportBuilder is: //Report Builder TP_GlobalIgnoreClassProperty(TppField,'FieldName'); TP_GlobalIgnoreClassProperty(TppField,'FieldAlias'); TP_GlobalIgnoreClassProperty(TppPrintable,'DataField'); TP_GlobalIgnoreClassProperty(TppPrintable,'DataPipelineName'); TP_GlobalIgnoreClassProperty(TppPrintable,'UserName'); TP_GlobalIgnoreClassProperty(TppReport,'ArchiveFileName'); TP_GlobalIgnoreClassProperty(TppReport,'TextFileName'); TP_GlobalIgnoreClassProperty(TppCustomReport,'DataPipelineName'); TP_GlobalIgnoreClassProperty(TppCommunicator,'UserName'); TP_GlobalIgnoreClassProperty(TppGroup,'UserName'); TP_GlobalIgnoreClassProperty(TppGroup,'BreakName'); TP_GlobalIgnoreClassProperty(TppCustomText,'Username'); TP_GlobalIgnoreClassProperty(TppMasterFieldLink,'MasterFieldName'); TP_GlobalIgnoreClassProperty(TppMasterFieldLink,'DetailFieldName'); TP_GlobalIgnoreClassProperty(TppRichText,'RichText'); I don’t guarantee this is correct – for example arguably UserName should be translated but we don’t currently use the user designer so we don’t care what the display names of components are. I can guarantee that we don’t get any AVs using 14.08 though. I don’t think we’ve tried ReportBuilder 15, we did try 16 briefly but we haven’t upgraded to it and its just possible we didn’t play with it enough to notice AVs. Cheers, David. *From:* delphi-boun...@listserver.123.net.nz [ mailto:delphi-boun...@listserver.123.net.nz
Re: [DUG] RE Relationship or not
things happen behind the scenes which can be hard to find In my experience this holds true for *any* component based, drag-and-drop development approach. DevArt components are no different in this respect than any other framework. That, and the fact that program behaviours are driven, sometimes subtly and sometimes significantly, by minor variations in component properties that are immeasurably more difficult to discover than changes resulting from difference in actual code, is why I avoid using such frameworks for application development like the proverbial. You can create an app that works (or seems to) very quickly. But when problems arise or you need to change or extend the behaviour or implement something which doesn't fit with the way that the components you are using expect or intend you to, the effort involved (and unintended side effects arising) then can be disastrously disproportionate. imho ymmv On 25 June 2015 at 22:41, Marshland Engineering marshl...@marshland.co.nz wrote: Hi chaps and update. Barry, Eric and Alistair all came to the rescue and I learned something from each one. Thanks very much. I'm using Devart for Mysql access. So what I have learned is, that, if you have a Master Detail relationship and you do a post with the Master table, the Detail table changes from edit to browse mode all by itself. Along the same lines if you have a Master Detail relationship and look to see if there is a Detail entry for a Master record and there isn't one, when you put the master into edit mode, it automatically creates one for you (or a virtual one) in the detail form so any conditional statement with the Detail table now returns true. So with Devarts components- things happen behind the scenes which can be hard to find. Thanks Wallace ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] XE8 with Castalia and MMX
I have seen numerous reports indicating that the integration of Castalia in XE8 has (re)introduced stability issues in the IDE. I cannot fathom why it would present a problem on some machines but not others, unless there are differences between the machines that might explain the problems (lack of memory in some case ? 32 vs 64 bit OS ? Particular installation differences somehow throwing a spanner in the works ? Too many possible variables to be able to say I think). I have to say that when I last looked at Castalia myself I reluctantly had to discontinue its use precisely because it made the IDE unstable, hopelessly so when working in larger projects. This was some years ago now and no doubt this area had been improved but if the reports are to be believed it seems that a lot of that good work was undone between XE7 and XE8. There also appear to have been a number of regressions introduced into FMX with XE8. Until Embarcadero manage to deliver a usable version of XE8 you should probably either simply stick with XE7 or whichever previous version you were using, or run with Castalia disabled where it is known/suspected to be causing problems. Depending on how the integration has been approached, this may or may not deal with the issues caused by that integration. I would also add that the fact that this option to disable Castalia was provided has a very nasty whiff about it. Almost as if they knew it wasn't ready for release which frankly I find offensive, given the way they made hotfix/update availability contingent upon a maintenance agreement with this release. +0.02 On 4 June 2015 at 13:14, John Bird johnkb...@paradise.net.nz wrote: XE8 comes with Castalia built in, here 2 of the users have both working, 2 others can have either Castalia or ModelMaker MMX (11.2.0) installed but not both. Castalia can be disabled with /NOCASTALIA on the command line switch. Error we get is on IDE startup “Access violation at address 20441561 in module ‘coreide220.bpl’. Read of address 003D.” Dies at that point. (We are already installing everything as Administrator, and running the IDE as same.) Can anyone shed any light on the problem or know of any solution? ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] Delphi Digest, Vol 139, Issue 15
Based on this your declaration of the API function appears to be incorrect: Documentation: int API_PCDRead(HANDLE commHandle, int:DeviceAddress, unsigned char: mode, unsigned char: blk_add, unsigned char: num_blk, unsigned char: *snr, unsigned char: *buffer); Your declaration: function API_PCDRead(comHandle: Thandle; DeviceAddress: integer; mode: byte; add_blk,num_blk:integer; snr,buffer:pchar): integer; Your *add_blk* and *num_blk* parameters are declared of type *Integer* (4 bytes) when the function is expecting parameters of type *unsigned char* (1 byte). This explains your access violation (the result of the way that memory used for passing parameters is handled when using 'C' calling conventions, if the caller of a function, and the function itself, do not agree on the exact sizes of the parameters being passed). Change your function declaration to: *function API_PCDRead(comHandle: THandle;* * DeviceAddress: integer; * * mode:byte;* * add_blk,num_blk: byte; snr,buffer: pchar): integer;* I would also double check the type declaration for the *Handle* parameter, just to be certain that the HANDLE type expected by the API function does in fact correspond to what appears to be the Windows API specific *THandle* type that you have declared it as. This will almost certainly solve your access violation. Based on the documentation it appears that the way that you are handling the result following the call is correct (though I haven't examined it exhaustively). You will do yourself an enormous favour by simplifying and tidying this up as well as the initialization part. Apart from anything else, it will greatly help someone maintaining the code in the future if the variables used in the calling code correspond to the parameters documented for the API. e.g. if you are passing a buffer in a parameter called *snr* then name your variable *snr*, or *snrParam*, and only access it that way. Don't use a variable and a pointer that happens to point to that variable (via a side-effect!) or if you absolutely must then at least ensure that the names involved make this usage clear, e.g. *snr* and *ptr**snr*. Finally, the documentation also says that upon calling the function, the *snr* buffer is expected to hold an *8 byte* key value which you are only initialising with 7 bytes (6 x $FF and a $00) so I would double check that this initialization of the *snr* buffer in your code is correct. Hope this helps. On 28 May 2015 at 18:27, Marshland Engineering marshl...@marshland.co.nz wrote: This is running with a USB cable and Windows XP. It installs as a HID device. 4.2Mifare Appilication Commands 4.2.1 int API_PCDRead(HANDLEcommHandle,int:DeviceAddress,unsignedchar:mode,unsigned char:blk_add,unsigned char:num_blk,unsigned char:*snr, unsigned char:*buffer); Description: read the appointed length date at the appointed station Input Parameter Description commHandle the serial port handle DeviceAddress equipment address moderead mode ( Request Idle + Key Amode=00 , Request Idle + Key B mode= 02, Request All + Key Amode=01 , Request All + Key B mode=03 the up number is hex） blk_add read block address num_blk read block amount *snra finger, transfer eight byte secret key *buffer wait receive the variable of output finger Output Parameter If Command success *snr4 byte card number *buffer the read date (the fact number is num_blk*16) If Command Failure buffer[0] System Error/Status Codes(You can consult the 2.2) Return value: 0x00Command OK. ( success) 0x01Command FAILURE The full manual is here http://www.marshland.co.nz/ftp/Misc/DLL.doc Thanks Wallace. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] RFID - EAccess violation
The debugger should be breaking (as in break-point) on the line causing the
AV. Tell us where that is and we may be able to help.
I would also suggest that you greatly simplify the code you are using to
work with the buffers being passed to and received from the API. The more
steps you introduce to achieve something, the greater chance that one of
those steps will introduce an inadvertent error (and make it harder to
identify where that error is creeping in.
For example, if the API requires a pointer to a null terminated key value
of 6 $FF bytes then simply declare a constant and pass the address of that,
rather than building a string. Apart from anything else, depending on
which version of Delphi you are using, your technique of using an
intermediate String may yield a PANSIChar (char = byte-size) or PWIDEChar
(char = word-size) and one of these is almost certainly not what the API
you are using is expecting.
And note that even if this technique works in a version of Delphi where
String = ANSI, it will likely break when you upgrade and recompile in a
version where String = UTF16.
Using a constant you not only eliminate a whole chunk of unnecessary code
but can be entirely explicit in what you are trying to achieve, so for a
byte buffer:
const
KEY = array[0..6] of Byte = ($FF,$FF,$FF,$FF,$FF,$FF,$00);
receive:=API_PCDRead(0,0,$00,10,1,@KEY,bufferr);
This might even be the cause of your problem.
On 28 May 2015 at 00:14, Robo robo...@gmail.com wrote:
Are you able to debug which line of code the error is occuring on?
On Wed, May 27, 2015 at 1:56 PM, Marshland Engineering
marshl...@marshland.co.nz wrote:
I'm a bit out my depth. Is there something I have missed ?
EAccess violation at address 0
I purchased an RFID reader with sample code. I stripped out what was not
necessary and ended up with this.
Sorry for the long code
**
unit Unit1;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Controls, Forms,
ComCtrls, StdCtrls, XPMenu, ExtCtrls;
type
TForm1 = class(TForm)
showm: TRichEdit;
Button1: TButton;
procedure falsereason(s:string);
procedure bReadClick(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
function
API_PCDRead(comHandle:Thandle;DeviceAddress:integer;mode:byte;add_blk,num_blk:integer;
snr,buffer:pchar):integer;stdcall;external 'mi.dll';
var
Form1: TForm1;
comhandle : Thandle ;
reason:string;
implementation
{$R *.dfm}
procedure TForm1.falsereason(s:string);
begin
if s='' then begin reason:=''; exit; end;
if s='00' then begin reason:=''; exit ; end;
etc
if s='96' then begin reason:='The Operation Do Not Success';
exit;
end;
end;
procedure TForm1.bReadClick(Sender: TObject);
var
buffer,bufferr:array [0..255] of char;
receive,i :integer;
keydata,cardnum,showmemo:string;
key : pchar;
begin
setlength(keydata,6);
for i:=1 to 6 do begin
keydata[i]:=Chr(StrToInt('$FF'));
end;
key:=StrPCopy(buffer,keydata);
receive:=API_PCDRead(0,0,$00,10,1,key,bufferr);
case receive of
0:begin
for i:=0 to 3 do begin
cardnum:=cardnum+ inttohex(ord(buffer[i]),2);
end;
showm.Lines.Add('Number :'+cardnum);
end;
1:begin
falsereason(inttohex(ord(bufferr[0]),2));
showm.Lines.Add(reason+#13#10);
end
else
showm.Lines.Add('error,no data receive...'+#13#10);
end;
end;
end.
I added the above to my code and it complies but crashes when I do a
receive.
EAccess
unit uMain;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls,
Forms,
Dialogs, Grids, DBGrids, Menus, ComCtrls, StdCtrls, Printers, DBCtrls,
Mask, ExtCtrls, IniFiles, DB, ShellAPI, XPMenu;
type
TfMain = class(TForm)
pcMembers: TPageControl;
Members: TTabSheet;
Events: TTabSheet;
DBGrid1: TDBGrid;
DBGrid4: TDBGrid;
DBGrid5: TDBGrid;
Label3: TLabel;
bFees: TButton;
Button1: TButton;
bEmail: TButton;
dbgMembers: TDBGrid;
Label5: TLabel;
Label7: TLabel;
dbgFeesMem: TDBGrid;
dbgSubs: TDBGrid;
Label4: TLabel;
Label2: TLabel;
puSubs: TPopupMenu;
puSubsAdd: TMenuItem;
puSubsDel: TMenuItem;
puFeesListPrinter: TMenuItem;
puFeesListScreen: TMenuItem;
upFeesCardsNotSent: TMenuItem;
PrintSet1: TPrinterSetupDialog;
puEventFees: TPopupMenu;
puFeesAdd: TMenuItem;
puFeesDelete: TMenuItem;
puFeesList: TMenuItem;
puMembers: TPopupMenu;
puAddMember: TMenuItem;
puDeleteMember: TMenuItem;
puBikes: TPopupMenu;
puAddBike: TMenuItem;
puDeleteBike: TMenuItem;
dbmNotes: TDBMemo;
Label6:
Re: [DUG] RFID - EAccess violation
Sorry, a typo in that. As a typed constant it should have read: const KEY : array[0..6] of Byte = ($FF,$FF,$FF,$FF,$FF,$FF,$00); Note the first '=' is now a ':' On 28 May 2015 at 11:33, Marshland Engineering marshl...@marshland.co.nz wrote: Thanks for the replies. this is the line receive:=API_PCDRead(0,0,$00,10,1,key,bufferr); I'm way out my depth with the workings of this function. I just do simple coding - A ex dBase3 programmer. I took the sample code that the RFID supplier gave, stripped off everything I didn't need other than the read line for RFID card and then copied the bits into my program which now crashes. I was wondering if the XPMENU call or something like that is interfering with other modules ? My debugging is limited to finding the line with the error. Both programs are run in Delphi 6, same machine and same environment. I can't find how to code this, where ever I put it, it crashes. - Expected expression but ARRAY found. const KEY = array[0..6] of Byte = ($FF,$FF,$FF,$FF,$FF,$FF,$00); Thanks Wallace. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] RFID - EAccess violation
I missed the use of key == buffer[] initially myself, no small thanks to the confusing names and amount of code obfuscating what is really going on. The most concise way to avoid confusion (and mistakes) would be to eliminate the intermediate variables entirely, use the most concise initialisation possible, and name the buffer variables appropriately: const KEY_CHAR = $FF; KEY_LEN = 6; var databuf, errbuf: array[0..255] of Char; begin // Initialise buffers as required ZeroMemory(@databuf, Length(databuf)); ZeroMemory(@errbuf, Length(errbuf)); FillMemory(@databuf, KEY_LEN, KEY_CHAR); // Now call the API, passing pointers to the buffers... receive := API_PCDRead(0,0,$00,10,1,@databuf,@errorbuf); Of course, this assumes that what is needed by the API fn are simple, immutable pointers to buffers of some fixed size (256 bytes). (These being the assumptions in the code as currently written). I think at this point we need to hand back to the OP and await more information. :) On 28 May 2015 at 16:07, Karl Reynolds kreyno...@chocfishsoft.co.nz wrote: That should be if i 6 then Cheers, Carl On Thu, May 28, 2015 at 4:06 PM, Karl Reynolds kreyno...@chocfishsoft.co.nz wrote: *Incidentally, buffer is used in the original code - it receives the keydata string via the call to StrPCopy. key ends up as effectively @buffer[0]* Oh right, I missed that! Then what I wrote was wrong, especially if the function is expecting to write back over buffer.. Yes, we do really need to know more about the function being called; in the absence of that information though, it wouldn't hurt to initialise the arrays. var key, bufferr: PChar; keydata, bufferrdata: array[0..255] of char; ... begin for i := 0 to 255 do begin if i = 6 then begin keydata[i] := #255; end else keydata[i] := #0; bufferrdata[i] := #0; end; key := PChar(@keydata); bufferr := PChar(@buffdata); receive := API_PCDRead(0,0,$00,10,1,key,bufferr); ... (I called it keydata rather than buffer to save myself confusion :)) Cheers, Carl On Thu, May 28, 2015 at 3:41 PM, Jolyon Smith jsm...@deltics.co.nz wrote: Fair enough. That wasn't entirely clear so thought it worth clarifying in case the OP was confused into thinking this was somehow involved in the AV. (Incidentally, buffer is used in the original code - it receives the keydata string via the call to StrPCopy. key ends up as effectively @buffer[0]). On 28 May 2015 at 15:31, Karl Reynolds kreyno...@chocfishsoft.co.nz wrote: Jolyon, I was pointing out a separate error that had nothing to do with the AV he was getting. * there looks to be an error in your code even if it works* Cheers, Carl On Thu, May 28, 2015 at 2:43 PM, Jolyon Smith jsm...@deltics.co.nz wrote: @Carl, Although the code probably is incorrect in the way that it references buffer after the call, rather than bufferr, this in itself will not cause an AV since both buffer and bufferr are both statically allocated arrays and thus references to items in these arrays will be valid, even if not correct, as long as those references are within the bounds of the array, which they are in this case. On 28 May 2015 at 12:33, Karl Reynolds kreyno...@chocfishsoft.co.nz wrote: I don't know the API_PCDRead function. But there looks to be an error in your code even if it works. You are passing bufferr (two 'r's) to the function but referring to buffer (one 'r') afterwards, which wasn't used (unless there's other code you didn't show). So you need to look at that. That aside, for the bit leading up to the call, try something like: var key, bufferr: PChar; keydata: string; buffdata: array[0..255] of char; ... begin // Allocate a string of six consecutive $FFs keydata := #255#255#255#255#255#255; // Convert to a PChar, an easy way to avoid having to allocate memory explicitly key := PChar(keydata); // Once again avoid having to allocate memory explicitly // Point bufferr at the address of an array of 256 characters bufferr := PChar(@buffdata); receive:=API_PCDRead(0,0,$00,10,1,key,bufferr); ... Cheers, Carl On Thu, May 28, 2015 at 11:33 AM, Marshland Engineering marshl...@marshland.co.nz wrote: Thanks for the replies. this is the line receive:=API_PCDRead(0,0,$00,10,1,key,bufferr); I'm way out my depth with the workings of this function. I just do simple coding - A ex dBase3 programmer. I took the sample code that the RFID supplier gave, stripped off everything I didn't need other than the read line for RFID card and then copied the bits into my program which now crashes. I was wondering if the XPMENU call or something like that is interfering with other modules ? My debugging is limited to finding the line with the error. Both programs are run in Delphi 6, same machine and same environment. I can't find how to code this, where
Re: [DUG] RFID - EAccess violation
However, since you are using Delphi 6 the StrPCopy code should be yielding the same thing as that constant declaration. I've also just noticed that your call to the API passes bufferr directly. I am surprised this even compiles with the declaration for the API function as provided in the code. This indicates that a pointer to a buffer is required, but you are passing the buffer itself: receive:=API_PCDRead(0,0,$00,10,1,key,bufferr); vs (I would expect): receive:=API_PCDRead(0,0,$00,10,1,key,@bufferr[0]); Do you have a reference to the documentation for the API you are using ? That will tell us what the API is expecting which might in turn point to the problem in the code. Without that we are pretty much shooting in the dark. On 28 May 2015 at 12:06, Jolyon Smith jsm...@deltics.co.nz wrote: Sorry, a typo in that. As a typed constant it should have read: const KEY : array[0..6] of Byte = ($FF,$FF,$FF,$FF,$FF,$FF,$00); Note the first '=' is now a ':' On 28 May 2015 at 11:33, Marshland Engineering marshl...@marshland.co.nz wrote: Thanks for the replies. this is the line receive:=API_PCDRead(0,0,$00,10,1,key,bufferr); I'm way out my depth with the workings of this function. I just do simple coding - A ex dBase3 programmer. I took the sample code that the RFID supplier gave, stripped off everything I didn't need other than the read line for RFID card and then copied the bits into my program which now crashes. I was wondering if the XPMENU call or something like that is interfering with other modules ? My debugging is limited to finding the line with the error. Both programs are run in Delphi 6, same machine and same environment. I can't find how to code this, where ever I put it, it crashes. - Expected expression but ARRAY found. const KEY = array[0..6] of Byte = ($FF,$FF,$FF,$FF,$FF,$FF,$00); Thanks Wallace. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] RFID - EAccess violation
Fair enough. That wasn't entirely clear so thought it worth clarifying in case the OP was confused into thinking this was somehow involved in the AV. (Incidentally, buffer is used in the original code - it receives the keydata string via the call to StrPCopy. key ends up as effectively @buffer[0]). On 28 May 2015 at 15:31, Karl Reynolds kreyno...@chocfishsoft.co.nz wrote: Jolyon, I was pointing out a separate error that had nothing to do with the AV he was getting. * there looks to be an error in your code even if it works* Cheers, Carl On Thu, May 28, 2015 at 2:43 PM, Jolyon Smith jsm...@deltics.co.nz wrote: @Carl, Although the code probably is incorrect in the way that it references buffer after the call, rather than bufferr, this in itself will not cause an AV since both buffer and bufferr are both statically allocated arrays and thus references to items in these arrays will be valid, even if not correct, as long as those references are within the bounds of the array, which they are in this case. On 28 May 2015 at 12:33, Karl Reynolds kreyno...@chocfishsoft.co.nz wrote: I don't know the API_PCDRead function. But there looks to be an error in your code even if it works. You are passing bufferr (two 'r's) to the function but referring to buffer (one 'r') afterwards, which wasn't used (unless there's other code you didn't show). So you need to look at that. That aside, for the bit leading up to the call, try something like: var key, bufferr: PChar; keydata: string; buffdata: array[0..255] of char; ... begin // Allocate a string of six consecutive $FFs keydata := #255#255#255#255#255#255; // Convert to a PChar, an easy way to avoid having to allocate memory explicitly key := PChar(keydata); // Once again avoid having to allocate memory explicitly // Point bufferr at the address of an array of 256 characters bufferr := PChar(@buffdata); receive:=API_PCDRead(0,0,$00,10,1,key,bufferr); ... Cheers, Carl On Thu, May 28, 2015 at 11:33 AM, Marshland Engineering marshl...@marshland.co.nz wrote: Thanks for the replies. this is the line receive:=API_PCDRead(0,0,$00,10,1,key,bufferr); I'm way out my depth with the workings of this function. I just do simple coding - A ex dBase3 programmer. I took the sample code that the RFID supplier gave, stripped off everything I didn't need other than the read line for RFID card and then copied the bits into my program which now crashes. I was wondering if the XPMENU call or something like that is interfering with other modules ? My debugging is limited to finding the line with the error. Both programs are run in Delphi 6, same machine and same environment. I can't find how to code this, where ever I put it, it crashes. - Expected expression but ARRAY found. const KEY = array[0..6] of Byte = ($FF,$FF,$FF,$FF,$FF,$FF,$00); Thanks Wallace. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] Parse.com IPhone 3
From the iOS Getting Started Guide on Parse.COM: Note that we support iOS 6.0 and higher. The only iPhone 3 model that can be upgraded to iOS 6 is the 3GS. If your iPhone 3 is some other, older model then it will not support iOS 6 and therefore is not supported by PARSE.COM either. On 20 May 2015 at 14:12, Willie Juson wil...@compliant.co.nz wrote: Hi, I’m trying to develop an app that uses push notifications, specifically through the PARSE.COM service. I’m having trouble getting a test IPhone3 to receive push notifications from my website. If I send the notification via the PARSE.COM website (using their “Send a push” function) the phone receives it OK, however the phone doesn’t acknowledge any I send from my website. I am targeting the phone using the devicetoken value as registered against the PARSE.COM service. It works ok for IPhon4,5 and 6 and an IPad 3. Has anyone had any experience with this? TIA Willie ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] XE8
Jeremy, If they are going to *withdraw* entitlement (as reported by the OP) by right associated with ownership of a license and make it contingent upon a separate maintenance contract then yes, I expect to see a *commitment *expressed as well as an entitlement. Note: this isn't primarily about whether or not there will be any updates/hotfixes to the current version, which a customer may not be in a position to transition to, but whether that customer can *expect* to receive any updates or hotfixes to the previous version they own a license for and may be currently stuck on. The expression of entitlement to updates and hotfixes for up to 3 prior versions is offered as part of the value proposition of SA. But there is no *commitment* to realise this value. Historically EMBT have abandoned each Delphi version as soon as a new version is released, almost without exception. Worse: in some cases they have regressed defects previously fixed! Based on that, an entitlement to updates to previous versions is completely and utterly meaningless. If EMBT had a track record of actively and effectively supporting older versions then there wouldn't be an issue. But they don't. It would be quite straightforward to commit to something along the lines of defects fixed in the current version *will* also be fixed in up to 3 prior versions where affected by the same defect. i.e. yes an unknown, in terms of exactly what will be fixed, but a quantified and express commitment that certain fixes applied in the current version WILL be fixed in applicable, qualifying prior versions. And to be fair there are a LOT of *known* bugs reported in prior Delphi versions and some of these are claimed to have been fixed in XE8. So where are the updates to fix these for XE5, 6 and 7 ? Some other things to bear in mind: This is the same company that attempted to surreptitiously impose a restriction in their EULA on the use of 3rd party products to extend the capabilities of their own (the prohibition on the use of client/server API's with Pro SKU in XE3). This is the same company that attempted to impose a 5% price rise on [my!] SA renewal in clear and direct contravention of their own terms and conditions for imposing such a rise. This is the same company that advertised and sold cross-platform development in the Pro SKU to entice new users/customers, only to then withdraw that capability. Quite simply this is not a company that has earned the right to be trusted implicitly when it comes to their license and contract terms. Customers - new and old - would be well advised to pay very close attention and to interpret any vague or ambiguous terms in the context of the conduct of the vendor. An empty promise costs nothing to make. EMBT's assessment that at least some people will be naive enough to believe that it represents value appears to be right on the money [sic]. There is of course an alternative approach: If there is no intention of providing updates to older versions then simply say so. At least then the value proposition could be more honestly evaluated. The ever-benevolent, butter-wouldn't-melt, fairy godmothers that some people seem to believe are at the helm at EMBT would always have the option of providing such updates as ex gratia on an ad-hoc basis if they wish, they simply wouldn't be obliged to. *But nothing in the current SA obliges them to either*. On 13 April 2015 at 17:45, Jeremy North jeremy.no...@gmail.com wrote: So you want them to quantify an unknown. Good luck with that. Perhaps it's just the areas of the industry you touch that's in trouble. Sent from my iPhone On 13 Apr 2015, at 3:20 pm, Jolyon Smith jsm...@deltics.co.nz wrote: If this is what get's dismissed as pedantry these days then the industry is in deeper trouble than I imagined. It used to be called paying attention to important details and sounding notes of caution where warranted. An Entitlement is not the same as an Obligation or even an Expectation, and ignoring the distinction is a recipe for disaster in any contract negotiation (which is what a license and support agreement is, lest we forget). On 13 April 2015 at 16:26, Jeremy North jeremy.no...@gmail.com wrote: pedantic much? On Mon, Apr 13, 2015 at 1:52 PM, Jolyon Smith jsm...@deltics.co.nz wrote: Updates and hot fixes for up to two (2) years and three (3) major releases This is meaningless unless there is also a money-where-your-mouth-is commitment to *provide* updates and hotfixes for versions other than the current one. This is actually what it says doesn't it. Not really. It says that SA entitles you to *receive* updates and hot-fixes. It says nothing about any commitment to *provide* any such updates or hot-fixes. Of course, there is no way to predict just how bad a release is in order to determine how many updates or hotfixes would be required. On 13 April 2015 at 15:24, Jeremy North jeremy.no...@gmail.com wrote
Re: [DUG] XE8
If this is what get's dismissed as pedantry these days then the industry is in deeper trouble than I imagined. It used to be called paying attention to important details and sounding notes of caution where warranted. An Entitlement is not the same as an Obligation or even an Expectation, and ignoring the distinction is a recipe for disaster in any contract negotiation (which is what a license and support agreement is, lest we forget). On 13 April 2015 at 16:26, Jeremy North jeremy.no...@gmail.com wrote: pedantic much? On Mon, Apr 13, 2015 at 1:52 PM, Jolyon Smith jsm...@deltics.co.nz wrote: Updates and hot fixes for up to two (2) years and three (3) major releases This is meaningless unless there is also a money-where-your-mouth-is commitment to *provide* updates and hotfixes for versions other than the current one. This is actually what it says doesn't it. Not really. It says that SA entitles you to *receive* updates and hot-fixes. It says nothing about any commitment to *provide* any such updates or hot-fixes. Of course, there is no way to predict just how bad a release is in order to determine how many updates or hotfixes would be required. On 13 April 2015 at 15:24, Jeremy North jeremy.no...@gmail.com wrote: On Mon, Apr 13, 2015 at 12:56 PM, Jolyon Smith jsm...@deltics.co.nz wrote: Native mobile controls OSX iOS Android for many controls (eg DateTime picker) In one review I read it was noted that this is a NO-OP on everything except iOS. On all other platforms you still get the doppelganger FireMonkey controls, even if you have configured for native. The native controls are basically for iOS as mentioned - not all have native support. The doppelganger fmx controls are good if you are creating a bespoke look and feel for your corporate brand across all supported platforms. Updates and hot fixes for up to two (2) years and three (3) major releases This is meaningless unless there is also a money-where-your-mouth-is commitment to *provide* updates and hotfixes for versions other than the current one. This is actually what it says doesn't it. The intention is apply fixes to previous versions. I understand it won't be all fixes as some will not be possible without breaking interface compatibility. If it is done as they say, it will be a welcome change but then again, how can we trust a company that can't even keep their newsgroups operational consistently and have drones looking at submitted requests and closing them with nonsensical resolutions. When was the last time EMBT released more than a token update or hotfix for anything other than the current version ? Is their any commitment to do better in this regards in the future ? ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] Anyone using GIT
The hump to get over is the distinction between a centralised repo (SVN) vs distributed. i.e. the fact that your working copy IS the repo, the whole repo. All the history. The whole enchillada. A developer commits their work to their repository. ie. their working copy is not just just their latest version of their work on the code, but ALL of their revisions, so a developer can commit frequently and often to capture incremental revisions. Then, when work is complete they would push those changes out to other repositories that need to incorporate those changes. Again, ALL the revisions are transmitted, not just the latest changes. Obviously trying to keep track of numerous sync'ed clones of a repo could be tricky, and you will ideally have a master repo that acts as a centralising repo. In Git this would usually be achieved with a bare repository. A bare repository is the closest you get to a central/server repo in git. A bare repo simply means that it is a repository that contains no working code of it's own. If you navigate to that repo on disk you won't find any source code or other repo contents in directly readable form (hence bare). It is a repo that consists entirely of commit history. . To work with another repo you create a local clone. This initially contains all of the history in tat repo up to the point you clone it along with a reference back to the original repo as a remote, allowing you to push any changes back up (or pull further changes back down). For collaborative projects where the entire team is not directly under the repo owner's control, they will typically require that any changes you wish to submit be co-ordinated via a pull request. That is, you fork their repo, make your changes in a clone of that fork and then instead of directly pushing your changes into the original repo you send a pull-request which notifies the repo owner of the change. They are then able to review your change in your fork and pull it into the repo only if they are happy. But this is just one workflow and with the flexibility offered by Git there are numerous workflow options to evaluate, in addition to understanding the core concepts they build on. All of this I have picked up simply by reading the docs and experimenting. :) It isn't rocket science, As I said, it's getting your head around the distributed approach that is key. GitHub provides a useful playground to experiment with git. Set yourself up a free account and start playing with some public repos (you only have to pay to host private ones, or so it used to be). Be prepared to make mistakes as you get to grips with the concepts. Don't set out to create a real repo at first - it almost certainly won't fit your needs out of the gate. Incidentally, I highly recommend Tortoise Git. On 30 March 2015 at 17:03, Sean Cross sean.cr...@catalystrisk.co.nz wrote: We just started using it this month. I found http://www.diaryofaninja.com/blog/2014/08/20/so-you-want-your-team-to-start-using-git-ndash-part-1-getting-started to be very helpful. Syncfusion also do a GIS Succinctly ebook available for free from their website. Regards Sean -Original Message- From: delphi-boun...@listserver.123.net.nz [mailto: delphi-boun...@listserver.123.net.nz] On Behalf Of Rohit Gupta Sent: Monday, 30 March 2015 10:55 a.m. To: NZ Borland Developers Group - Delphi List Subject: [DUG] Anyone using GIT Has anyone been using GIT for a while ? I am looking for someone to give us a crash course on it. We will reimburse you for your time. Regards Rohit ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] Delphi vs C# for web services performance
It's definitely there. Here's a direct link: https://github.com/deltics/delphi.libs/blob/master/rtl/Deltics.JSON.pas Let me know if you have trouble with it. Note that the unit is not standalone - you will need other units from my RTL and it will likely be simplest to clone the repo (or checkout/get, if you use the SVN/Git bridge) rather than to try to grab individual files. On 26 March 2015 at 08:10, John Bird johnkb...@paradise.net.nz wrote: Jolyon, Am interested in looking at your JSON library – we use the lkJSON library which is adequate, and the inbuilt system.JSON - but the have heard several comments for doing various serialising of FHIR objects into either XML or JSON that the Delphi JSON libraries seem to be problematic and a weak point. Would be interested to hear more about the strengths of your JSON library. cheers *From:* Jolyon Smith jsm...@deltics.co.nz *Sent:* Tuesday, March 24, 2015 3:01 PM *To:* NZ Borland Developers Group - Delphi List delphi@listserver.123.net.nz *Subject:* Re: [DUG] Delphi vs C# for web services performance @Stefan and anybody else interested re JSON... You might like to investigate my JSON implementation, available free (as in beer) from my github repo. The RTL Smoketest project includes tests for the Deltics.JSON unit (smoketest framework is in the same repo) and also acts as an example of basic usage (though this should be fairly straightforward). Supports Delphi 7 and later. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] Delphi for Mac
Lazarus won't just re-compile any old Delphi app from Windows to Mac without potentially significant re-working. Not even Delphi tself can do this, if the app is currently a VCL app (you will need to port .the UI to FireMonkey first). Any option that involves changing the project code in order to compile to a Mac executable is unlikely to be worth the effort for a single user, and without a Mac yourself to test on, you could never had confidence that your app will work for your user until they have tested it for you.. Whatever you do, you will have to spend some time and quite possibly some money. The only way to avoid incurring that cost is to ask/require your user to spend that money to establish a Windows VM on their system. There are a number of solutions for this, including free options (VirtualBox) and comemrcial (VMware, Parallels etc). On top of the VM itself of course, the user will need a Windows license as well. Depending on the Mac hardware and on the VM solution they might choose, they could even set things up so that your application runs seamlessly on the Mac desktop. This isn't achieved through recompilation or binary compatible runtime libraries, but simply by hiding the Windows Desktop and rendering each application directly into the Mac desktop, still running as a plain and simple Windows app in a Windows VM. Parallels offers this capability, in what they call Coherence mode. The Windows desktop is merged with the Mac desktop - your Start menu is an icon in the Mac menu bar and each Windows app runs directly on the Mac desktop. VMWare has a similar mode I believe. You (or your customer) pays your money (or not) and makes your choice. :) On 23 March 2015 at 10:56, Marshland Engineering marshl...@marshland.co.nz wrote: One of my users runs a Mac. I've done a bit of a web search but not been successful other than finding out to make a Hackintosh. I only have one application so I don't want to spend any money !! Lazarus could be an option but can I compile to make a Mac exe using a PC ? Any other suggestions are welcome. One is to give him an old PC laptop. Cheers Wallace ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] Delphi vs C# for web services performance
@Stefan and anybody else interested re JSON... You might like to investigate my JSON implementation, available free (as in beer) from my github repo. The RTL Smoketest project includes tests for the Deltics.JSON unit (smoketest framework is in the same repo) and also acts as an example of basic usage (though this should be fairly straightforward). Supports Delphi 7 and later. On 23 March 2015 at 15:45, Stefan Mueller muell...@orcl-toolbox.com wrote: Some thoughts: -The real processing of the data be that in C# or Delphi (encoding to json/xml, etc) will probably be in 1ms range. The slight speed advantage of native compiled Delphi code over C# is irrelevant compared to the overhead of database, network and webserver request handling. -The latest versions of IIS (anything version 8+) are quite speedy in request processing (catching up a bit with NGINX, etc). My webserver runs on an Xeon E3-1240 - which isn’t exactly very powerful hardware. last time I made some benchmarks I got 39k req/s for static content (small 174bytes file) and 9.3k req/s for a simple JSON Rest service (a simple service that returned some cities/states for a given country from cached data, 817bytes). That’s on default settings before performance tuning anything (which wasn’t necessary in my case). I’ve seen benchmarks running a simple service in WCF on a core i5 processor handling 50k+ req/s … I am sure if you get some proper hardware (xeon e7 ?) you can easily get into to 100k+ region. -Delphi support for XML (through OmniXML, don’t use the native Delphi MSXML) is ok … but still haven’t really found a good JSON library for Delphi. The built in functions are a pain to work with (especially if you need to read JSON). I wish there is something like FastJSON (a C# library) in Delphi for serializing/deserializing. -In my experience, anything web-related is just so much easier to do in DotNet. Delphi is great for desktop applications … and DotNet is fantastic for web stuff (great platform tied in with IIS, ASP.Net MVC, WCF, etc and heaps of awesome third party libraries). -Benchmark your own service, it probably takes you less time to write a simple testcase in C# and benchmark it than it took me to respond to this email ;-/ … Kind regards, *Stefan Müller*, RD Manager *ORCL* *Toolbox Ltd.* Auckland, New Zealand P Please consider the environment before printing this email This message is intended for the adresse named above and may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone. *From:* delphi-boun...@listserver.123.net.nz [mailto: delphi-boun...@listserver.123.net.nz] *On Behalf Of *John Bird *Sent:* Monday, 23 March 2015 2:33 p.m. *To:* NZ Borland Developers Group - Delphi List *Subject:* Re: [DUG] Delphi vs C# for web services performance Current version (Hospital Java app) used to have a requirement that the DB returns each result within 200ms (fires about 15 simultaneous queries to various systems including 2 or 3 to ours). Currently the calls are to stored procedures on a SQL Server cluster to get the data. The web service (Delphi or C#) would put a layer between the application and the DB, packaging the query results into XML or JSON and its pretty critical to get as close to the direct DB access speed as possible. At times being a hospital system the load is high and the response times are crucial. *From:* Leigh Wanstead leigh.wanst...@gmail.com *Sent:* Monday, March 23, 2015 11:44 AM *To:* NZ Borland Developers Group - Delphi List delphi@listserver.123.net.nz *Subject:* Re: [DUG] Delphi vs C# for web services performance Hi John, What is your requirement for performance? i.e. One million user to get median value 100ms response time? Regards Leigh On 23 March 2015 at 10:27, John Bird johnkb...@paradise.net.nz wrote: There is a web service we might are looking at implementing. We could use either Delphi or C#. Performance is highly critical. Will be getting getting REST request, getting data from a DB. and packaging it into XML or JSON according to the request. We have noticed that some C# web services have some latency but this might be due to how they are setup on IIS rather than an inherent language issue. We are wondering if there is any clear reason to do it in Delphi - anyone have metrics or references etc on performance? ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe -- ___ NZ Borland Developers Group - Delphi mailing list
Re: [DUG] iOS 64bit
@David, Delphi has always been a bit of a niche, but occupied a big enough niche that although it was difficult to find the developers needed it wasn't impossible (and for a long time the quality of the smaller quantity of Delphi developers vs that of the much larger VB/C# group largely offset the quantity advantage of those more plentiful resources). But more and more people have taken note of the writing on the wall and many of those quality Delphi developers are now applying their skills in .net and are not looking back. Having been involved with trying to hire Delphi skills in NZ for much of the past 10 years, I can say that it has only gotten harder and harder. Increasingly we are forced to look overseas, and be able to offer a definite career path out of Delphi as part of the prospects. Solutions to this particular aspect of the confidence problem with Delphi coming from Europe, the US and elsewhere may not be as effective here given that those regions are still not yet at that scarcity point (quite obviously they are not, otherwise we in NZ wouldn't be able to find there the Delphi skills that we can no longer find here). On 29 January 2015 at 23:45, David Brennan dugda...@dbsolutions.co.nz wrote: We've had questions along those lines before. My usual answer is that there is no way we would even attempt to write our software in Java and C# wasn't around when we started. Switching to C# would be an option but for our software there are few obvious benefits to doing so. The main one would be a larger pool of developers to hire from but we almost always hire graduates anyway so that doesn't affect us much. Conversely there could be some downsides in that our software is quite computationally intensive and while C# can be fairly heavily optimised these days it is an unknown whether it would be able to match Delphi for our workload. I might also bring up C++ by saying that in some ways C++ would be a more suitable tool for our sort of software but we believe Delphi to be much more productive and much better for GUIs. At which point in the conversation I say that since there is no obvious benefit in changing to another language and there would be an absolutely massive cost involved (without even getting into the mantra as espoused by Joel Spolsky that you should *never* do a full re-write) it really isn't an issue for us. If necessary I also make the point that C# was designed by the same guy (Anders Heijlsberg) who led the design of Delphi and at core they solve similar problems in similar ways. However we are fortunate that we are usually selling to the business rather than the IT department, so the business makes their decision based on the functionality we can offer rather than the IT department deciding. For software which is sold primarily to IT departments it could be a slightly harder discussion, but even so, unless they can point out specific problems with not having some particular software written in C# it is all rather woolly and speculative on their part. I will be interested to see what Malcolm comes back with though. Cheers, David. -Original Message- From: delphi-boun...@listserver.123.net.nz [mailto: delphi-boun...@listserver.123.net.nz] On Behalf Of Paul Hectors Sent: Thursday, 29 January 2015 4:38 p.m. To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] iOS 64bit +1 My recent experience is that corporates do not like it when you inform them that your application is written in Delphi, it is perceived as old and a security risk. It would be nice if there was a white paper or some material to reassure them. -Original Message- From: delphi-boun...@listserver.123.net.nz [mailto: delphi-boun...@listserver.123.net.nz] On Behalf Of Cameron Hart Sent: Thursday, 29 January 2015 1:50 p.m. To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] iOS 64bit Hi Malcolm We regularly get questioned on our use of Delphi versus Microsoft C# when responding to RFPs. The market has a perception that if it's not Java of C# then it is old technology (I doubt if I drilled into it with anyone whether they would be able to articulate why they think that). This creates a barrier to sale in some cases. Are you or someone in your team able to provide any sound bites regarding Delphi versus C#/Java that we can use when responding thanks Cameron Hart Flow Software Limited PO Box 302 768, North Harbour P +64 9 476 3569 Auckland 0751, New Zealand M +64 21 222 3569 www.flowsoftware.co.nz E cameron.h...@flowsoftware.co.nz This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone. Please consider the environment before printing this email -Original Message- From:
Re: [DUG] iOS 64bit - Delphi vs Java
@John, I have to wonder what the rational debate would be about. There are two ways to interpret a concern about age and years in existence is I think too literal an interpretation. Measured from it's birth Delphi is perhaps about the same age as Java, yes. Although that is only the case if you ignore the previous existence of Turbo Pascal, from which Delphi directly evolved. But in addition, Java was (one of) the first in the new generation of managed runtimes. A new(er) technology and a new (to many) approach. .net and Java are cut from the same cloth. Or at least more significantly similar cloth than Delphi and .net or Delphi and Java. For example. As a secure language, Delphi has no more problems (and in many ways fewer) than, say, C or C++. But as the runtime works more directly with memory than the managed runtimes with no sandbox of its own and no gatekeeper other than as may be provided in the (similarly aging) OS API's, yes as a language it is less secure than a managed runtime. Of course it's possible to write secure code, but it is also significantly easier to inadvertently write non-secure code than in a managed environment (the distinction of those others being 'managed' somewhat being the point) where the compilers will these days often specifically reject such code unless you go out of your way to re-assure the compiler that you know what you are doing (or at least think you do). There is also the use of proprietary technologies that the tool vendor has a habit of changing from time to time. Did you replace the BDE yet ? Did you replace it with DBExpress ? Using 3rd party drivers ? Are they still supported ? When might you be planning to replace DBExpress with FireDAC ? What comes after FireDAC ? Did you ever migrate to CLX ? (and then what?) Have you migrated from VCL to FMX yet ? It is hard to avoid the fact that Borland/CodeGear/Embarcadero have form in this area. (Which isn't to say that .net is itself entirely immune from such issues) On 29 January 2015 at 18:32, John Bird johnkb...@paradise.net.nz wrote: Old yes, well C is older, C++ is about as old, Java is about as old (1996 for V1). So there is a rational debate to be had about age. Security risk ? I would have thought off the top of my head that Delphi does not carry too many obvious security risks: - Relatively few DLL problems as it generally packages everything in the EXE - Relatively immune to buffer overflows if not allocating memory manually or using C-type strings (PChar). - Can one really make a case that Delphi is less secure than Java? There are occasional bugs to watch out for eg http://www.coresecurity.com/advisories/delphi-and-c-builder-vcl-library-buffer-overflow Maybe the corporates mean security risk of an ageing programmer suddenly feeling the need to retire from whatever cause. -Original Message- From: Paul Hectors Sent: Thursday, January 29, 2015 4:38 PM To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] iOS 64bit +1 My recent experience is that corporates do not like it when you inform them that your application is written in Delphi, it is perceived as old and a security risk. It would be nice if there was a white paper or some material to reassure them. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] iOS 64bit - Delphi vs Java
@David, I'm not sure how evolutionary change is relevant to concerns relating to technology having been superceded and abandoned. The BDE didn't evolve. It was replaced and abandoned and applications relying on it then experienced difficulties arising from changes in the operating environment. It may not be possible to avoid this entirely. But you can hope to reduce the risk by ensuring that your applications employ technology that is an integral part of your operating environment, rather than relying on proprietary components that may be abandoned. Particularly if the developer of the proprietary tech has an established record of adopting a replacement over evolution approach to change in these areas. On 30 January 2015 at 10:38, David Brennan dugda...@dbsolutions.co.nz wrote: I’m not sure the change in technologies over time is particularly relevant – if there is a language where technologies such as this haven’t evolved in the last 15 years then that language is probably dead or dying. As you mention .NET has plenty of such examples which have been hung out to die slow deaths. *From:* delphi-boun...@listserver.123.net.nz [mailto: delphi-boun...@listserver.123.net.nz] *On Behalf Of *Jolyon Smith *Sent:* Friday, 30 January 2015 8:46 a.m. *To:* NZ Borland Developers Group - Delphi List *Subject:* Re: [DUG] iOS 64bit - Delphi vs Java There is also the use of proprietary technologies that the tool vendor has a habit of changing from time to time. Did you replace the BDE yet ? Did you replace it with DBExpress ? Using 3rd party drivers ? Are they still supported ? When might you be planning to replace DBExpress with FireDAC ? What comes after FireDAC ? Did you ever migrate to CLX ? (and then what?) Have you migrated from VCL to FMX yet ? It is hard to avoid the fact that Borland/CodeGear/Embarcadero have form in this area. (Which isn't to say that .net is itself entirely immune from such issues) On 29 January 2015 at 18:32, John Bird johnkb...@paradise.net.nz wrote: Old yes, well C is older, C++ is about as old, Java is about as old (1996 for V1). So there is a rational debate to be had about age. Security risk ? I would have thought off the top of my head that Delphi does not carry too many obvious security risks: - Relatively few DLL problems as it generally packages everything in the EXE - Relatively immune to buffer overflows if not allocating memory manually or using C-type strings (PChar). - Can one really make a case that Delphi is less secure than Java? There are occasional bugs to watch out for eg http://www.coresecurity.com/advisories/delphi-and-c-builder-vcl-library-buffer-overflow Maybe the corporates mean security risk of an ageing programmer suddenly feeling the need to retire from whatever cause. -Original Message- From: Paul Hectors Sent: Thursday, January 29, 2015 4:38 PM To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] iOS 64bit +1 My recent experience is that corporates do not like it when you inform them that your application is written in Delphi, it is perceived as old and a security risk. It would be nice if there was a white paper or some material to reassure them. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] iOS 64bit - Delphi vs Java
@John, I am surprised that you dismiss the ASLR problem so lightly. You cannot surely regard this as merely an installation nuisance ? Every time you boot a Windows Vista (or later) system, the OS randomizes the location of some DLL's in memory for each process. There is a specific address range reserved for this shuffling and DLL's that are not flagged as compatible with the mechanism are excluded from the process. The problem is that the BDE relies on a piece of shared memory, used by every BDE application. rather inconveniently, the default location for this shared memory is in the address range reserved for this DLL randomization ! Every time you boot the system, a DLL may be plonked at that address and when you try to start your first BDE application it will fail to load since it cannot reserve the required piece of shared memory at that location. The BDE absolutely does not work under those conditions. The problem is often dismissed as a random issue because it seems to be fixed by a reboot (or two). The ASLR shuffling caused by a new boot is more likely than not to come out with a BDE compatible result, so if you get unlucky once you are unlikely to be unlucky a second time (in succession). But if you do get unlucky. Tough luck. (until you reboot). To resolve this properly you need to identify a safe area outside of the ASLR address range using some form of VM address space inspector, such as the SysInternals VM Map utility, and change your BDE configuration to use this alternative location. The problem is that there is no guaranteed safe location that you can use for ALL systems. The available safe addresses will vary from system to system according to what device drivers, system components and applications are installed and in use. The only way to identify a safe area is to start every application on a system that a user might use and identify an unused address common to ALL those applications. Then all you can do is hope that a subsequent device driver, system component or application update/install will not render your chosen safe address unsafe again. This would be a trivial issue to resolve in the BDE itself by making the shared memory allocation more resilient. But of course, the BDE is no longer supported and afaik hasn't had a fix in more than a decade and never will again. On 30 January 2015 at 12:26, John Bird johnkb...@paradise.net.nz wrote: I have been involved in migrating a BDE application from Delphi 5 to XE5, and it still uses the BDE. No problem. Not abandoned – so what is your point? The reasons they still use the BDE are 1 – No work to do other than figure out installing it on Windows 7 etc 2 – The BDE despite being a nuisance to install on workstations actually offers some real nice functionality – the update queries with GUI selectable fields that are candidates for being updated with ApplyUpdates is very nice to use. Alternatives meant enough recoding that they decided not to bother. 3 – That it still works after 15 years where other technologies have come and gone is neat. I found an interesting user survey on Delphi vs C#. http://vschart.com/compare/delphi-programming-language/vs/c-sharp C# scored more real good things (eg free versions for commercial use, documentation, HTML, Community, Jobs) But the most interesting ones to me were: Preference – Delphi scored 59% to C# 41%, Delphi works out of the box 65% to C# 35% Surprises or dubious areas are – C# rated well for iOS/Android development (is this so??) and better for performance than Delphi (really?) C# rated poorly for JVM support. Surprise surprise! *From:* Jolyon Smith jsm...@deltics.co.nz The BDE didn't evolve. It was replaced and abandoned and applications relying on it then experienced difficulties arising from changes in the operating environment. It may not be possible to avoid this entirely. But you can hope to reduce the risk by ensuring that your applications employ technology that is an integral part of your operating environment, rather than relying on ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] iOS 64bit - Delphi vs Java
@Russell, As well as a desktop DB engine, the BDE was also used for client/server connectivity to SQL Server, Oracle etc. In those cases it is only good luck that the BDE drivers (a.k.a SQL Links) for those platforms have continued to work or (more likely) that a suitable ODBC driver alternative is/was available which continued to be compatible with the BDE ODBC driver. But regardless of whether you are using it as a desktop engine or part of a client/server infrastructure, the BDE has significant problems with modern versions of Windows (by which I mean Vista and later) . (See my other post w.r.t ASLR) On 30 January 2015 at 12:36, russell russ...@belding.co.nz wrote: I thought I was the last BDE developer to switch to SQL and particularly a single file database. Maybe not? For those not familiar with the BDE, it is a multi-file database. I had three apps deployed in the BDE. It was used because it was free and it worked on my desktop. After a while bugs rolled in with file corruptions. It installed well on a single desktop and had problems installing to a network. The BDE did evolve, but not well. Several fixit packages were made by third-parties. The BDE was, I suppose, beyond repair. Interbase and Firebird had paths to take the BDE into better technology. The Firebird embedded DB engine provided a BDE replacement for a desktop package. Russell *From:* delphi-boun...@listserver.123.net.nz [mailto: delphi-boun...@listserver.123.net.nz] *On Behalf Of *Jolyon Smith *Sent:* Friday, 30 January 2015 11:43 a.m. *To:* NZ Borland Developers Group - Delphi List *Subject:* Re: [DUG] iOS 64bit - Delphi vs Java @David, I'm not sure how evolutionary change is relevant to concerns relating to technology having been superceded and abandoned. The BDE didn't evolve. It was replaced and abandoned and applications relying on it then experienced difficulties arising from changes in the operating environment. It may not be possible to avoid this entirely. But you can hope to reduce the risk by ensuring that your applications employ technology that is an integral part of your operating environment, rather than relying on proprietary components that may be abandoned. Particularly if the developer of the proprietary tech has an established record of adopting a replacement over evolution approach to change in these areas. On 30 January 2015 at 10:38, David Brennan dugda...@dbsolutions.co.nz wrote: I’m not sure the change in technologies over time is particularly relevant – if there is a language where technologies such as this haven’t evolved in the last 15 years then that language is probably dead or dying. As you mention .NET has plenty of such examples which have been hung out to die slow deaths. *From:* delphi-boun...@listserver.123.net.nz [mailto: delphi-boun...@listserver.123.net.nz] *On Behalf Of *Jolyon Smith *Sent:* Friday, 30 January 2015 8:46 a.m. *To:* NZ Borland Developers Group - Delphi List *Subject:* Re: [DUG] iOS 64bit - Delphi vs Java There is also the use of proprietary technologies that the tool vendor has a habit of changing from time to time. Did you replace the BDE yet ? Did you replace it with DBExpress ? Using 3rd party drivers ? Are they still supported ? When might you be planning to replace DBExpress with FireDAC ? What comes after FireDAC ? Did you ever migrate to CLX ? (and then what?) Have you migrated from VCL to FMX yet ? It is hard to avoid the fact that Borland/CodeGear/Embarcadero have form in this area. (Which isn't to say that .net is itself entirely immune from such issues) On 29 January 2015 at 18:32, John Bird johnkb...@paradise.net.nz wrote: Old yes, well C is older, C++ is about as old, Java is about as old (1996 for V1). So there is a rational debate to be had about age. Security risk ? I would have thought off the top of my head that Delphi does not carry too many obvious security risks: - Relatively few DLL problems as it generally packages everything in the EXE - Relatively immune to buffer overflows if not allocating memory manually or using C-type strings (PChar). - Can one really make a case that Delphi is less secure than Java? There are occasional bugs to watch out for eg http://www.coresecurity.com/advisories/delphi-and-c-builder-vcl-library-buffer-overflow Maybe the corporates mean security risk of an ageing programmer suddenly feeling the need to retire from whatever cause. -Original Message- From: Paul Hectors Sent: Thursday, January 29, 2015 4:38 PM To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] iOS 64bit +1 My recent experience is that corporates do not like it when you inform them that your application is written in Delphi, it is perceived as old and a security risk. It would be nice if there was a white paper or some material to reassure them
Re: [DUG] iOS 64bit - Delphi vs Java
@Tony, Not an argument, just a question of establishing scale when quantifying the effort involved, which I am sure at least some people still dealing with the BDE in their Delphi apps might find useful to do. f.i. How do you define large w.r.t an application in this context ? Having worked on some large applications/suites myself (multi-million LOC) with TQuery instances numbered in the hundreds and thousands (*not* hundreds OF thousands), how would this compare, for example ? [This isn't about my code base is bigger than yours bragging rights, just trying to establish some frames of reference] :) Email me off-list if you prefer (jsm...@deltics.co.nz). On 30 January 2015 at 16:50, Tony Blomfield to...@precepthealth.com wrote: Sure I appreciate that there are many variables that will determine this. However I remember that once I got stuck in it was a lot easier than I ever imagined. In fact I had at least ten large applications to do this to, and I was very pleasantly surprised to discover it was not so hard so take courage from this. Anyway let’s not take this further as it’s a rather pointless argument. Cheers. *From:* delphi-boun...@listserver.123.net.nz [mailto: delphi-boun...@listserver.123.net.nz] *On Behalf Of *Jolyon Smith *Sent:* Friday, 30 January 2015 2:32 p.m. *To:* NZ Borland Developers Group - Delphi List *Subject:* Re: [DUG] iOS 64bit - Delphi vs Java @Tony, Rome wasn't built in a day (though bits of it were). :) What I mean by that is that the exercise to migrate away from the BDE is not a fixed amount of work. It depends on: - How many applications you have - How large and complex your application(s) is/are - How your application(s) is/are developed (*) - What you choose to migrate to - How many people you are able/willing to commit to the exercise (* - if there are client data sets already sitting between the code and the query sources then this makes things easier. If not, then things can be significantly more complicated) Not to mention the testing. In some cases the exercise could be a few days at most. But it could also be many. many months at least. It all depends. On 30 January 2015 at 14:06, Tony Blomfield to...@precepthealth.com wrote: I agree with this. moved away from BDE in 2000 as the writing was on the wall. I have some clients that have old BDE apps (Not from us) and I see nothing but problems since Vista. IT is not so difficult to migrate away from BDE. Maybe a few day’s work at most. *From:* delphi-boun...@listserver.123.net.nz [mailto: delphi-boun...@listserver.123.net.nz] *On Behalf Of *Jolyon Smith *Sent:* Friday, 30 January 2015 1:14 p.m. *To:* Russell Belding; NZ Borland Developers Group - Delphi List *Subject:* Re: [DUG] iOS 64bit - Delphi vs Java @Russell, As well as a desktop DB engine, the BDE was also used for client/server connectivity to SQL Server, Oracle etc. In those cases it is only good luck that the BDE drivers (a.k.a SQL Links) for those platforms have continued to work or (more likely) that a suitable ODBC driver alternative is/was available which continued to be compatible with the BDE ODBC driver. But regardless of whether you are using it as a desktop engine or part of a client/server infrastructure, the BDE has significant problems with modern versions of Windows (by which I mean Vista and later) . (See my other post w.r.t ASLR) On 30 January 2015 at 12:36, russell russ...@belding.co.nz wrote: I thought I was the last BDE developer to switch to SQL and particularly a single file database. Maybe not? For those not familiar with the BDE, it is a multi-file database. I had three apps deployed in the BDE. It was used because it was free and it worked on my desktop. After a while bugs rolled in with file corruptions. It installed well on a single desktop and had problems installing to a network. The BDE did evolve, but not well. Several fixit packages were made by third-parties. The BDE was, I suppose, beyond repair. Interbase and Firebird had paths to take the BDE into better technology. The Firebird embedded DB engine provided a BDE replacement for a desktop package. Russell *From:* delphi-boun...@listserver.123.net.nz [mailto: delphi-boun...@listserver.123.net.nz] *On Behalf Of *Jolyon Smith *Sent:* Friday, 30 January 2015 11:43 a.m. *To:* NZ Borland Developers Group - Delphi List *Subject:* Re: [DUG] iOS 64bit - Delphi vs Java @David, I'm not sure how evolutionary change is relevant to concerns relating to technology having been superceded and abandoned. The BDE didn't evolve. It was replaced and abandoned and applications relying on it then experienced difficulties arising from changes in the operating environment. It may not be possible to avoid this entirely. But you can hope to reduce the risk by ensuring that your applications employ technology that is an integral part
Re: [DUG] iOS 64bit
In such cases the concerns about the technology in which a product is implemented are certainly not with the capabilities of the technology since this is easily addressed by demonstrating the capability of your product itself. Rather the concern is likely to be one of business continuance. That is, your on-going ability to find the resources you will need to further develop and maintain the application, product or service on which your customers business will depend if they choose your product over the alternative(s). You may satisfy someone that the Delphi language has been developed and now has more features in common with C# than previously. But concerns about a product not having been implemented in C# (which, I think it is fair to say, less technical, business oriented people often perceive as synonymous with .net) do not often stem from a need to tick boxes on a technology features/capability list. I should say that in Cameron's case I am aware that there is a specific issue in that the Flow product provides a scripting engine which itself uses a dialect of Pascal. So in his case in addition to the business continuance issue, the users of the product themselves also have to take into account availability of Pascal skills/knowledge vs the alternatives (C# / VBScript / JavaScript) more directly. But I think this is a relatively specialised aspect of concern w.r.t that particular product, and is on top of the more general concerns regarding business continuance. imho The problem has only been made more difficult with the fact that .NET support has now been discontinued in Delphi with no apparent plans to replace it and, perhaps to a lesser extent, that developing support for Windows 8.x for existing (i.e. VCL) application has evidently taken a back seat to FMX. I'd like to be wrong, but unfortunately I think that anyone who is expressing such concerns is unlikely to be mollified by anything that can be said about Delphi's recent development, current state or future direction. On 29 January 2015 at 16:38, Paul Hectors p...@powershield.com wrote: +1 My recent experience is that corporates do not like it when you inform them that your application is written in Delphi, it is perceived as old and a security risk. It would be nice if there was a white paper or some material to reassure them. -Original Message- From: delphi-boun...@listserver.123.net.nz [mailto: delphi-boun...@listserver.123.net.nz] On Behalf Of Cameron Hart Sent: Thursday, 29 January 2015 1:50 p.m. To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] iOS 64bit Hi Malcolm We regularly get questioned on our use of Delphi versus Microsoft C# when responding to RFPs. The market has a perception that if it's not Java of C# then it is old technology (I doubt if I drilled into it with anyone whether they would be able to articulate why they think that). This creates a barrier to sale in some cases. Are you or someone in your team able to provide any sound bites regarding Delphi versus C#/Java that we can use when responding thanks Cameron Hart Flow Software Limited PO Box 302 768, North Harbour P +64 9 476 3569 Auckland 0751, New Zealand M +64 21 222 3569 www.flowsoftware.co.nz E cameron.h...@flowsoftware.co.nz This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone. Please consider the environment before printing this email -Original Message- From: delphi-boun...@listserver.123.net.nz [mailto: delphi-boun...@listserver.123.net.nz] On Behalf Of Malcolm Groves Sent: Thursday, 29 January 2015 1:46 p.m. To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] iOS 64bit Yep, on the roadmap for this year...pending anymore surprises like iOS64 bit of course :-) Malcolm Groves Senior Director, Asia Pacific and Japan Embarcadero Technologies Australia Pty Ltd | www.embarcadero.com http://www.embarcadero.com/ Level 10, 46 Market Street Sydney, NSW 2000, Australia mgro...@embarcadero.com | twitter.com/malgroves http://twitter.com/malcolmgroves Mobile: +61 416 264 204 On 29/01/2015 11:39, Paul Harellis paul.harel...@nzracingboard.co.nz wrote: Hi Malcom, Have you got any plans to have Delphi for Linux? Thanks Paul Harellis Development Lead Jetbet Team, Development t+64 (04) 576 6847 m +64 (027)471 3827 epaul.harel...@nzracingboard.co.nz w www.nzracingboard.co.nz ∙ www.tab.co.nz ∙ www.trackside.co.nz ∙ www.theraces.co.nz New Zealand Racing Board 106-110 Jackson Street, Petone 5012, PO Box 38899, Wellington Mail Centre 5045, New Zealand -Original Message- From: delphi-boun...@listserver.123.net.nz [mailto:delphi-boun...@listserver.123.net.nz] On Behalf Of Malcolm Groves Sent: Thursday, 29
Re: [DUG] XE7 and Android Development
@David Brennan - I don't see how you reach the conclusion that XE7 + FireMonkey makes sense if you have an existing code base, given that if you aren't already developing in FMX then that existing codebase is almost certainly VCL and given all the observations you made about how utterly UN-re-usable your existing VCL code base was in your case. The pre-amble seems to point to the exact opposite conclusion. No ? For Eric, I would ask why you are interested in using Delphi for this ? If it is to exploit existing VCL code, then you have little chance of realising any benefit without an awful lot of work (perhaps even more than starting from scratch with an alternative tool/tech). If you seek to leverage familiarity with Delphi to fully exploit any and all Android devices, I suspect you will be similarly disappointed both because the Android support is simply not complete as well as because Delphi for Android is a quite different animal than the Delphi you are used to. You might as well learn Java or apply any knowledge you may have of C# with Xamarin. Or, if you simply wish to continue using Pascal, you could look at RemObjects Oxygene (also previously known as Delphi Prism, in it's .NET garb as re-branded by Embarcadero for a time). I developed a very simple app in Oxygene for Android, iOS and WinPhone. In all three cases the app was developed using Oxygene (ObjectPascal with knobs on) but compiles to genuine, platform native binaries (i.e indistinguishable from those produced by Android Studio, Xcode or Visual Studio). The Android version is here if you are curious: https://play.google.com/store/apps/details?id=itchbox.txt2parkhl=en The downside of the Oxygene approach (as some see it) is that you have to learn how to develop for each platform since there is no comprehensive cross platform abstraction library (although there is a library - Sugar - which makes a certain amount of re-use possible at the RTL layer - sharing common string manipulation routines etc etc). But imho this platform specific aspect of the approach is absolutely NOT a downside for any serious mobile developer as you will quickly realise when you come to appreciate the differences between the platforms and learn how to write apps properly that look and behave properly on each platform, instead of taking a one size fits all approach. It also means that you are learning those platforms and if necessary can apply that knowledge directly to development using the platform native tool chains. i.e. With my simple app I have learned how to program a (simple, VERY simple) SMS sender app for Android, iOS and Windows Phone. I happened to use Pascal, but what I learned about the platforms is just as directly applicable in Java, Objective-C or C# (respectively). It also means that you can *learn* from people with expertise in the framework even if they are using other languages. It is worth mentioning that all 3 versions of the app were developed in just one weekend even though there was zero code re-use between them. The app is essentially 100% UI, and each platform works completely differently when it comes to the SMS APi's so there was no real chance for useful code re-use in such an app anyway. Actually, there were 6 apps in total since I also learned the advertising API's and controls appropriate for each platform (again, different in each case) and created two separate versions of the app for each platform, one free/ad supported, the other paid for with no ads. Creating the 3 ad supported apps was another weekend. :) But Oxygene also is not hosted on Linux, being a Visual Studio plug-in (it is also supported by the free VS Community Edition, so there's no extra cost for using VS Pro any more). However RemObjects are also working on Fire, an OS X hosted IDE (still not Linux but at least also Unix based) for all their languages, since they also provide their own C# compiler as well as 'Silver' - a.k.a Apple Swift. All three languages support all platforms: Java/Android, iOS/OS X, .NET/WPhone. Just my $2 (it was going to be 2c but thought I'd better protect it against future inflation). :) On 22 January 2015 at 16:29, David Brennan dugda...@dbsolutions.co.nz wrote: We created an Android app in XE6 using a moderate amount of code from one of our big Delphi projects. It went OK and we successfully demonstrated the app on phones at a trade show recently, people liked the app. During development we had a few annoyances with how Firemonkey behaved but in general it wasn’t too bad. However getting our existing code (even units with no forms/frames) to work was a bigger issue than expected. We did it in a development branch were we hacked things a moderate amount to get uses clauses and everything to compile with ifdefs, commenting stuff out, etc. A surprising amount of basic classes such as TPoint, TRect, etc (I think if I am remembering correctly) are not available in Firemonkey so we had to do quite a
Re: [DUG] Risk Management Plan
Here at Datacom we have an Application Management unit that specifically addresses these concerns for a variety of clients, taking on the support as well as on-going development and maintenance of existing applications for them. This is not limited only to Delphi applications, obviously. I joined Datacom in part to extend and further establish a Delphi capability in this area and this is now being further expanded, hence the call for CV's I recently posted to the list. :) The flip-side of that is that if there are developers/ISV's on this list who have clients/customers who have concerns in this area, then you might like to put them in touch with us, as we may be able to provide the assurances they need. On 3 December 2014 at 17:24, Graham Marsden grahamars...@gmail.com wrote: Hi John C. This is an interesting issue and often pursued by managers who themselves are of the ilk not to be in their position for very long. On a few occasions I have had this thrown at me when in fact there is no-one in the organsiation that pre-dates me, the outside contactor/developer. It is a valid point and the client is of course wanting continuity in their application's function and development. I have used the fact that this DUG exits at all as an assurance that help is not far away in the form of Delphi expertise should the big yellow bus thing happen. A more reassuring offering to the client would be the existence of a loose or tight association between two or more developers and an assurance that there would be a specific named somebody that your client could contact in such an event. Even better would be to actually meet that person(s) as part of setting up the Risk Management Plan. It is a bit ironic that people think that dealing with a software company is itself some kind of assurance when in fact IT employees tend to be quite mobile and so the connection from the bespoke application to the actual people that created it is often fairly temporary. Regards Graham Marsden ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] Detecting public holidays
I don't have any Delphi code ready to roll to consume it, but this info may be of use in coming up with something: http://www.dol.govt.nz/er/holidaysandleave/publicholidays/publicholidaydates/ical/index.asp Incidentally, did my post re opportunity for Delphi devs here at Datacom make it thru to the list ? I didn't get a copy of the message or an acknowledgement of the post, so am not sure. :S On 2 December 2014 at 14:22, John C j...@sunshinesoftware.co.nz wrote: Hi all I'd like to detect whether a certain date range includes a public holiday and if so what date and name. I had a look on the Internet but only found something at https://pear.php.net/package/Date_Holidays which does not include NZ holidays. Any other ideas? (using PHP) Thanks John C ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] Access violation in TTntCustomListView (Delphi 7)
What version of TNT are you using ? There is nothing intrinsically wrong with the line on which the error is occurring, which suggests that the problem is with the parameters involved. Given that it is a write op to a NIL address, this points the finger at the destination of the WStrLCopy()... the pszText member of the item data. There is potential for the pszText parameter to be invalid, if the LVIF_TEXT flag is not set in the notification mask. According to the community additions on the MSDN ref for the LVN_DISPINFO notification ( http://msdn.microsoft.com/en-us/library/windows/desktop/bb774818(v=vs.85).aspx), this is specifically the case on Windows 8 when list selection changes, as would occur when keying up/down through the list, for example. So far, everything seems to point in the same direction However, the code you have quoted above is conditional on the LVIF_TEXT flag being set, but there is code that precedes this in TNT which invokes the inherited implementation of the CNNotify handler, removing and re-instating the LVIF_TEXT flag in the process. The reason I ask about the version you are using is that in the version I am looking at (2.3.0) this preceding code appears to handle the LVIF_TEXT flag correctly, only re-applying the LVIF_TEXT flag if it was originally set. But I wonder if you have some version of the TNT code which perhaps contains a flaw in this area and is adding this flag when it shouldn't ? Or is it possible that your copy of the source has been modified from the TNT original in a way that might have introduced such a flaw ? It might be helpful to post the entire LVN_GETDISPINFOW handler from the CNNotify() method, to be sure. On 3 November 2014 20:06, Ross Levis r...@stationplaylist.com wrote: I hope someone can help. I’m using the freeware TNT controls with D7 for a TTntListView component. This is working fine for many users but one user experiences a crash when simply using the keyboard to move up and down the listview. He is using Win8 64-bit as I do here, but I can’t duplicate it. It is a virtual listview using OnData. Here is a portion of a MadExcept log. Can provide more if required. exception message : Access violation at address 0050DA73 in module 'SPLStudio.exe'. Write of address . main thread ($d88): 0050da73 SPLStudio.exe TntWideStrUtils 180 +10 WStrLCopy 0053e20e SPLStudio.exe TntComCtrls 2104 +46 TTntCustomListView.CNNotify 004f304f SPLStudio.exe Controls 4645 +53 TControl.WndProc 004f6d5e SPLStudio.exe Controls 6342 +33 TWinControl.WndProc 004c04a5 SPLStudio.exe ComCtrls14815 +12 TCustomListView.WndProc 0053dee4 SPLStudio.exe TntComCtrls 2023 +98 TTntCustomListView.WndProc 00539335 SPLStudio.exe TntControls 666 +19 TWinControlTrap.WindowProc 004f2d5a SPLStudio.exe Controls 4552 +5 TControl.Perform 004f6f20 SPLStudio.exe Controls 6388 +6 DoControlMsg 004f772f SPLStudio.exe Controls 6579 +1 TWinControl.WMNotify ... Code in TntComCtrls.pas where it crashes updating a list item caption... // handle any text info with PLVDispInfoW(NMHdr)^.item do begin if (mask and LVIF_TEXT) 0 then begin Item := GetItemW(PLVDispInfoW(NMHdr)^.item); if iSubItem = 0 then WStrLCopy(pszText, PWideChar(Item.Caption), cchTextMax - 1) else begin with Item.SubItems do begin if iSubItem = Count then WStrLCopy(pszText, PWideChar(Strings[iSubItem - 1]), cchTextMax - 1) else pszText[0] := #0; end; end; end; end; Any ideas appreciated. Thanks, Ross, ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] bordbk70.dll missing or not registered
As a general rule it is a *very* bad idea to install older versions of Delphi under the Program Files folder on Windows versions later than XP. Older versions of the IDE do not behave well under the more restrictive policies in place on that folder since Vista. I would strongly recommend that you back out your Delphi install entirely and start over, installing into some other folder entirely outside of Program Files. I typically use a structure similar to: C:\Delphi\version C:\Delphi\Shared Files For consistency I choose to install *all* my Delphi IDE's into this folder in this way. And always run the installation setup.exe elevated (i.e. as an Administrator). On 30 September 2014 10:10, John C j...@sunshinesoftware.co.nz wrote: Hi all I have installed D7 on my new laptop running Windows 8.1. Running the program in debug-mode comes up with bordbk70.dll missing or not registered. I have copied this bordbk70.dll from my old pc and put it in the directory C:\Program Files (x86)\Common Files\Borland Shared\Debugger. That did not help. Then I browsed the internet and found a way to register this dll using Regsvr32.exe. Although it said that it did register the dll it did not help either. Cleaned registery and rebooted, and no I'm stuck. Any ideas what I can do to fix this? Thanks a lot. John Sunshine ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] Int64 or floating point faster?
@Cameron, you appear to be confused. Yes, Delphi uses a standard implementation of single and double types - the IEEE standards. But I don't know where you got the idea that this standard involves a naive pairing of two ints (of any size). Floating point types are *far* more complex than that. e.g. the internal representation of the value 1 in Double is not (0x0001).(0x) but (0x3fff).(0x) How would I describe it otherwise ? Why, the same way that IEEE 754 describes it of course. ;) http://en.wikipedia.org/wiki/Double-precision_floating-point_format Single is similarly not a naive pairing of two int16's. In fact, the closest I can even think that Delphi has to such a limited implementation for decimal values is the Curreny type, but even that isn't a pair of integers, rather a straightforward fixed point with a scalar of 10,000, yielding 4 fixed decimal places. Back to the OP... If you are using Delphi 7 and were thinking of using Single precision, then I strongly recommend that you do some tests with some representative sample data to establish the most efficient approach, but as a rule of thumb I would expect to find that Single precision would be more efficient than Double (and in the older.Win32 compilers I wouldn't be surprised if these had an even greater performance advantage over Int64). The question then is whether Single precision is adequate for your needs or if you need the additional capacity of Double. If you are inclined toward Int64 for some reason, be aware that there was a bug in the Delphi Int64 arithmetic in older Delphi versions. The 32-bit compiler doesn't use hardware op-codes for Int64 operations but emulates these in software, which is why Int64 performs less well than Double: I'm fairly sure this is the case even today (hence the comparative performance of Double and Int64 even in the XE4 32-bit compiler), but absolutely certain that it is the case with the older Delphi compilers. The details of the bug escape my memory right now, other than that it was a basic arithmetic error in the compiler emitted code (and something of an edge case), rather than a bug in an RTL function. i.e. not something that can be easily avoided. But I am sure your tests will show that Single or Double are more efficient anyway. On 17 August 2014 20:09, Cameron Hart cameron.h...@flowsoftware.co.nz wrote: I’m confused now as I’m pretty sure Delphi uses a standard format to represent float (the same format used anywhere else for that matter). In which case a float is essentially two int32 (or other int’s depending on the scale of the float). Ie a single used two int16. One int represented the mantissa the other the exponent (in essence the decimal portion). Together they resulted in the floating point value. How would you describe this otherwise? *From:* delphi-boun...@listserver.123.net.nz [mailto: delphi-boun...@listserver.123.net.nz] *On Behalf Of *Jolyon Smith *Sent:* Sunday, 17 August 2014 12:54 p.m. *To:* NZ Borland Developers Group - Delphi List *Subject:* Re: [DUG] Int64 or floating point faster? That's curious. Who are they ? It doesn't sound like any floating point implementation I ever came across in Delphi (or anywhere else, for that matter). O.o On 17 August 2014 12:28, Pieter De Wit pie...@insync.za.net wrote: Hi Jolyon, From memory, they used 2 int32's to make a float - this could have been int16's - memory is very vague on this :) The one was used to represent the whole numbers and the other was to show the decimal numbers Cheers, Pieter On 17/08/2014 12:05, Jolyon Smith wrote: @Pieter - I don't understand what you mean when you say that float was int32.int32. For starters, float is an imprecise term. If you mean single then the entire value was always 32 bit in it's entirety. If you mean double then it was always 64 bit. What is this in32.int32 type of which you speak ? O.o On 17 August 2014 11:52, Jolyon Smith jsm...@deltics.co.nz wrote: I think there are too many variables involved to give an answer to this question without some of those variables being reduced to known values. e.g. what hardware ? what version of Delphi ? x64 target or x86 ? what precision of floating point ? Having said that, in a quick test knocked up in my Smoketest framework I found that Double comfortably outperforms Int64 when compiling for Win32 but that both Double and Int64 demonstrated improved performance when compiling for Win64 and that whilst Double still showed some advantage it was not as significant (and in some test runs the difference was negligible). If you are targeting FireMonkey you will have to bear in mind that the back-end compiler is different to the x86/x64 backend, so results obtained using the WinXX compilers will not necessarily be indicative of performance on the ARM or LLVM platforms. Conditions: - Delphi XE4 - Running in a 64-bit Win 7 VM
Re: [DUG] Int64 or floating point faster?
Pieter, better to stick to what tests *show *to be best, not what intuition suggests *should* be. ;) A Pentium CPU doesn't have opcodes for floating point... but it does have an FPU which does. The 32-bit Delphi compiler may not make the absolute best use of the available silicon (e.g. MMX), but it will at least make use of the FPU. But the 32-bit Delphi compiler doesn't use CPU opcodes for Int64 operations - even if they are present in the hardware) which I think is why - in *tests* - Int64 arithmetic Is significantly less efficient than Double arithmetic. Something was bugging me that I had forgotten something... and I had... There is also the Comp type. This is listed as a real type in most documentation but is in fact an Int64. The difference is that operations involving this type are performed in the FPU, rather than through software emulation of a 64-bit integer. So it's possible that Comp might provide a performance advantage over Double. Again, testing will be the key to answering the question of whether or not it does in practice. On 18 August 2014 08:37, Pieter De Wit pie...@insync.za.net wrote: Hi, No, it appears I was wrong. Delphi (at least pascal and by default, I assume then delphi) stores real's as per the IEEE std. See : https://www.informatik.uni-hamburg.de/RZ/software/SUNWspro/pascal/lang_ref/ref_data.doc.html It's a weird layout which results in (if I understand this correctly) a multiply instruction to even set the value: A real number is represented by this form: (-1)sign * 2 exponent-bias *1.f f is the bits in the fraction I would hate to work out the CPU cycles needed to multiply real's... Either way - you going to end up with a LOT more CPU usage multiplying real's vs int - *unless* you need a real, stick to int :) A tip from me - I would load the source ints into a few arrays and then use threading to make it faster/use more cores. (This did spark off a talk about if Intel/AMD include a math co-pro with each core - if not, you really have to stick to threaded int64 - even more so if your CPUs are hyperthreaded, then you need int64 as a single core serves 2 HT cores - research the early days of HT for more info on this :) ) Cheers, Pieter On 17/08/2014 20:09, Cameron Hart wrote: I'm confused now as I'm pretty sure Delphi uses a standard format to represent float (the same format used anywhere else for that matter). In which case a float is essentially two int32 (or other int's depending on the scale of the float). Ie a single used two int16. One int represented the mantissa the other the exponent (in essence the decimal portion). Together they resulted in the floating point value. How would you describe this otherwise? *From:* delphi-boun...@listserver.123.net.nz [mailto: delphi-boun...@listserver.123.net.nz] *On Behalf Of *Jolyon Smith *Sent:* Sunday, 17 August 2014 12:54 p.m. *To:* NZ Borland Developers Group - Delphi List *Subject:* Re: [DUG] Int64 or floating point faster? That's curious. Who are they ? It doesn't sound like any floating point implementation I ever came across in Delphi (or anywhere else, for that matter). O.o On 17 August 2014 12:28, Pieter De Wit pie...@insync.za.net wrote: Hi Jolyon, From memory, they used 2 int32's to make a float - this could have been int16's - memory is very vague on this :) The one was used to represent the whole numbers and the other was to show the decimal numbers Cheers, Pieter On 17/08/2014 12:05, Jolyon Smith wrote: @Pieter - I don't understand what you mean when you say that float was int32.int32. For starters, float is an imprecise term. If you mean single then the entire value was always 32 bit in it's entirety. If you mean double then it was always 64 bit. What is this in32.int32 type of which you speak ? O.o On 17 August 2014 11:52, Jolyon Smith jsm...@deltics.co.nz wrote: I think there are too many variables involved to give an answer to this question without some of those variables being reduced to known values. e.g. what hardware ? what version of Delphi ? x64 target or x86 ? what precision of floating point ? Having said that, in a quick test knocked up in my Smoketest framework I found that Double comfortably outperforms Int64 when compiling for Win32 but that both Double and Int64 demonstrated improved performance when compiling for Win64 and that whilst Double still showed some advantage it was not as significant (and in some test runs the difference was negligible). If you are targeting FireMonkey you will have to bear in mind that the back-end compiler is different to the x86/x64 backend, so results obtained using the WinXX compilers will not necessarily be indicative of performance on the ARM or LLVM platforms. Conditions: - Delphi XE4 - Running in a 64-bit Win 7 VM - No testing was done for correctness of the results. On 16
Re: [DUG] Int64 or floating point faster?
Leigh, I'm not sure that this would be a reliable indicator of performance. Surely some opcodes are more expensive than others ? The relationship between opcodes and CPU cycles is not 1:1 afaik. On 18 August 2014 08:51, Leigh Wanstead leigh.wanst...@gmail.com wrote: Just one suggestion, why not look at assembler code in delphi to count the lines and add up the operands to get the cpu cycle total number? :-) My 2 nz cents Leigh ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] Int64 or floating point faster?
That would be odd since the IEEE single and double types were introduced in TP 5.0 and use of these was always dependent on having a math co-pro. Perhaps it was the real type ? I'm not sure how that was implemented 'under the hood' back in the day (although these days it's just a synonym for Double) although with a range of 1E-32 to 1E+38, an int32.int32 pair wouldn't have worked (and iirc it was a 48-bit type anyway, hence it lives [lived?] on as Real48 for people who really need/want it). I am interested to find out more about this elusive type as I'd be curious to see how it was implemented (I find this sort of thing fascinating). :) On 18 August 2014 10:50, Pieter De Wit pie...@insync.za.net wrote: Hey Jolyon, I was also under the impression it was a double int. I am damn sure it was documented like this for Pascal 5.5. Even if I can find it now, it doesn't matter since I think we have proved that Delphi uses the IEEE std :) Cheers, Pieter On 18/08/2014 08:47, Jolyon Smith wrote: @Cameron, you appear to be confused. Yes, Delphi uses a standard implementation of single and double types - the IEEE standards. But I don't know where you got the idea that this standard involves a naive pairing of two ints (of any size). Floating point types are *far* more complex than that. e.g. the internal representation of the value 1 in Double is not (0x0001).(0x) but (0x3fff).(0x) How would I describe it otherwise ? Why, the same way that IEEE 754 describes it of course. ;) http://en.wikipedia.org/wiki/Double-precision_floating-point_format Single is similarly not a naive pairing of two int16's. In fact, the closest I can even think that Delphi has to such a limited implementation for decimal values is the Curreny type, but even that isn't a pair of integers, rather a straightforward fixed point with a scalar of 10,000, yielding 4 fixed decimal places. Back to the OP... If you are using Delphi 7 and were thinking of using Single precision, then I strongly recommend that you do some tests with some representative sample data to establish the most efficient approach, but as a rule of thumb I would expect to find that Single precision would be more efficient than Double (and in the older.Win32 compilers I wouldn't be surprised if these had an even greater performance advantage over Int64). The question then is whether Single precision is adequate for your needs or if you need the additional capacity of Double. If you are inclined toward Int64 for some reason, be aware that there was a bug in the Delphi Int64 arithmetic in older Delphi versions. The 32-bit compiler doesn't use hardware op-codes for Int64 operations but emulates these in software, which is why Int64 performs less well than Double: I'm fairly sure this is the case even today (hence the comparative performance of Double and Int64 even in the XE4 32-bit compiler), but absolutely certain that it is the case with the older Delphi compilers. The details of the bug escape my memory right now, other than that it was a basic arithmetic error in the compiler emitted code (and something of an edge case), rather than a bug in an RTL function. i.e. not something that can be easily avoided. But I am sure your tests will show that Single or Double are more efficient anyway. On 17 August 2014 20:09, Cameron Hart cameron.h...@flowsoftware.co.nz wrote: I'm confused now as I'm pretty sure Delphi uses a standard format to represent float (the same format used anywhere else for that matter). In which case a float is essentially two int32 (or other int's depending on the scale of the float). Ie a single used two int16. One int represented the mantissa the other the exponent (in essence the decimal portion). Together they resulted in the floating point value. How would you describe this otherwise? *From:* delphi-boun...@listserver.123.net.nz [mailto: delphi-boun...@listserver.123.net.nz] *On Behalf Of *Jolyon Smith *Sent:* Sunday, 17 August 2014 12:54 p.m. *To:* NZ Borland Developers Group - Delphi List *Subject:* Re: [DUG] Int64 or floating point faster? That's curious. Who are they ? It doesn't sound like any floating point implementation I ever came across in Delphi (or anywhere else, for that matter). O.o On 17 August 2014 12:28, Pieter De Wit pie...@insync.za.net wrote: Hi Jolyon, From memory, they used 2 int32's to make a float - this could have been int16's - memory is very vague on this :) The one was used to represent the whole numbers and the other was to show the decimal numbers Cheers, Pieter On 17/08/2014 12:05, Jolyon Smith wrote: @Pieter - I don't understand what you mean when you say that float was int32.int32. For starters, float is an imprecise term. If you mean single then the entire value was always 32 bit in it's entirety. If you mean double then it was always 64 bit. What
Re: [DUG] Int64 or floating point faster?
That's curious. Who are they ? It doesn't sound like any floating point implementation I ever came across in Delphi (or anywhere else, for that matter). O.o On 17 August 2014 12:28, Pieter De Wit pie...@insync.za.net wrote: Hi Jolyon, From memory, they used 2 int32's to make a float - this could have been int16's - memory is very vague on this :) The one was used to represent the whole numbers and the other was to show the decimal numbers Cheers, Pieter On 17/08/2014 12:05, Jolyon Smith wrote: @Pieter - I don't understand what you mean when you say that float was int32.int32. For starters, float is an imprecise term. If you mean single then the entire value was always 32 bit in it's entirety. If you mean double then it was always 64 bit. What is this in32.int32 type of which you speak ? O.o On 17 August 2014 11:52, Jolyon Smith jsm...@deltics.co.nz wrote: I think there are too many variables involved to give an answer to this question without some of those variables being reduced to known values. e.g. what hardware ? what version of Delphi ? x64 target or x86 ? what precision of floating point ? Having said that, in a quick test knocked up in my Smoketest framework I found that Double comfortably outperforms Int64 when compiling for Win32 but that both Double and Int64 demonstrated improved performance when compiling for Win64 and that whilst Double still showed some advantage it was not as significant (and in some test runs the difference was negligible). If you are targeting FireMonkey you will have to bear in mind that the back-end compiler is different to the x86/x64 backend, so results obtained using the WinXX compilers will not necessarily be indicative of performance on the ARM or LLVM platforms. Conditions: - Delphi XE4 - Running in a 64-bit Win 7 VM - No testing was done for correctness of the results. On 16 August 2014 15:30, Ross Levis r...@stationplaylist.com wrote: Would I be correct that int64 multiplications would be faster than floating point in Delphi? My app needs to do several million. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] ListView - Scroll Event
Why not use the OnSelectItem() event and simply ignore the events where the Selected parameter is FALSE ? The only possible complication I foresee then is if you need to support the user selecting nothing (i.e. un-selecting any current selection and leaving the control with no selected item). On 28 July 2014 08:08, Eric A eaa...@hotmail.com wrote: Yes, could do that, with the understanding that it will result in some extra overhead due to fetching two lots of child records if I don't detect which is the last non-nil item notified. That's what I meant by messy. -- From: robo...@gmail.com Date: Sun, 27 Jul 2014 20:57:40 +0200 To: delphi@listserver.123.net.nz Subject: Re: [DUG] ListView - Scroll Event So you just need to use the OnChange event, and check the item is not nil. From memory I don't think you need to check whether item is different to previous item. Robo On Sun, Jul 27, 2014 at 8:52 PM, Eric A eaa...@hotmail.com wrote: Yes, multiple OnChange events are generated on the ListView control, for both mouse clicks and navigation key depressions, as follows: a) First mouse click or down arrow/PgDn key depression: - Item = new selection b) subsequent mouse clicks or down arrow/PgDn key depressions: - Item - current selection - Item= nil - Item = new selection Seems messy ... -- From: robo...@gmail.com Date: Sun, 27 Jul 2014 12:28:33 +0200 To: delphi@listserver.123.net.nz Subject: Re: [DUG] ListView - Scroll Event From memory, when a record changes, first an event gets fired where selected item is nil, then a second event gets fire where selected item is the new item. On Sun, Jul 27, 2014 at 11:07 AM, Eric A eaa...@hotmail.com wrote: (Delphi 7) I wish to detect the user selecting a row (item) in a ListView component to display child records for the item in another control. There is no OnScroll event for this control. I can use the OnClick event OK for a selection cia the mouse, but how do I detect when a user scrolls on to a record by using the arrow keys (or PgUp, PgDn or moving the scrollbar ? I have tried the using the OnChange event but it seems that there are two events generated for each movement by the arrow keys. Does anyone have a code snippet to accomplish this? Eric. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] Shellexecute question
Have you tried passing *SW_SHOWMINNOACTIVE instead of SW_MINIMIZED ?*
Caveat: The show flag parameter is merely passed to the application being
executed. What it chooses to do with that flag is it's own affair, but if
you're lucky, it will respect your wishes. If not, then you will have to
engage in a focus window arms race/lotto as already suggested. But Route
#1 would be to try the officially mandated mechanisms.
Good luck. :)
On 24 July 2014 19:46, russell russ...@belding.co.nz wrote:
Tyr this after spawning the other program.
SetForegroundWindow(forms.application.mainWindow.handle)
To give the main window of your program focus.
Perhaps modifications of this will take you to the window of the calling
program where you want the focus?
Russell
*From:* delphi-boun...@listserver.123.net.nz [mailto:
delphi-boun...@listserver.123.net.nz] *On Behalf Of *John Bird
*Sent:* Thursday, 24 July 2014 4:43 p.m.
*To:* NZ Borland Developers Group - Delphi List
*Subject:* [DUG] Shellexecute question
I have a program (Program A) that fires up another (program B) via
ShellExecute, if its not already running. However even though Program B is
started minimised, focus shifts away from Program A, which is a minor
nuisance.
Is there any way to stop this within Delphi? Or will I have to do
something like delve into the Windows API?
if ShellExecute(Application.Mainform.Handle, 'open', Pchar(aProgName),
PChar(aparaml), PChar(aDir), SW_SHOWMINIMIZED) = 32 then
ShowMessage('Start Minimised error:')
___
NZ Borland Developers Group - Delphi mailing list
Post: delphi@listserver.123.net.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with
Subject: unsubscribe
___
NZ Borland Developers Group - Delphi mailing list
Post: delphi@listserver.123.net.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with
Subject: unsubscribe
Re: [DUG] Shellexecute question
It shouldn't be puzzling. It is not the fact that the form is starting minimized, but the fact that Application.Run varies it's behaviour for the SW_SHOWMINNOACTIVE value CmdShow, a variation which does not occur for SW_MINIMIZED. But NOoo - do NOT add calls to ProcessMessages(). Do not add ANY calls to ProcessMessages(). And remove any you already have !!! :) ProcessMessages() calls make your application UI code re-entrant in highly unpredictable ways that can have you forever trying to find Heisenbugs, especially in a case like this where a user is likely to click on your launched app icon to see if it has woken up yet. Do blocking work on a background thread, allow the UI to continue to respond on the main thread, and provide whatever feedback to the UI relating to the progress of the background thread via properly marshalled, thread safe mechanisms. You will get more sleep that way. :) On 25 July 2014 12:43, John Bird johnkb...@paradise.net.nz wrote: It looks like the code in D2007 Application.Run is the later one. I would like to solve this at some stage out of curiosity so will return. The SW_SHOWMINIMIZED works as expected which is a puzzle. Usual story however, this is not on the list of urgent things to get working so it has to be put aside for now. Its a good point you make about where to put startup code – my rule of thumb has generally been initialising non component stuff can be done in the form create, but I tend to put anything initialising component stuff on the form show event, and this is where much of it is – there is a bit of setting things visible or not depending on what properties are set and I don’t think this can generally be done before the Show event. This Program B does this general initialisation and then starts a timer which then fires of the rest of the startup code which is long running. Some of the long running code takes 20-40 seconds to run (calculations) and it doesn’t respond to minimising/maximising while that is happening which is another minor issue – I may need to put some extra processmessages calls in there eventually. This relates to a previous question – the long running calculation sets up some quite large arrays and I tried saving/reading them in from disk to bypass the calculations but it produced a stack overflow. I am presuming that this is not from the code, as Russell’s code to save and load arrays to disk ran standalone, but due to the program using a larger amount of memory. Another investigation for later on the list of priorities! *From:* Jolyon Smith jsm...@deltics.co.nz *Sent:* Friday, July 25, 2014 7:49 AM *To:* NZ Borland Developers Group - Delphi List delphi@listserver.123.net.nz *Subject:* Re: [DUG] Shellexecute question If the other Delphi application isn't correctly responding to *SW_SHOWMINNOACTIVE* then the problem is in the *TApplicaiton* code of the version of Delphi involved. The fact that your FormShow event isn't firing suggests that it's an older version of Delphi involved, since an inspection of the *TApplication.Run* method reveals how this behaviour (or lack of) would eventuate case CmdShow of *SW_SHOWMINNOACTIVE: FMainForm.FWindowState := wsMinimized;* SW_SHOWMAXIMIZED: MainForm.WindowState := wsMaximized; end; if FShowMainForm then *if FMainForm.FWindowState = wsMinimized then* * Minimize else* FMainForm.Visible := True; The internal state is forced to *wsMinimize, *bypassing normal property setters, resulting in the show code simply calling the *Minimize* method on the main form, rather than making the form visible, which is why the FormShow even isn't fired. The form isn't shown! i.e. the *FormShow* event will eventually fire only when the user first activates the application and the window becomes shown. You could argue that this is desirable behaviour, but doesn't suit your purposes in this case. This was changed in later versions of Delphi. The above code is from D7. The version below from XE4 (the only 2 versions I have available on this system): case CmdShow of *SW_SHOWMINNOACTIVE:* * begin* *FInitialMainFormState := wsMinimized;* *FMainForm.FWindowState := wsMinimized;* * end;* SW_SHOWMAXIMIZED: MainForm.WindowState := wsMaximized; end; if FShowMainForm then *if (FMainForm.FWindowState = wsMinimized) or (FInitialMainFormState = wsMinimized) then* *begin* * Minimize;* * if (FInitialMainFormState = wsMinimized) then* *FMainForm.Show;* end else FMainForm.Visible := True; Now it appears that the *Show* method of your main form should be called, though I haven't tested to see whether this is actually the case. But in theory, *SW_SHOWMINNOACTIVE* should work for you if you upgrade the target EXE to a more
Re: [DUG] Shellexecute question
This doesn't really establish anything other than what we already know... that it is incredibly difficult to reliably anticipate in one thread something that is happening in some other thread. Prog A launch Prog B In simplistic terms you now have two threads, let's call them Thread A and B (corresponding to each program, A and B). If Thread A now does something that might interfere with/be interefered with by something occuring on Thread B then if you want any sort of reliable behaviour there has to be some co-ordination between the threads. Anything else is built on an assumption or set of assumptions that may or may not be valid at any given time. In this case, if Thread A tries to SetForegroundWindow() because it believes that Thread B has stolen it, then it's attempt to steal it back is only going to succeed if the call to SetForegroundWindow() occurs AFTER Thread B has in fact stolen it. If Thread A reclaims the focus BEFORE Thread B has nicked it, then Trehad B is still going to end up stealing the focus. Thread A can build in an assumption that if it waits a certain amount of time then Thread B will probably have completed it's stealing activity, but this is still an assumption and is just as vulnerable to failure. On 25 July 2014 16:17, russell russ...@belding.co.nz wrote: *I also tried Russells suggestion about setting the foreground window and it don’t work for me (Windows 8.1)* I tested this earlier on W7 by starting another program, so my main program lost focus. My main program was triggering SetForegroundWindow(forms.application.mainWindow.handle) from a timer and it worked OK. That is, focus returned to my main program when the timer went off. Just now I ran bcdShellExecute(path toExcel); SetForegroundWindow(forms.application.mainWindow.handle); and focus was not returned to my main program, it stayed with Excel. As a guess I tried bcdShellExecute(path toExcel); Sleep(150); SetForegroundWindow(forms.application.mainWindow.handle); and focus was returned to my main program. We can each guess what this means about interrupting a starting program in W7. I tried a similar test on W8.1 and focus is not returned to my main program even using sleep(1250). R *From:* delphi-boun...@listserver.123.net.nz [mailto: delphi-boun...@listserver.123.net.nz] *On Behalf Of *John Bird *Sent:* Friday, 25 July 2014 12:22 a.m. *To:* NZ Borland Developers Group - Delphi List *Subject:* Re: [DUG] Shellexecute question Hey that should have been perfect, as I already was doing SW_SHOWMINIMIZED which works fine, and so does SW_SHOWNOACTIVE which also does what it should – start the other window but not change focus. However SW_SHOWMINNOACTIVE doesn’t work. Now the other program is a Delphi program of mine that does some initialisation in the Formshow event (turning on timers etc) and I am wondering if somehow the event doesn’t fire. The process starts, but nothing runs, looks asleep in Task Manager. Not worth messing around with, as its a minor issue. I toyed with using SW_SHOWINACTIVE and getting the program (Program B) to minimise itself on start, but that is just damned complicated and fiddly/fragile. It also seems prone to ending up with 2 icons on the task bar, as though multiple copies have started even if only one is running – (maybe due to the large amount of work it does on startup – it is unresponsive for a good while) . I also tried Russells suggestion about setting the foreground window and it don’t work for me (Windows 8.1) What I did in the end was go back to the SW_SHOWMINIMIZED and then after the ShellExecute (in Program A) I put a ShowMessage saying I had started the other program. Because this gives a modal clue that they have to click on to continue it will do the job of setting the focus back. And its a bit useful for them to be informed it has been started. *From:* Jolyon Smith jsm...@deltics.co.nz *Sent:* Thursday, July 24, 2014 8:21 PM *To:* Russell Belding russ...@belding.co.nz ; NZ Borland Developers Group - Delphi List delphi@listserver.123.net.nz *Subject:* Re: [DUG] Shellexecute question Have you tried passing *SW_SHOWMINNOACTIVE instead of SW_MINIMIZED ?* Caveat: The show flag parameter is merely passed to the application being executed. What it chooses to do with that flag is it's own affair, but if you're lucky, it will respect your wishes. If not, then you will have to engage in a focus window arms race/lotto as already suggested. But Route #1 would be to try the officially mandated mechanisms. Good luck. :) On 24 July 2014 19:46, russell russ...@belding.co.nz wrote: Tyr this after spawning the other program. SetForegroundWindow(forms.application.mainWindow.handle) To give the main window of your program focus. Perhaps modifications of this will take you to the window of the calling program where you want the focus? Russell *From:* delphi
Re: [DUG] Migrating to XE6 - Project Issues
The problem with that Colin is that there is no intrinsic mechanism in
Delphi to share a DPR between projects of different names. So if your
application DPR is in any way non-standard, then having different named
projects means having to keep the separate DPR's all in sync, which I
understand is the case in point.
This is particularly annoying when you realise that the XML in the dproj
files references the project source (DPR) explicitly, so there really is no
reason these days for the filename of the DPR and the filename of the DPROJ
to have to be consistent (unlike, for example, in days gone past when the
IDE had to infer various files associated with a project by coincident
filename stem).
On 21 July 2014 23:47, Colin Johnsun colin.a...@gmail.com wrote:
Wouldn't it be easier just to have one project called MyAppD2007.dproj and
another called MyAppDXE3.dproj?
Just rename the executable after compilation.
Regards,
Colin
On Monday, 21 July 2014, David Brennan dugda...@dbsolutions.co.nz wrote:
We wrestled with this problem for a while because we were using both 2007
and XE3. We also have quite a few projects which share sets of files and it
was a bit of a mission remembering to add new files to all applicable
projects.
In the end we wrote a small program to build DPRs and Dproj files from a
combination of the old dproj file, a custom DPR format (with our own
extension) and include files which were referenced within the custom DPR.
The program replaces the include file references in the custom DPR and then
outputs a proper DPR. Then with the Dproj it deletes the old file
references and builds new XML file records from the include files.
It would be nice if Delphi fully supported include files in the DPR
(tricky I know but still) or provided a built in method like what we do.
Cheers,
David.
*From:* delphi-boun...@listserver.123.net.nz [mailto:
delphi-boun...@listserver.123.net.nz] *On Behalf Of *Jolyon Smith
*Sent:* Monday, 21 July 2014 1:12 p.m.
*To:* NZ Borland Developers Group - Delphi List
*Subject:* Re: [DUG] Migrating to XE6 - Project Issues
ime sharing dpk's (or even dpr's) (or trying to) between versions can be
a recipe for headaches.
Have you considered using include files to achieve the sharing of the
meat of your dpk, whilst allowing the IDE to maintain different
versions for each IDE in the dpk files themselves (with attendant dproj
etc) ?
package MyPackage2007;
{$i mypackage.inc}
end.
package MyPackageXE6;
{$i mypackage.inc}
end.
The downside is that you lose some of the IDE support for working with
the content of your DPK/DPR, but if you are dependent on $ifdef's in this
area then you no doubt already find yourself having to steer well clear of
such IDE support anyway, since it has as tendency to clobber such things
(and if that's the case, it's worth nothing that the contents of your
include file(s) will be conveniently safe from any inadvertent meddling by
the IDE!).
On 21 July 2014 12:14, Rohit Gupta ro...@cfl.co.nz wrote:
Hi Joylon,
Its sorted now. It just does not like the old dproj file, it doesn't
like a cut down edited version, it doesnt like a blank one and it doesnt
like a missing one
I made a new dpk project and saved it and then copied everything from the
old dpk and it works. It seems like it wants some new xml lines in it or
ELSE..
The issue here is that we have to work concurrently on 2007 and XE6
versions with the same source (and a few ifdefs). So the last thing I want
is the various clauses - includes, requires, uses to be in a different
order. When its 50 to 100 of them, it makes a huge difference to source
comparison.
Rohit
On 21/07/2014 12:05 p.m., Jolyon Smith wrote:
It looks like perhaps the IDE is trying to be too clever and when it
doesn't find a current dproj is looking for a historical bdsproj to upgrade
from and not coping when there isn't one (it being inconceivable that there
would be anyone using an even older version of Delphi that predated the
bdsproj).
To avoid this, instead of deleting the dproj, try adding the packages
with the current dproj.
With the prior dproj intact, the IDE should identify that you are
upgrading and offer to save the old version with a different name (or offer
to save the new version with a different name, I forget which way round.
Though I have a niggly feeling that in the past I was frustrated by the
fact that it was the former, which imho is the least useful approach!)
You have versioning/backups though, so it shouldn't matter which
particular named variety of these files the IDE chooses to mess with. Once
you have an upgraded package/project, you Save As to get a file correctly
named for new version you need, and then restore your previous versions
from source control/backups. Right ? :)
hth
On 21 July 2014 11:28, Rohit Gupta ro...@cfl.co.nz wrote:
I am trying to migrate
Re: [DUG] Migrating to XE6 - Project Issues
It looks like perhaps the IDE is trying to be too clever and when it
doesn't find a current dproj is looking for a historical bdsproj to upgrade
from and not coping when there isn't one (it being inconceivable that there
would be anyone using an even older version of Delphi that predated the
bdsproj).
To avoid this, instead of deleting the dproj, try adding the packages with
the current dproj.
With the prior dproj intact, the IDE should identify that you are upgrading
and offer to save the old version with a different name (or offer to save
the new version with a different name, I forget which way round. Though I
have a niggly feeling that in the past I was frustrated by the fact that it
was the former, which imho is the least useful approach!)
You have versioning/backups though, so it shouldn't matter which particular
named variety of these files the IDE chooses to mess with. Once you have
an upgraded package/project, you Save As to get a file correctly named
for new version you need, and then restore your previous versions from
source control/backups. Right ? :)
hth
On 21 July 2014 11:28, Rohit Gupta ro...@cfl.co.nz wrote:
I am trying to migrate a group of projects (packages) from 2007 to
XE6.I deleted the dcus, drc and dproj files.
Even when I start from a blank project group and add the existing
project in I get
Unable to load project *.bdsproj
Of course it doesnt exist, only the dpk does. A dump of error details
follows. Incidentally I had the same issue last time migrating another
group to XE5. That I had to recreate brand new dpk file and the
stupid thing was identical to the original one...
Any clues anyone ?
[21CA67AE]{delphicoreide200.bpl}
BaseDelphiProject.TBaseDelphiProject.Create (Line 775,
BaseDelphiProject.pas + 51) + $2C
[223A563A]{delphide200.bpl}
DelphiProject.TDelphiProjectCreationTrait.OpenProject (Line 314,
DelphiProject.pas + 7) + $19
[2069F929]{coreide200.bpl} ProjectFileUtils.LoadProjectFile (Line 642,
ProjectFileUtils.pas + 29) + $34
[21D05BED]{delphicoreide200.bpl}
CommonPasReg.TLegacyModuleHandler.FileOpen (Line 482, CommonPasReg.pas
+ 38) + $D
[2086B468]{coreide200.bpl} DocModul.TFilterList.OpenFile (Line 807,
DocModul.pas + 36) + $0
[20870A8C]{coreide200.bpl} DocModul.ProjectOpenDialog (Line 3295,
DocModul.pas + 42) + $3E
[2061437B]{coreide200.bpl} ProjectMgr.TProjectManager.AddTarget (Line
449, ProjectMgr.pas + 2) + $7
[20613C54]{coreide200.bpl} ProjectMgr.TProjectManager.CommandHandler
(Line 272, ProjectMgr.pas + 5) + $A
[204A397B]{coreide200.bpl}
ContainerIntf.TIDEProjectManagerMenuObject.Execute (Line 862,
ContainerIntf.pas + 26) + $17
[204A559E]{coreide200.bpl} ContainerIntf.TProjectManagerMenuItem.Click
(Line 1110, ContainerIntf.pas + 18) + $22
[506289BC]{vcl200.bpl } Vcl.Menus.TMenu.DispatchCommand (Line 3436,
Vcl.Menus.pas + 5) + $4
[50629C2E]{vcl200.bpl } Vcl.Menus.TPopupList.WndProc (Line 4597,
Vcl.Menus.pas + 4) + $E
[50629B7D]{vcl200.bpl } Vcl.Menus.TPopupList.MainWndProc (Line 4572,
Vcl.Menus.pas + 2) + $5
[501766E4]{rtl200.bpl } System.Classes.StdWndProc (Line 17064,
System.Classes.pas + 6) + $1
[50644241]{vcl200.bpl } Vcl.Forms.TApplication.CancelHint (Line 11180,
Vcl.Forms.pas + 6) + $D
[50642EDF]{vcl200.bpl } Vcl.Forms.TApplication.ProcessMessage (Line
10351, Vcl.Forms.pas + 23) + $1
[50642F22]{vcl200.bpl } Vcl.Forms.TApplication.HandleMessage (Line
10381, Vcl.Forms.pas + 1) + $4
[50643255]{vcl200.bpl } Vcl.Forms.TApplication.Run (Line 10519,
Vcl.Forms.pas + 26) + $3
Rohit
___
NZ Borland Developers Group - Delphi mailing list
Post: delphi@listserver.123.net.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with
Subject: unsubscribe
___
NZ Borland Developers Group - Delphi mailing list
Post: delphi@listserver.123.net.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with
Subject: unsubscribe
Re: [DUG] Migrating to XE6 - Project Issues
ime sharing dpk's (or even dpr's) (or trying to) between versions can be a
recipe for headaches.
Have you considered using include files to achieve the sharing of the
meat of your dpk, whilst allowing the IDE to maintain different
versions for each IDE in the dpk files themselves (with attendant dproj
etc) ?
package MyPackage2007;
{$i mypackage.inc}
end.
package MyPackageXE6;
{$i mypackage.inc}
end.
The downside is that you lose some of the IDE support for working with the
content of your DPK/DPR, but if you are dependent on $ifdef's in this area
then you no doubt already find yourself having to steer well clear of such
IDE support anyway, since it has as tendency to clobber such things (and if
that's the case, it's worth nothing that the contents of your include
file(s) will be conveniently safe from any inadvertent meddling by the
IDE!).
On 21 July 2014 12:14, Rohit Gupta ro...@cfl.co.nz wrote:
Hi Joylon,
Its sorted now. It just does not like the old dproj file, it doesn't like
a cut down edited version, it doesnt like a blank one and it doesnt like a
missing one
I made a new dpk project and saved it and then copied everything from the
old dpk and it works. It seems like it wants some new xml lines in it or
ELSE..
The issue here is that we have to work concurrently on 2007 and XE6
versions with the same source (and a few ifdefs). So the last thing I want
is the various clauses - includes, requires, uses to be in a different
order. When its 50 to 100 of them, it makes a huge difference to source
comparison.
Rohit
On 21/07/2014 12:05 p.m., Jolyon Smith wrote:
It looks like perhaps the IDE is trying to be too clever and when it
doesn't find a current dproj is looking for a historical bdsproj to upgrade
from and not coping when there isn't one (it being inconceivable that there
would be anyone using an even older version of Delphi that predated the
bdsproj).
To avoid this, instead of deleting the dproj, try adding the packages
with the current dproj.
With the prior dproj intact, the IDE should identify that you are
upgrading and offer to save the old version with a different name (or offer
to save the new version with a different name, I forget which way round.
Though I have a niggly feeling that in the past I was frustrated by the
fact that it was the former, which imho is the least useful approach!)
You have versioning/backups though, so it shouldn't matter which
particular named variety of these files the IDE chooses to mess with. Once
you have an upgraded package/project, you Save As to get a file correctly
named for new version you need, and then restore your previous versions
from source control/backups. Right ? :)
hth
On 21 July 2014 11:28, Rohit Gupta ro...@cfl.co.nz wrote:
I am trying to migrate a group of projects (packages) from 2007 to
XE6.I deleted the dcus, drc and dproj files.
Even when I start from a blank project group and add the existing
project in I get
Unable to load project *.bdsproj
Of course it doesnt exist, only the dpk does. A dump of error details
follows. Incidentally I had the same issue last time migrating another
group to XE5. That I had to recreate brand new dpk file and the
stupid thing was identical to the original one...
Any clues anyone ?
[21CA67AE]{delphicoreide200.bpl}
BaseDelphiProject.TBaseDelphiProject.Create (Line 775,
BaseDelphiProject.pas + 51) + $2C
[223A563A]{delphide200.bpl}
DelphiProject.TDelphiProjectCreationTrait.OpenProject (Line 314,
DelphiProject.pas + 7) + $19
[2069F929]{coreide200.bpl} ProjectFileUtils.LoadProjectFile (Line 642,
ProjectFileUtils.pas + 29) + $34
[21D05BED]{delphicoreide200.bpl}
CommonPasReg.TLegacyModuleHandler.FileOpen (Line 482, CommonPasReg.pas
+ 38) + $D
[2086B468]{coreide200.bpl} DocModul.TFilterList.OpenFile (Line 807,
DocModul.pas + 36) + $0
[20870A8C]{coreide200.bpl} DocModul.ProjectOpenDialog (Line 3295,
DocModul.pas + 42) + $3E
[2061437B]{coreide200.bpl} ProjectMgr.TProjectManager.AddTarget (Line
449, ProjectMgr.pas + 2) + $7
[20613C54]{coreide200.bpl} ProjectMgr.TProjectManager.CommandHandler
(Line 272, ProjectMgr.pas + 5) + $A
[204A397B]{coreide200.bpl}
ContainerIntf.TIDEProjectManagerMenuObject.Execute (Line 862,
ContainerIntf.pas + 26) + $17
[204A559E]{coreide200.bpl} ContainerIntf.TProjectManagerMenuItem.Click
(Line 1110, ContainerIntf.pas + 18) + $22
[506289BC]{vcl200.bpl } Vcl.Menus.TMenu.DispatchCommand (Line 3436,
Vcl.Menus.pas + 5) + $4
[50629C2E]{vcl200.bpl } Vcl.Menus.TPopupList.WndProc (Line 4597,
Vcl.Menus.pas + 4) + $E
[50629B7D]{vcl200.bpl } Vcl.Menus.TPopupList.MainWndProc (Line 4572,
Vcl.Menus.pas + 2) + $5
[501766E4]{rtl200.bpl } System.Classes.StdWndProc (Line 17064,
System.Classes.pas + 6) + $1
[50644241]{vcl200.bpl } Vcl.Forms.TApplication.CancelHint (Line 11180,
Vcl.Forms.pas + 6) + $D
[50642EDF]{vcl200.bpl } Vcl.Forms.TApplication.ProcessMessage (Line
Re: [DUG] Opinion wanted - is the upgrade from XE5 to XE6 worthwhile
Yes Leigh, I was addressing the possible perception that might be misinterpreted from your posts, that Xamarin provides 100% single source/common code and that RemObjects offers 0%, when neither is the case. On 13 July 2014 14:04, Leigh Wanstead leigh.wanst...@gmail.com wrote: Hi Jolyon, Don't you think that 75% common code is a great success?[?] Regards Leigh On 11 July 2014 16:57, Jolyon Smith jsm...@deltics.co.nz wrote: You don't avoid this even with Xamarin - they themselves suggest you will likely achieve only 75% common code. Whether this is typical, or a best case, I don't know. And of course any code you write against platform API's is not portable. Despite what you appear to think, it is possible to create portable code using RemObjects as well. Any code that does not rely on platform services or UI etc can be written in a manner that makes it portable across all of those platforms. On 11 July 2014 16:49, Leigh Wanstead leigh.wanst...@gmail.com wrote: Hi Jolyon, Thanks for your input. But by using RemObjects, you cannot get benefits from writing code once for all platforms i.e. android, ios, windows 8 phone like Xamarin.Forms do. You have to write multiple sets of code for each platform which means maintenance nightmare and delay release etc. Regards Leigh On 11 July 2014 16:42, Jolyon Smith jsm...@deltics.co.nz wrote: Leigh, When it comes to gleaning insights from examples, you get far more benefit from a translation than from a blank sheet of paper. ;) And making a translation from Java to Pascal (or C# if using Xamarin) is really not that hard, or shouldn't be for anyone who is - or claims to be - a software developer. Certainly not one with ambitions to develop for multiple, disparate devices. imho. ;) On 11 July 2014 16:32, Leigh Wanstead leigh.wanst...@gmail.com wrote: Hi Jolyon, But you need a mental translation from java to delphi :-) Regards Leigh On 11 July 2014 16:17, Jolyon Smith jsm...@deltics.co.nz wrote: But Leigh, the point is that an Oxygene developer does not need *Oxygene specific* support. When I was developing my battery widget I was using the same resources that a Java Android developer would use, which are plentiful (ditto my excursions into Cocoa). As some sort of idea, you might look at # of tagged questions on StackOverflow as a (crude) metric: Android: 500,000+ iOS: 250,000+ Delphi: 27,000+ Xamarin: 3,400+ FireMonkey: 880+ Oxygene: 101+ Initially this does not look good for Oxygene. But a high proportion of those 750,000 Android and iOS questions will be just as helpful to an Oxygene developer (and Xamarin for that matter). Not so much for a FireMonkey developer. Of the three, a FireMonkey developer is the most on their own. As for availability of skills, RemObjects and Xamarin have similar advantages - both are (or in the case of Xamarin, can be) Visual Studio based so experience with the IDE isn't an issue. With Xamarin and Hydrogene, language skills aren't an issue now that you can call on the pool of C# skills. Framework skills ? Well, again we're talking about Android SDK and Cocoa (or .NET), not some proprietary cross platform framework (although there are elements of this with Xamarin I believe). Again, Delphi with FireMonkey romps home with the Rocking Horse Droppings award. ;) On 11 July 2014 15:51, Leigh Wanstead leigh.wanst...@gmail.com wrote: Hi Jolyon, Thanks for your reply. I think the issue with RemObjects Oxygene is developer community size. Delphi is already a minority compare to .net developer population. Then RemObjects Oxygene for android, ios? I think that as rare as hen's teeth :-) If a project has no developer to hire using a tech, what will happen? :-) Anyway, by doing RemObjects Oxygene, everything is same learning curve like native platform except change the language to be pascal. But you have far small community to ask questions and get answers. Answers are not ready for you on the internet, you have to wait someone to answer it first. I already feel that xamarin developer community is too small compare to asp.net mvc, desktop .net etc. Regards Leigh ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo
Re: [DUG] Xero private API (OAuth)
Simply changing all relevant declarations explicitly to ANSIChar / ANSIString in the Flow code should have addressed any Unicode issues (similarly knocking up a p.o.c in pre-Unicode version of Delphi would have determined if this were the issue). I would not rule out the possibility that Xero have changed something on their end which has broken the Flow code - it has happened in the past and as ever with OAuth you get no clues to go on as to what might be the problem. It doesn't help that unless things have changed since I was wrestling with it, the Xero documentation is not exactly a shining example of the art (and from a quick look, it doesn't appear to have changed at all since then). If that is the case then using their provided wrappers is likely the most reliable approach, if a little clunky. :) On 11 July 2014 12:06, Robert Martin r...@chreos.co.nz wrote: Hi Alister I have my OAuth stuff working! After literally days of trying to get OAuth going in Delphi I gave up. Instead I used the Xero provided framework for PHP and built a PHP interface between my Delphi app and it. So instead of doing; Delphi app - Build XML command - OAuth sign - Http to Xero - Response - Delphi app I now have Delphi app - Build XML command - My custom PHP script - PHP OAuth sign using Xero framework - Http to Xero - Response - My Custom PHP script - Delphi app. Works like a charm. obviously I have had to provide my own security between the Delphi app and my custom framework but that wasn't too difficult. I strogly suspect the issues I was having were related to Unicode Delphi and the non unicode code that I got from Cameron. It was just too hard to debug as I couldn't see what my output should be vs what it was. Cheers Rob On 11/07/2014 11:49 a.m., Alister Christie wrote: With regards to OAuth you could try using TMS Cloud Pack http://www.tmssoftware.com/site/cloudpack.asp. I've used it for connecting to TradeMe, although still required a bit of work. Alister. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4716 / Virus Database: 3986/7832 - Release Date: 07/10/14 ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] Opinion wanted - is the upgrade from XE5 to XE6 worthwhile
Leigh, the potential issue is specifically one of licensing in commercial applications that rely on Mono, not viability of the platform: https://xamarin.com/licensing Note that licensing of Mono is necessarily required. As I understand it, it is a potential issue only in some deployment situations, but the potential does exist - ignoring it won't make it go away. At the very least someone needs to understand the potential implications before they can decide whether it is relevant to them. As for the viability of Mono, some might say that Xamarin/Mono had better prospects on non-Microsoft platforms before MS got involved. I do have to wonder how it is in Microsoft's interests to attract and support developers for what are after all competitor platforms ? I can't help but recall that it was Microsoft, after all, that coined the phrase Embrace. Extend. Extinguish ? ;) On the technical front, the fact remains that a Xamarin app relies on Mono. Just as a FireMonkey app has the FireMonkey runtime bundled in with every app, every Xamarin app has a built-in copy of the Mono VM, which is why Hello World in those solutions require you to set your units of measurement to MBs. As developers we have become very used to VAST amounts of storage at our disposal. 1GB for an app ? Pah. Who cares ? Get a bigger HDD if you need one and stop complaining. :) But mobile devices are a different kettle of fish. User storage is often not freely expandable and if you are thinking of targeting wearables or the internet of things in the future, the amount of storage in future devices is likely going to be even more limited in those cases. Meanwhile, the production version of my battery widget for Android (developed using RemObjects Oxygene) weighs in at a hefty, eye-watering, SD card straining . 37 KB. And I wasn't even *trying* to save space when I wrote it. :) https://play.google.com/store/apps/details?id=nz.co.deltics.batterywidget Unfortunately it's impossible to compare with a FireMonkey version of the same thing since it's impossible to *create* such a thing using FireMonkey. ;) However, I believe it is possible with Xamarin, and it could be interesting to make that comparison one day. On 11 July 2014 14:42, Leigh Wanstead leigh.wanst...@gmail.com wrote: Hi Jolyon, What you said is not an issue related to Mono. Xamarin becomes a partner with Microsoft. http://xamarin.com/pr/xamarin-microsoft-partner .net developer has a better future on Mono than microsoft :-) Regards Leigh On 11 July 2014 13:59, Jolyon Smith jsm...@deltics.co.nz wrote: Xamarin relies on Mono, with potential licensing and runtime implications for commercial developers. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] Xero private API (OAuth)
Rob, no worries. The biggest problem I had with their documentation was the lack of fully worked examples, leaving far to much to guesswork/clairvoyance. And in some places their docs contained contradictory examples. You shouldn't have to figure out which 1 of N examples is actually the one you should be following! Grrr. :) On 11 July 2014 15:34, Robert Martin r...@chreos.co.nz wrote: Hi I really appreciated your help with this and I did consider building it in D2007 to test the unicode thing (as suggested), however I just couldn't justify spending any more time on it! While I am ranting about documentation... With regards to the Xero documentation, I didn't find the stuff I looked at too bad. However I do think if you are going to provide a PHP framework / class to access your services, you should at least include a basic example of how it is used. The web site had some calls but didn't show the class involved. I had to trace back through the class source code to find out what the calls were and what values I should pass. Kind of defeats the whole purpose of black box programming! Cheers Rob On 11/07/2014 2:06 p.m., Jolyon Smith wrote: Simply changing all relevant declarations explicitly to ANSIChar / ANSIString in the Flow code should have addressed any Unicode issues (similarly knocking up a p.o.c in pre-Unicode version of Delphi would have determined if this were the issue). I would not rule out the possibility that Xero have changed something on their end which has broken the Flow code - it has happened in the past and as ever with OAuth you get no clues to go on as to what might be the problem. It doesn't help that unless things have changed since I was wrestling with it, the Xero documentation is not exactly a shining example of the art (and from a quick look, it doesn't appear to have changed at all since then). If that is the case then using their provided wrappers is likely the most reliable approach, if a little clunky. :) On 11 July 2014 12:06, Robert Martin r...@chreos.co.nz wrote: Hi Alister I have my OAuth stuff working! After literally days of trying to get OAuth going in Delphi I gave up. Instead I used the Xero provided framework for PHP and built a PHP interface between my Delphi app and it. So instead of doing; Delphi app - Build XML command - OAuth sign - Http to Xero - Response - Delphi app I now have Delphi app - Build XML command - My custom PHP script - PHP OAuth sign using Xero framework - Http to Xero - Response - My Custom PHP script - Delphi app. Works like a charm. obviously I have had to provide my own security between the Delphi app and my custom framework but that wasn't too difficult. I strogly suspect the issues I was having were related to Unicode Delphi and the non unicode code that I got from Cameron. It was just too hard to debug as I couldn't see what my output should be vs what it was. Cheers Rob On 11/07/2014 11:49 a.m., Alister Christie wrote: With regards to OAuth you could try using TMS Cloud Pack http://www.tmssoftware.com/site/cloudpack.asp. I've used it for connecting to TradeMe, although still required a bit of work. Alister. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4716 / Virus Database: 3986/7832 - Release Date: 07/10/14 ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4716 / Virus Database: 3986/7832 - Release Date: 07/10/14 ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] Opinion wanted - is the upgrade from XE5 to XE6 worthwhile
But Leigh, the point is that an Oxygene developer does not need *Oxygene specific* support. When I was developing my battery widget I was using the same resources that a Java Android developer would use, which are plentiful (ditto my excursions into Cocoa). As some sort of idea, you might look at # of tagged questions on StackOverflow as a (crude) metric: Android: 500,000+ iOS: 250,000+ Delphi: 27,000+ Xamarin: 3,400+ FireMonkey: 880+ Oxygene: 101+ Initially this does not look good for Oxygene. But a high proportion of those 750,000 Android and iOS questions will be just as helpful to an Oxygene developer (and Xamarin for that matter). Not so much for a FireMonkey developer. Of the three, a FireMonkey developer is the most on their own. As for availability of skills, RemObjects and Xamarin have similar advantages - both are (or in the case of Xamarin, can be) Visual Studio based so experience with the IDE isn't an issue. With Xamarin and Hydrogene, language skills aren't an issue now that you can call on the pool of C# skills. Framework skills ? Well, again we're talking about Android SDK and Cocoa (or .NET), not some proprietary cross platform framework (although there are elements of this with Xamarin I believe). Again, Delphi with FireMonkey romps home with the Rocking Horse Droppings award. ;) On 11 July 2014 15:51, Leigh Wanstead leigh.wanst...@gmail.com wrote: Hi Jolyon, Thanks for your reply. I think the issue with RemObjects Oxygene is developer community size. Delphi is already a minority compare to .net developer population. Then RemObjects Oxygene for android, ios? I think that as rare as hen's teeth :-) If a project has no developer to hire using a tech, what will happen? :-) Anyway, by doing RemObjects Oxygene, everything is same learning curve like native platform except change the language to be pascal. But you have far small community to ask questions and get answers. Answers are not ready for you on the internet, you have to wait someone to answer it first. I already feel that xamarin developer community is too small compare to asp.net mvc, desktop .net etc. Regards Leigh ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] Opinion wanted - is the upgrade from XE5 to XE6 worthwhile
Leigh, When it comes to gleaning insights from examples, you get far more benefit from a translation than from a blank sheet of paper. ;) And making a translation from Java to Pascal (or C# if using Xamarin) is really not that hard, or shouldn't be for anyone who is - or claims to be - a software developer. Certainly not one with ambitions to develop for multiple, disparate devices. imho. ;) On 11 July 2014 16:32, Leigh Wanstead leigh.wanst...@gmail.com wrote: Hi Jolyon, But you need a mental translation from java to delphi :-) Regards Leigh On 11 July 2014 16:17, Jolyon Smith jsm...@deltics.co.nz wrote: But Leigh, the point is that an Oxygene developer does not need *Oxygene specific* support. When I was developing my battery widget I was using the same resources that a Java Android developer would use, which are plentiful (ditto my excursions into Cocoa). As some sort of idea, you might look at # of tagged questions on StackOverflow as a (crude) metric: Android: 500,000+ iOS: 250,000+ Delphi: 27,000+ Xamarin: 3,400+ FireMonkey: 880+ Oxygene: 101+ Initially this does not look good for Oxygene. But a high proportion of those 750,000 Android and iOS questions will be just as helpful to an Oxygene developer (and Xamarin for that matter). Not so much for a FireMonkey developer. Of the three, a FireMonkey developer is the most on their own. As for availability of skills, RemObjects and Xamarin have similar advantages - both are (or in the case of Xamarin, can be) Visual Studio based so experience with the IDE isn't an issue. With Xamarin and Hydrogene, language skills aren't an issue now that you can call on the pool of C# skills. Framework skills ? Well, again we're talking about Android SDK and Cocoa (or .NET), not some proprietary cross platform framework (although there are elements of this with Xamarin I believe). Again, Delphi with FireMonkey romps home with the Rocking Horse Droppings award. ;) On 11 July 2014 15:51, Leigh Wanstead leigh.wanst...@gmail.com wrote: Hi Jolyon, Thanks for your reply. I think the issue with RemObjects Oxygene is developer community size. Delphi is already a minority compare to .net developer population. Then RemObjects Oxygene for android, ios? I think that as rare as hen's teeth :-) If a project has no developer to hire using a tech, what will happen? :-) Anyway, by doing RemObjects Oxygene, everything is same learning curve like native platform except change the language to be pascal. But you have far small community to ask questions and get answers. Answers are not ready for you on the internet, you have to wait someone to answer it first. I already feel that xamarin developer community is too small compare to asp.net mvc, desktop .net etc. Regards Leigh ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] Opinion wanted - is the upgrade from XE5 to XE6 worthwhile
You don't avoid this even with Xamarin - they themselves suggest you will likely achieve only 75% common code. Whether this is typical, or a best case, I don't know. And of course any code you write against platform API's is not portable. Despite what you appear to think, it is possible to create portable code using RemObjects as well. Any code that does not rely on platform services or UI etc can be written in a manner that makes it portable across all of those platforms. On 11 July 2014 16:49, Leigh Wanstead leigh.wanst...@gmail.com wrote: Hi Jolyon, Thanks for your input. But by using RemObjects, you cannot get benefits from writing code once for all platforms i.e. android, ios, windows 8 phone like Xamarin.Forms do. You have to write multiple sets of code for each platform which means maintenance nightmare and delay release etc. Regards Leigh On 11 July 2014 16:42, Jolyon Smith jsm...@deltics.co.nz wrote: Leigh, When it comes to gleaning insights from examples, you get far more benefit from a translation than from a blank sheet of paper. ;) And making a translation from Java to Pascal (or C# if using Xamarin) is really not that hard, or shouldn't be for anyone who is - or claims to be - a software developer. Certainly not one with ambitions to develop for multiple, disparate devices. imho. ;) On 11 July 2014 16:32, Leigh Wanstead leigh.wanst...@gmail.com wrote: Hi Jolyon, But you need a mental translation from java to delphi :-) Regards Leigh On 11 July 2014 16:17, Jolyon Smith jsm...@deltics.co.nz wrote: But Leigh, the point is that an Oxygene developer does not need *Oxygene specific* support. When I was developing my battery widget I was using the same resources that a Java Android developer would use, which are plentiful (ditto my excursions into Cocoa). As some sort of idea, you might look at # of tagged questions on StackOverflow as a (crude) metric: Android: 500,000+ iOS: 250,000+ Delphi: 27,000+ Xamarin: 3,400+ FireMonkey: 880+ Oxygene: 101+ Initially this does not look good for Oxygene. But a high proportion of those 750,000 Android and iOS questions will be just as helpful to an Oxygene developer (and Xamarin for that matter). Not so much for a FireMonkey developer. Of the three, a FireMonkey developer is the most on their own. As for availability of skills, RemObjects and Xamarin have similar advantages - both are (or in the case of Xamarin, can be) Visual Studio based so experience with the IDE isn't an issue. With Xamarin and Hydrogene, language skills aren't an issue now that you can call on the pool of C# skills. Framework skills ? Well, again we're talking about Android SDK and Cocoa (or .NET), not some proprietary cross platform framework (although there are elements of this with Xamarin I believe). Again, Delphi with FireMonkey romps home with the Rocking Horse Droppings award. ;) On 11 July 2014 15:51, Leigh Wanstead leigh.wanst...@gmail.com wrote: Hi Jolyon, Thanks for your reply. I think the issue with RemObjects Oxygene is developer community size. Delphi is already a minority compare to .net developer population. Then RemObjects Oxygene for android, ios? I think that as rare as hen's teeth :-) If a project has no developer to hire using a tech, what will happen? :-) Anyway, by doing RemObjects Oxygene, everything is same learning curve like native platform except change the language to be pascal. But you have far small community to ask questions and get answers. Answers are not ready for you on the internet, you have to wait someone to answer it first. I already feel that xamarin developer community is too small compare to asp.net mvc, desktop .net etc. Regards Leigh ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland
Re: [DUG] RAD 2007 to what
I still maintain a Delphi museum: All versions of Delphi from 1.0 thru to XE5. The only one missing is Delphi 8 and 2005 (the .NOT [sic] releases). w.r.t donating unused versions, if the current version you use was licensed as an upgrade to an older version, the fact that you no longer use that older version doesn't alter the fact that your current licensed version is only licensed on the basis of the license for the older version so if you give up that original license, the validity of your upgrade licenses becomes doubtful. You can apply to transfer licenses, but it's far from straightforward. On 9 July 2014 22:40, John Bird johnkb...@paradise.net.nz wrote: As far as I understand, yes – back to about D2007 I think. I have more versions of Delphi than I can shake a stick at (XE2,XE5,XE6). Aside – its a pity there is not a way to donate an unused version to eg a student as part of the up and coming Delphi community. *From:* Robo robo...@gmail.com *Sent:* Wednesday, July 9, 2014 7:54 PM *To:* NZ Borland Developers Group - Delphi List delphi@listserver.123.net.nz *Subject:* Re: [DUG] RAD 2007 to what Does Embarcadero still offer old versions of Delphi when purchasing the new version? ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] Saving aray
I would look at using a memory mapped file (MMF). In this way, the memory for your array is backed by storage in a designated file so there is no need to explicitly, separately persist the contents of the memory to that file when you are done. You simply close the mapping. Similarly there is no need for separate, explicit subsequent loading of file contents into memory - simply re-instate the mapping and contents of the file are mapped directly into your address space. The only thing to be wary of when using this technique is if you have records in your data that contain references to other locations in the memory, i.e. pointers, since these pointers are not certain to be valid/correct when you re-map the file content. But in the case of a simple array of integers this shouldn't be an issue. On 7 July 2014 20:35, John Bird johnkb...@paradise.net.nz wrote: I have a program that builds a very large array (over 1,500,000) of integers, and the calculation to fill the array takes quite a while – around 40-50 secs. If there is a quick way to do it, I would save the array to disk if it was faster than recalculating it the next time. I am guessing that writing the elements to strings and using CSV etc would be quite slow, as it involves quite a lot of processing. I will run a test to see. Is there any really fast way to save such an array to disk? The numbers range between 0 and 256 if that helps. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] ocx import problem
...@chreos.co.nz wrote: Hi Jolyon Good suggestion :) I assumed it was installed as the main product / standalone app runs fine. I downloaded and installed the latest Java runtime but alas still no go. I have also tried registering the ocx with regsvr32 and that also fails. I have un installed and re install autovue but still no go. Not sure if it is Delphi or AutoVue Thanks Rob On 24/06/2014 12:34 p.m., Jolyon Smith wrote: Do you have the required Java Runtime Environment installed and configured ? I believe the AutoVue ActiveX control is merely a wrapper around the underlying Java based AutoVue implementation, so without the necessary Java scaffolding the ActiveX isn't going to stand up. On 24 June 2014 11:54, Robert Martin r...@chreos.co.nz wrote: Hi I have an activeX control for AutoVue (CAD software) I am trying to import into Delphi XE2. I can import the activeX and install it into a package however when I try to place the control on a form I get and 'External exception'. Subsequent attempts to add it generate 'ClassFactory cannot supply requested class'. I have done a search on that message and most results indicate an issue with installing an activeX or a bit versioning issue. I believe the version installed is 32Bit. How can I test the JvueAX.ocx file is installed correctly, is there an easy way to do this? Does anyone have any suggestions on how to resolve the issue? We desperately need to get this working !!! The version of AutoVue we are using is 20.2.2 (I believe the most recent). I installed it using the ISDK and DesktopDeployment installers. I can post the component wrapper if that would help. Thanks Rob ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4592 / Virus Database: 3972/7731 - Release Date: 06/23/14 ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4592 / Virus Database: 3972/7731 - Release Date: 06/23/14 ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4592 / Virus Database: 3972/7731 - Release Date: 06/23/14 ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4592 / Virus Database: 3972/7731 - Release Date: 06/23/14 ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] Work Wanted in Wellington
@ David : some good observations. I would also add that skill scarcity acts as a leveler of value. When there are very few developers of *any* ability, the average or even sub-average developer can command a high salary/hourly rate due to that scarcity, independent of their abilities or skills, increasing their value in the market relative to that of the above average/excellent developer who will likely be an excellent developer, regardless of technology. Maybe. Certainly sounds plausible. :) On 3 July 2014 10:53, Leigh Wanstead leigh.wanst...@gmail.com wrote: I think the issue in Auckland in general is an excellent developer cannot find salary more than NZ$120,000 a year. Have to switch to abap in sap to get that amounts of salary. On 3 July 2014 10:32, David Brennan dugda...@dbsolutions.co.nz wrote: I find that very interesting too. The difficult thing with software development is that differences in capabilities are heavily accentuated. So a good developer is several times better than an average developer while a below average developer is likely to make a negative contribution to the project (in that you would be better off replacing them with an empty seat). For reasonably complex programs the minimum bar can be higher such that anyone less than a great developer is going to be a mistake. Unfortunately statistics dictates that average and below average developer are rather more common than great programmers… Maybe you got lucky with great programmers in Switzerland and got unlucky with your choices in NZ? Cheers, David. *From:* delphi-boun...@listserver.123.net.nz [mailto: delphi-boun...@listserver.123.net.nz] *On Behalf Of *Stefan Mueller *Sent:* Thursday, 3 July 2014 10:07 a.m. *To:* 'NZ Borland Developers Group - Delphi List' *Subject:* Re: [DUG] Work Wanted in Wellington As a Swiss Delphi Developer living in New Zealand I find that interesting. Switzerland isn’t exactly at the top of my mind when I think about the “value for bucks” for outsourcing work to – not because you don’t get the quality, but because salaries there are almost twice what you would have to pay here. Kind regards, *Stefan Müller*, RD Manager *ORCL* *Toolbox Ltd.* Auckland, New Zealand P Please consider the environment before printing this email This message is intended for the adresse named above and may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone. *From:* delphi-boun...@listserver.123.net.nz [ mailto:delphi-boun...@listserver.123.net.nz delphi-boun...@listserver.123.net.nz] *On Behalf Of *Tony Blomfield *Sent:* Thursday, 3 July 2014 9:29 a.m. *To:* 'NZ Borland Developers Group - Delphi List' *Subject:* Re: [DUG] Work Wanted in Wellington Gary. If you would like to send the details to me I will have a chat with them. Unfortunately we have had such a bad run with Kiwi Developers we moved our RD over to Switzerland last year where we get much more cost effective results. Anyway, I’d like to assess the person myself to see if they are suitable. Kind regards. Tony Blomfield *From:* delphi-boun...@listserver.123.net.nz [ mailto:delphi-boun...@listserver.123.net.nz delphi-boun...@listserver.123.net.nz] *On Behalf Of *Gary T. Benner *Sent:* Wednesday, 2 July 2014 2:32 p.m. *To:* del...@delphi.org.nz *Subject:* [DUG] Work Wanted in Wellington HI All, This just passed in if anyone can help: *Permanent Developer available in Wellington.* *Experienced Senior Delphi Developer looking for a permanent role in or around Wellington. * *Open to remote work. Also open to learning a new language if needed. Experienced in picking up code from others and looking after legacy systems as well as new development.* *Also experienced as a Development Manager and Product Management.* Anyone with an opportunity can email me at g...@benner.co.nz and I'll pass it on. cheers Gary List Admin Gary Benner MNZCS ITCP Information Technology Certified Professional Onlearn Limited http://www.onlearn.co.nz - Online Learning Hosting Support, Training Content Development 123 Internet Limited http://www.123.net.nz - Managed Web Hosting, Virtualisation, High Availability Systems Cluster Technologies Semantic Limited http://www.semantic.co.nz - Software Development Systems Design, Online Education, e-Commerce Disaster Warning Systems Limited http://www.diwa.co.nz - Public Emergency Warning and Communication Systems *Mob:* 021 966 992 *DDI:* +64 7 543 1206 *Email:* g...@benner.co.nz *Skype:* garybenner Ref#: 41006 ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject:
Re: [DUG] Work Wanted in Wellington
As you say John, the measure of good is a complex issue and may even vary from project to project according to the needs of those projects. Technical proficiency (in any specific area) , mentoring skills or knowledge (OO or again, in whatever area) can all be gained as and when needed but may or may not be relevant to a particular project. Ultimately it comes down to a combination of knowledge and approach, and the fit in these areas that a developer has with the needs of any particular project. In my experience, the best developers are the curious and caring ones. By which I don't mean the ones that people raise an eyebrow to/at and who get all teary eyed at a soppy movie, but who - when faced with a problem or a challenge - seek first to fully understand it before rolling up their sleeves and cutting code. And when they do produce code, they care about the clarity and structure of it. Working code isn't good enough for such people, it must also have some aesthetic other quality. i.m.e more often than not, ugly code turns eventually out to be wrong code. I know when I'm on the right track to a solution because it not only works, but it makes a sort of obvious sense and has a certain elegance that cannot be simply designed in. But, as I say, it's a highly complex area and I don't think there is a simple check list of qualities that categorically identify a good developer. Which is perhaps why it is also difficult to determine the value of one, resulting in the tendency to place value on more easily measured qualities, such as scarcity, experience (as measured in years), etc etc On 3 July 2014 11:20, John Bird johnkb...@paradise.net.nz wrote: OK that begs a further discussion! What in your eyes makes a developer “good” as opposed to thinking they are good – specific qualities please of what the good qualities are. I am wondering if there are many opinions of what a “good” programmer is which might explain why some think they are good whilst others think they are not. What are the more objective measures? I have worked on numerous projects the last few years and seen a lot of different talents. Some that stick out in my experience are: - Technical proficiency – ie knowing already what is likely to be the best technology to use to tackle a new problem - OO depth. Is it innate or learned? How is it best learned? - Ability to mentor and guide others through existing code Curious to hear specifics from you as you have the reputation of a Delphi authority! *From:* Jeremy North jeremy.no...@gmail.com *Sent:* Thursday, July 3, 2014 10:23 AM *To:* NZ Borland Developers Group - Delphi List delphi@listserver.123.net.nz *Subject:* Re: [DUG] Work Wanted in Wellington I know here (Australia) we would happily pay decent salaries if we found Delphi developers that were actually good and didn't just *think* they were good. On Thu, Jul 3, 2014 at 8:06 AM, Stefan Mueller muell...@orcl-toolbox.com wrote: As a Swiss Delphi Developer living in New Zealand I find that interesting. Switzerland isn’t exactly at the top of my mind when I think about the “value for bucks” for outsourcing work to – not because you don’t get the quality, but because salaries there are almost twice what you would have to pay here. Kind regards, *Stefan Müller*, RD Manager *ORCL* *Toolbox Ltd.* Auckland, New Zealand P Please consider the environment before printing this email This message is intended for the adresse named above and may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone. *From:* delphi-boun...@listserver.123.net.nz [mailto: delphi-boun...@listserver.123.net.nz] *On Behalf Of *Tony Blomfield *Sent:* Thursday, 3 July 2014 9:29 a.m. *To:* 'NZ Borland Developers Group - Delphi List' *Subject:* Re: [DUG] Work Wanted in Wellington Gary. If you would like to send the details to me I will have a chat with them. Unfortunately we have had such a bad run with Kiwi Developers we moved our RD over to Switzerland last year where we get much more cost effective results. Anyway, I’d like to assess the person myself to see if they are suitable. Kind regards. Tony Blomfield *From:* delphi-boun...@listserver.123.net.nz [ mailto:delphi-boun...@listserver.123.net.nz delphi-boun...@listserver.123.net.nz] *On Behalf Of *Gary T. Benner *Sent:* Wednesday, 2 July 2014 2:32 p.m. *To:* del...@delphi.org.nz *Subject:* [DUG] Work Wanted in Wellington HI All, This just passed in if anyone can help: *Permanent Developer available in Wellington.* *Experienced Senior Delphi Developer looking for a permanent role in or around Wellington. * *Open to remote work. Also open to learning a new language if needed. Experienced in picking up code from others and looking after legacy systems as well as new
Re: [DUG] Work Wanted in Wellington
And Smoketest... http://www.deltics.co.nz/blog/posts/tag/smoketest ;) On 3 July 2014 11:49, Jeremy Coulter jscoul...@gmail.com wrote: There is also DunitX and we also use Delphi Mocks. But yes using 'AAA' in C# is nice. Jeremy On Thu, Jul 3, 2014 at 11:41 AM, Leigh Wanstead leigh.wanst...@gmail.com wrote: Hi Jeremy, I think Dunit in Delphi cannot compete with typemock in C# which can use AAA. i.e. change current time to suit the unit test :-) Regards Leigh On 3 July 2014 11:33, Jeremy Coulter jscoul...@gmail.com wrote: To follow on from John Bird's comments, I have been involved in technical interviews of potential employees many times and the biggest problem we find is we get a number of applicants who are RAD developers and struggle with code separation techniques and using unit test with DUnit etc. let alone ones who can't solve simple SQL problems! Thats not to say RAD developers can't become developers who can learn how to do code separation unit tests. Its just a change in mind set. Jeremy On Thu, Jul 3, 2014 at 11:20 AM, John Bird johnkb...@paradise.net.nz wrote: OK that begs a further discussion! What in your eyes makes a developer “good” as opposed to thinking they are good – specific qualities please of what the good qualities are. I am wondering if there are many opinions of what a “good” programmer is which might explain why some think they are good whilst others think they are not. What are the more objective measures? I have worked on numerous projects the last few years and seen a lot of different talents. Some that stick out in my experience are: - Technical proficiency – ie knowing already what is likely to be the best technology to use to tackle a new problem - OO depth. Is it innate or learned? How is it best learned? - Ability to mentor and guide others through existing code Curious to hear specifics from you as you have the reputation of a Delphi authority! *From:* Jeremy North jeremy.no...@gmail.com *Sent:* Thursday, July 3, 2014 10:23 AM *To:* NZ Borland Developers Group - Delphi List delphi@listserver.123.net.nz *Subject:* Re: [DUG] Work Wanted in Wellington I know here (Australia) we would happily pay decent salaries if we found Delphi developers that were actually good and didn't just *think* they were good. On Thu, Jul 3, 2014 at 8:06 AM, Stefan Mueller muell...@orcl-toolbox.com wrote: As a Swiss Delphi Developer living in New Zealand I find that interesting. Switzerland isn’t exactly at the top of my mind when I think about the “value for bucks” for outsourcing work to – not because you don’t get the quality, but because salaries there are almost twice what you would have to pay here. Kind regards, *Stefan Müller*, RD Manager *ORCL* *Toolbox Ltd.* Auckland, New Zealand P Please consider the environment before printing this email This message is intended for the adresse named above and may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone. *From:* delphi-boun...@listserver.123.net.nz [mailto: delphi-boun...@listserver.123.net.nz] *On Behalf Of *Tony Blomfield *Sent:* Thursday, 3 July 2014 9:29 a.m. *To:* 'NZ Borland Developers Group - Delphi List' *Subject:* Re: [DUG] Work Wanted in Wellington Gary. If you would like to send the details to me I will have a chat with them. Unfortunately we have had such a bad run with Kiwi Developers we moved our RD over to Switzerland last year where we get much more cost effective results. Anyway, I’d like to assess the person myself to see if they are suitable. Kind regards. Tony Blomfield *From:* delphi-boun...@listserver.123.net.nz [ mailto:delphi-boun...@listserver.123.net.nz delphi-boun...@listserver.123.net.nz] *On Behalf Of *Gary T. Benner *Sent:* Wednesday, 2 July 2014 2:32 p.m. *To:* del...@delphi.org.nz *Subject:* [DUG] Work Wanted in Wellington HI All, This just passed in if anyone can help: *Permanent Developer available in Wellington.* *Experienced Senior Delphi Developer looking for a permanent role in or around Wellington. * *Open to remote work. Also open to learning a new language if needed. Experienced in picking up code from others and looking after legacy systems as well as new development.* *Also experienced as a Development Manager and Product Management.* Anyone with an opportunity can email me at g...@benner.co.nz and I'll pass it on. cheers Gary List Admin Gary Benner MNZCS ITCP Information Technology Certified Professional Onlearn Limited http://www.onlearn.co.nz - Online Learning Hosting Support, Training Content Development 123 Internet Limited http://www.123.net.nz - Managed Web Hosting, Virtualisation, High Availability Systems Cluster Technologies Semantic Limited http://www.semantic.co.nz -
Re: [DUG] Work Wanted in Wellington
One possible problem with asking to look at old code is that this would often break confidentiality requirements with a previous employer/client. I also have to admit that when I read some (*SOME*!) of my old code it gives me the shivers. People can get better over time y'know. :) I think perhaps a better approach might be to ask someone what they *think* of the code they wrote in the past. On 3 July 2014 12:03, Leigh Wanstead leigh.wanst...@gmail.com wrote: To know if he/she is a good developer is very easy. Just read the code he/she wrote in the past. On 3 July 2014 11:51, Jolyon Smith jsm...@deltics.co.nz wrote: As you say John, the measure of good is a complex issue and may even vary from project to project according to the needs of those projects. Technical proficiency (in any specific area) , mentoring skills or knowledge (OO or again, in whatever area) can all be gained as and when needed but may or may not be relevant to a particular project. Ultimately it comes down to a combination of knowledge and approach, and the fit in these areas that a developer has with the needs of any particular project. In my experience, the best developers are the curious and caring ones. By which I don't mean the ones that people raise an eyebrow to/at and who get all teary eyed at a soppy movie, but who - when faced with a problem or a challenge - seek first to fully understand it before rolling up their sleeves and cutting code. And when they do produce code, they care about the clarity and structure of it. Working code isn't good enough for such people, it must also have some aesthetic other quality. i.m.e more often than not, ugly code turns eventually out to be wrong code. I know when I'm on the right track to a solution because it not only works, but it makes a sort of obvious sense and has a certain elegance that cannot be simply designed in. But, as I say, it's a highly complex area and I don't think there is a simple check list of qualities that categorically identify a good developer. Which is perhaps why it is also difficult to determine the value of one, resulting in the tendency to place value on more easily measured qualities, such as scarcity, experience (as measured in years), etc etc On 3 July 2014 11:20, John Bird johnkb...@paradise.net.nz wrote: OK that begs a further discussion! What in your eyes makes a developer “good” as opposed to thinking they are good – specific qualities please of what the good qualities are. I am wondering if there are many opinions of what a “good” programmer is which might explain why some think they are good whilst others think they are not. What are the more objective measures? I have worked on numerous projects the last few years and seen a lot of different talents. Some that stick out in my experience are: - Technical proficiency – ie knowing already what is likely to be the best technology to use to tackle a new problem - OO depth. Is it innate or learned? How is it best learned? - Ability to mentor and guide others through existing code Curious to hear specifics from you as you have the reputation of a Delphi authority! *From:* Jeremy North jeremy.no...@gmail.com *Sent:* Thursday, July 3, 2014 10:23 AM *To:* NZ Borland Developers Group - Delphi List delphi@listserver.123.net.nz *Subject:* Re: [DUG] Work Wanted in Wellington I know here (Australia) we would happily pay decent salaries if we found Delphi developers that were actually good and didn't just *think* they were good. On Thu, Jul 3, 2014 at 8:06 AM, Stefan Mueller muell...@orcl-toolbox.com wrote: As a Swiss Delphi Developer living in New Zealand I find that interesting. Switzerland isn’t exactly at the top of my mind when I think about the “value for bucks” for outsourcing work to – not because you don’t get the quality, but because salaries there are almost twice what you would have to pay here. Kind regards, *Stefan Müller*, RD Manager *ORCL* *Toolbox Ltd.* Auckland, New Zealand P Please consider the environment before printing this email This message is intended for the adresse named above and may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone. *From:* delphi-boun...@listserver.123.net.nz [mailto: delphi-boun...@listserver.123.net.nz] *On Behalf Of *Tony Blomfield *Sent:* Thursday, 3 July 2014 9:29 a.m. *To:* 'NZ Borland Developers Group - Delphi List' *Subject:* Re: [DUG] Work Wanted in Wellington Gary. If you would like to send the details to me I will have a chat with them. Unfortunately we have had such a bad run with Kiwi Developers we moved our RD over to Switzerland last year where we get much more cost effective results. Anyway, I’d like to assess the person myself to see if they are suitable. Kind regards
Re: [DUG] Work Wanted in Wellington
I'd say that if you already have sufficient doubt to trust them to honestly represent their own work then it doesn't really matter what the code looks like, whoever's code it may be. ;) On 3 July 2014 12:35, Jeremy North jeremy.no...@gmail.com wrote: Also how do you know they actually wrote it. On Thu, Jul 3, 2014 at 10:09 AM, Jolyon Smith jsm...@deltics.co.nz wrote: One possible problem with asking to look at old code is that this would often break confidentiality requirements with a previous employer/client. I also have to admit that when I read some (*SOME*!) of my old code it gives me the shivers. People can get better over time y'know. :) I think perhaps a better approach might be to ask someone what they *think* of the code they wrote in the past. On 3 July 2014 12:03, Leigh Wanstead leigh.wanst...@gmail.com wrote: To know if he/she is a good developer is very easy. Just read the code he/she wrote in the past. On 3 July 2014 11:51, Jolyon Smith jsm...@deltics.co.nz wrote: As you say John, the measure of good is a complex issue and may even vary from project to project according to the needs of those projects. Technical proficiency (in any specific area) , mentoring skills or knowledge (OO or again, in whatever area) can all be gained as and when needed but may or may not be relevant to a particular project. Ultimately it comes down to a combination of knowledge and approach, and the fit in these areas that a developer has with the needs of any particular project. In my experience, the best developers are the curious and caring ones. By which I don't mean the ones that people raise an eyebrow to/at and who get all teary eyed at a soppy movie, but who - when faced with a problem or a challenge - seek first to fully understand it before rolling up their sleeves and cutting code. And when they do produce code, they care about the clarity and structure of it. Working code isn't good enough for such people, it must also have some aesthetic other quality. i.m.e more often than not, ugly code turns eventually out to be wrong code. I know when I'm on the right track to a solution because it not only works, but it makes a sort of obvious sense and has a certain elegance that cannot be simply designed in. But, as I say, it's a highly complex area and I don't think there is a simple check list of qualities that categorically identify a good developer. Which is perhaps why it is also difficult to determine the value of one, resulting in the tendency to place value on more easily measured qualities, such as scarcity, experience (as measured in years), etc etc On 3 July 2014 11:20, John Bird johnkb...@paradise.net.nz wrote: OK that begs a further discussion! What in your eyes makes a developer “good” as opposed to thinking they are good – specific qualities please of what the good qualities are. I am wondering if there are many opinions of what a “good” programmer is which might explain why some think they are good whilst others think they are not. What are the more objective measures? I have worked on numerous projects the last few years and seen a lot of different talents. Some that stick out in my experience are: - Technical proficiency – ie knowing already what is likely to be the best technology to use to tackle a new problem - OO depth. Is it innate or learned? How is it best learned? - Ability to mentor and guide others through existing code Curious to hear specifics from you as you have the reputation of a Delphi authority! *From:* Jeremy North jeremy.no...@gmail.com *Sent:* Thursday, July 3, 2014 10:23 AM *To:* NZ Borland Developers Group - Delphi List delphi@listserver.123.net.nz *Subject:* Re: [DUG] Work Wanted in Wellington I know here (Australia) we would happily pay decent salaries if we found Delphi developers that were actually good and didn't just *think* they were good. On Thu, Jul 3, 2014 at 8:06 AM, Stefan Mueller muell...@orcl-toolbox.com wrote: As a Swiss Delphi Developer living in New Zealand I find that interesting. Switzerland isn’t exactly at the top of my mind when I think about the “value for bucks” for outsourcing work to – not because you don’t get the quality, but because salaries there are almost twice what you would have to pay here. Kind regards, *Stefan Müller*, RD Manager *ORCL* *Toolbox Ltd.* Auckland, New Zealand P Please consider the environment before printing this email This message is intended for the adresse named above and may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone. *From:* delphi-boun...@listserver.123.net.nz [mailto: delphi-boun...@listserver.123.net.nz] *On Behalf Of *Tony Blomfield *Sent:* Thursday, 3 July 2014 9:29 a.m. *To:* 'NZ Borland Developers Group - Delphi List' *Subject:* Re
Re: [DUG] Delphi Git
There is nothing particularly noteworthy about using Delphi with Git that isn't also applicable when using Delphi with any other version control system, such as keeping keeping DFM files in text form rather than binary, to facilitate diffíng etc etc. Other than that it is simply a question of the differences in how you use Git as opposed to those other systems (e.g. in establishing files or filetypes to be ignored for the purposes of versioning etc). I have been using a combination of TortoiseGit and (rarely) git command line for some time now, having previously had an SVN repo. TortoiseGit can be initially overwhelming as to my mind it provides far deeper reach into the overall Git functionality than TortoiseSVN does for SVN. This may also be because the distributed nature of Git itself makes for an intrinsically richer domain, which may initially appear more complex, though it really isn't. i.e. rather than simple checkout of working copies and commit (or revert) of changes, TortoiseGit also has to accommodate the Push/Pull semantics and remote repository references that DVCS entails, which a central repository system such as SVN does not. You may also have to get your head around concepts like bare repositories (a git repo which has no working copies. None of this is especially difficult, as long as you don't try to understand Git solely in terms of comparison to SVN. They are very different and in my experience it is best to understand and appreciate the differences rather than trying to smooth over them. Fortunately there are plenty of online resources and guides to help gain this understanding, none of which really related specifically to use with Delphi. The documentation on the git-scm site is a good place to start. http://git-scm.com/documentation One thing worth noting is that SVN and Git (and indeed TortoiseSVN and TortoiseGit) co-exist very happily so there is no problem in running a hybrid Git/SVN environment while you gain comfort with Git. -- Jolyon On 29 May 2014 09:39, Gary T. Benner g...@benner.co.nz wrote: HI All, Has anyone had experience with Delphi and Git? There appears to be a somewhat unsupported project called RAD Studio Version Insight, and there is also TortoiseGit which works like TortoseSVN by working as an extension to Windows Explorer. Some feedback on best practice and any horror stories as well to keep us on the right path. cheers Gary Gary Benner MNZCS ITCP Information Technology Certified Professional Onlearn Limited http://www.onlearn.co.nz - Online Learning Hosting Support, Training Content Development 123 Internet Limited http://www.123.net.nz - Managed Web Hosting, Virtualisation, High Availability Systems Cluster Technologies Semantic Limited http://www.semantic.co.nz - Software Development Systems Design, Online Education, e-Commerce Disaster Warning Systems Limited http://www.diwa.co.nz - Public Emergency Warning and Communication Systems *Mob:* 021 966 992 *DDI:* +64 7 543 1206 *Email:* g...@benner.co.nz *Skype:* garybenner Ref#: 41006 ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] Embarcadero emails
Careful. The last time I complained about this very thing (years ago - some things never change, let alone improve) I got attacked for attacking Embarcadero. Expecting merely competencey and adequacy somehow gets you a reputation for being a whinger. Not unique to, but for some reason a particularly noticeable problem in, the Delphi community. ;) The excuse I got last time (and the time before that and the time before that... ) was that Marketing use a different mailing list than the registered user list. i.e. the right hand making excuses for the left hand as if there were no central, co-ordinating function available or even imaginable. Anyway, semi-rant-echo response to rant over. :) On 12 May 2014 18:40, Jeremy Coulter jscoul...@gmail.com wrote: Is it just me or do other people get somewhat dismayed when you receive emails from Embarcadero telling you about in this case New features for RAD/Delphi Application Development and the whole thing is telling me about a product I already own!! Its a complete waist of resource and my time (having to read it). I don't normally moan, but it seems a bit.I hate to say it butincompetent This doesn't need to turn into a yeah I think Embarcadero are stupid because thing, but man, in my eyes, it does look good. my question is I am a registered user...how do you NOT know I am a registered user of the product ??!! Anywayrant over :-) ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] Embarcadero emails
competencey - LOL at my own awkwardly apposite typographical error. :) On 13 May 2014 08:44, Jolyon Smith jsm...@deltics.co.nz wrote: Careful. The last time I complained about this very thing (years ago - some things never change, let alone improve) I got attacked for attacking Embarcadero. Expecting merely competencey and adequacy somehow gets you a reputation for being a whinger. Not unique to, but for some reason a particularly noticeable problem in, the Delphi community. ;) The excuse I got last time (and the time before that and the time before that... ) was that Marketing use a different mailing list than the registered user list. i.e. the right hand making excuses for the left hand as if there were no central, co-ordinating function available or even imaginable. Anyway, semi-rant-echo response to rant over. :) On 12 May 2014 18:40, Jeremy Coulter jscoul...@gmail.com wrote: Is it just me or do other people get somewhat dismayed when you receive emails from Embarcadero telling you about in this case New features for RAD/Delphi Application Development and the whole thing is telling me about a product I already own!! Its a complete waist of resource and my time (having to read it). I don't normally moan, but it seems a bit.I hate to say it butincompetent This doesn't need to turn into a yeah I think Embarcadero are stupid because thing, but man, in my eyes, it does look good. my question is I am a registered user...how do you NOT know I am a registered user of the product ??!! Anywayrant over :-) ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] Auckland Event Details
Ooops, sorry Jeremy - that reply was for Ian. Sorry for that. :) On 5 May 2014 20:21, Jolyon Smith jsm...@deltics.co.nz wrote: Jeremy, an opinion isn't a guess, merely an opinion. You may disagree with my opinion, of course. I have no problem with that. But I am curious as to what appeal you think FireMonkey has to someone contemplating all of the available options for developing for the supported platforms. As an aside, I would like to say that I do not feel that observations regarding my employment at Flow or elsewhere are at all relevant and are wholly inappropriate for this forum. However, since Cameron has made a specific claim in this regard, I would also like to clarify that as far as I know and was told at the time, I was not demoted from my position at Flow. My position was made redundant. Coincidentally an exciting opportunity arose with another company at around that time which I chose to accept. I resigned from my redeployed position with Flow in February and am now enjoying significant success in that new and far more significant role. Though quite what that has to do with what I might think of FireMonkey... well, if anyone can explain that, I'm all ears.:) ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] Auckland Event Details
What makes less sense is the way that they added support for those platforms. You are right to highlight the manner in which they have managed to tick boxes. Unfortunately it is *purely* an exercise in ticking boxes. Far less useful as a solid basis for continuing to be able to *keep*those boxes ticked. Delphi was always a niche product. Despite the marketing, their cross-platform solution is *not* Delphi for iOS/OS X/Android (and it painfully clearly is not Delphi for .NET, let alone WinRT or WinPhone). It is Delphi for FireMonkey, with the ability to deploy to any platform that FireMonkey manages to cajole a semblance of support for within the constraints of what the approach allows. i.e. you cannot build true Android solutions using FireMonkey because the way that FireMonkey works rules out certain capabilities of that platform. Similarly your FireMonkey Android apps will not benefit from ART. Sure, your FireMonkey app is native code, but is also bogged down by the non-platform native frameworks required to make even Hello Worldpossible, so whilst true platform native apps gain all the benefits that that platform delivers, FireMonkey remains stuck in it's own world. i.e. FireMonkey created a niche within a niche. Having attracted the interest of Delphi developers to the platforms that FireMonkey ticks the boxes for, many of those developers will quickly realise the limits and look instead at the alternatives, at which point they realise just how far behind Delphi has fallen over the years while Embarcadero wasted their time on the Smoking Chimp. As for the renewed interest in developing the VCL, this can be seen as a return to core value, or it could be seen as a belated recognition that FireMonkey is not in fact the secure future for Delphi/Embarcadero that it was supposed to be, and worst of all, without any viable strategy for supporting the platform on which that core value rests - i.e. the latest and future versions of Windows - even that core value is now at risk. For myself, I now use a combination of RemObjects Elements and Xcode for most of my work. Delphi is now very much a legacy platform. On 5 May 2014 10:46, David Brennan dugda...@dbsolutions.co.nz wrote: It was a good seminar IMO. I understand why Embarcadero have decided to spend so much time adding support for OS-X, iOS and Android, at some point we may even take advantage of it. More importantly though I’m glad they seem to have realised that now they have ticked those boxes they need to return to address quality across the product. I just hope that XE7 will continue that trend so that the Delphi IDE and executables continue to improve in speed and robustness. I’m also hoping that XE7 will see a big push to make Code Insight bulletproof (or as bullet proof as such a thing can be, given that if you screw your syntax up completely midway through a big change it is always going to struggle, but it would be nice if it returned to fully operational once you tidy things up a bit!). Cheers, David. *From:* delphi-boun...@listserver.123.net.nz [mailto: delphi-boun...@listserver.123.net.nz] *On Behalf Of *Jeremy Coulter *Sent:* Monday, 5 May 2014 10:10 a.m. *To:* NZ Borland Developers Group - Delphi List *Subject:* Re: [DUG] Auckland Event Details Yeah let us know hen its done. We didnt attend the presentation for various reasons, although it would have be good, so am looking forward to hearing what Marco had to say. Jeremy On Mon, May 5, 2014 at 9:51 AM, Alister Christie alis...@salespartner.co.nz wrote: I managed to spend a number of hours with Marco after the presentation, and have about an hour and a quarter recorded, which I will make available after Marco has reviewed it. It was great talking with him, it seems that Embarcadero made a good choice appointing him Product Manager for Rad Studio. Alister Alister Christie Computers for People Ph: 04 471 1849 Fax: 04 471 1266 http://www.salespartner.co.nz Follow us on Twitter http://twitter.com/salespartner PO Box 13085 Johnsonville Wellington On Wed, Apr 30, 2014 at 8:43 AM, Gary Benner g...@benner.co.nz wrote: HI All, Sorry this is a little late but just got back from a trip overseas. To endorse Alister's comment, great opportunity to meet Marco. cheers Gary Please see below details for the RAD XE6 Launch. Please will you forward this email invitation to members of the NZDUD to register/attend the event. Date and Venue: Friday, 02 May: Auckland Venue: Rydges Auckland - 59 Federal Street Cnr Kingston Street, Auckland 1010, New Zealand Time: 8.30am Registrations, 9:00am – 12:00pm http://forms.embarcadero.com/AP14Q2NZDeveloperDirectLIVE The event will be hosted by Damien Bootsma with special guest-speaker, Marco Cantu, RAD Studio Product Manager, global luminary author of over a dozen books on Delphi. This event is not to be missed, so register NOW, as spaces are
Re: [DUG] Auckland Event Details
@David: Your prescription that the approach must support single source is arbitrary. Heck, not even Embarcadero achieved this goal completely satisfactorily, so by that criteria FireMonkey itself is a failure. RemObjects approach is the more robust one. Rather than trying to pretend that platform differences can be abstracted away or reduced to lowest common denominator (as if the various user communities of the various platforms were not themselves making their choices precisely because of those differences, in many cases), those differences should be embraced and the developers empowered to take full advantage of them in order to provide the best solutions possible for *each*platform, not limited to providing a solution that can be deployed on *all* platforms. What should Embarcadero have done ? Simple. Instead of tossing Prism into the long grass, they should have brought Elements into the fold. Kept Delphi + VCL as their Win32 solution with Elements as their .NET and mobile platforms offering. But, frankly, as an Elements user who has previously experienced Borland/Inprise/Codegear/Embarcadero's product management, development, marketing and pricing at first hand, I am actually *very* relieved that they didn't (and suspect that RemObjects themselves might have resisted any attempt to do so). ;) The very fact that an outfit such as RemObjects have both the technical nouse and capacity to deliver something like Elements whilst Embarcadero, with far more resources at their disposal, are left buying up other people's technologies and trying to create a marketing message around them whilst rushing out poor quality releases (XE6 Hotfix 1 was out before the ink had dried on the XE6 release EULA!) to keep the money mill churning, should tell you everything you need to know about Delphi's future. If RemObjects can do it, and if Embarcadero are everything that their supporters crack them up to be, then Embarcadero should have been able to deliver their own Elements, especially given that they would have been able to focus exclusively on a Pascal solution, if they so chose, without the added distraction of a C# front end. @Leigh Yes, Oxygene/Hydrogene (hereafter: Elements) when targetting Java, produces Java byte code. Just like the vast majority of Android code out there (with the exception of games - the one type of app that the NativeActivity support in Android was only ever intended for). Oh, and the FireMonkey apps. One thing this means is that unlike FireMonkey, your target platform is not confined only to Android and the Java environment provided there. For example, if you really wanted to, you could use Elements to create an Eclipse plug-in. Elements can produce Java code, hence Elements supports all Java based platforms using all of the capabilities that those Java platforms supports because - to all intents and purposes - when compiling for Java, Elements *is* Java. Just with a different language front-end. As such, yes, it runs at Java speed, just like all the other Java code on those Java based devices, Android or otherwise. But it does so without having to drag in a bloated runtime and a custom UI rendering engine (and that's incorporated into EVERY FireMonkey app, btw). Your apps take full advantage of the device capabilities. That includes, for example, ART, which is the Android technology that allows Java based Android apps to be installed as pre-compiled, native code binaries. Just like FireMonkey apps, but without the embedded bloatware, and with the ability to run on any Android device (that support ART, or indeed of course all the ones that don''t). But equally, when compiling for Cocoa, Elements is an LLVM compiler. All of the same advantages apply - you have complete, platform native access to the platform with all of the benefits that accrue. Whether that is Cocoa (OS X) or CocoaTouch (iOS). Similarly, Elements for .NET... any .NET based platform is available to you, be that Windows.NET, Windows RT or Windows Phone. How is the .NET support in FireMonkey these days, by the way ? ;) On 5 May 2014 12:59, russell russ...@belding.co.nz wrote: Always interesting to read strong opinions … even when presented as facts and focusing on a few topics. The analysis looks plausible. I cannot assess it well as I write for a niche community and RAD Studio serves me fairly well. Russell *From:* delphi-boun...@listserver.123.net.nz [mailto: delphi-boun...@listserver.123.net.nz] *On Behalf Of *Jolyon Smith *Sent:* Monday, 5 May 2014 11:13 a.m. *To:* NZ Borland Developers Group - Delphi List *Subject:* Re: [DUG] Auckland Event Details What makes less sense is the way that they added support for those platforms. You are right to highlight the manner in which they have managed to tick boxes. Unfortunately it is *purely* an exercise in ticking boxes. Far less useful as a solid basis for continuing to be able to *keep* those boxes ticked
Re: [DUG] Using Boolean (Char(1)) in Firebird
I don't think you can adopt a general rule for all boolean type conditions in data. In the two example fields you cite, for example, I can see that there is a potential difference in the nature of the booleans involved. ActiveRecord - looks like something that could change over time. A record that was active may become inactive and I further speculate that there will over time be far more inactive records than active ones. AccountTransactionType - looks like something that is fixed. The type of a transaction seems unlikely to change once that transaction has been recorded. You might call this a static boolean, as opposed to the more dynamic nature of the previous example. Of course, more specific domain knowledge may reveal these assumptions to be invalid, but you get the general idea the characteristics of a particular datum go beyond it's simple data type and those characteristics in turn determine the most appropriate implementation (which in turn will depend on whether the dominant context is OLTP or OLAP - i.e. efficiency of creating/modifying data vs efficiency of queries). In the case of static booleans for example, you might consider creating separate tables for records of different values in this field. For convenience of querying all records you can of course project a view which unions the two (or more) tables involved, with a derived, virtual column containing the discriminating field value. This also opens up the possibility that the most efficient indexes for rows of a certain type (i.e. now table) may well be different than those for the other. i.e. the way you work with Income transactions might benefit from different indexes than Expense transactions. On the other hand, the way you work with income and expense transactions may mean that you are better off having indexes operating over ALL transactions, regardless of Income/Expense type. See what I mean about the best way being dependent on far more than just the data type ? And there's still more to it than that... w.r.t index selectivity, I am not convinced that the 1 / # of distinct values metric is a particularly reliable measure. It surely assumes an even distribution of distinct values across the data set ? i.e. if you have 100,000 records and they have a column where 50,000 rows have one value and 50,000 have another, then yes, the efficiency and thus the utility of any index on that value is going to be negligible (but then, no better than having no index isn't actually *worse*, is it ? Although there will be some overhead introduced in maintaining the index, though I doubt this will itself be hugely significant). On the other hand, if only 1,000 of those 100,000 records have one value and the remaining 99,000 have another, AND if your application most often queries that table to select those in the smaller subset (the 1,000) then whilst an index may not be of any benefit for querying the 99,000, it surely will provide benefit for those queries that select the 1,000 (or from among them), a benefit which *might* be worth the overhead of maintaining that index even though it provides little/no benefit for the handful/minority of queries that work with the 99,000 records ? The bottom line is, there is no shortcut for properly understanding your data and the way your application(s) work(s) with that data for correctly tuning your database structure and metadata for optimal performance. :) On 30 March 2014 15:19, Steve Peacocke st...@peacocke.net wrote: Hi all, I'm playing around with a Firebird database and wanted to know from you DB experts out there how you handle booleans in a table. These could be as simple as ActiveRecord (Y/N) AccountTransactionType (I/E) - (Income or Expense) That last I would normally think would be Income (Y/N) so that would be a boolean too. My understanding is that this will never be indexed, even if you specifically add an index to it. So how do you handle it. There may be several boolean fields in a table definition. As these tables c an contain several hundred thousand records, this could potentially slow down any query to say total all records last 3 years where Active and Income - as the only index would then be on the date field, there is a possibility that this could potentially be a very slow query. I've heard of others creating another table to create, say, non-Avtive record ID's, but this one table could have several booleans, therefore creating several new tables (combining then into a single table with the field name would cause the same problem). Any thoughts? Steve Peacocke Mobile: +64 220 612-611 Linkedin Professional Profilehttp://nz.linkedin.com/pub/steve-peacocke/1/a06/489 ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to
Re: [DUG] Contact form page
+1 for a spambot.
The smoking gun for me is the fact that if it was a case of valid details
being munged by a Unicode or codepage issue then I would not expect this
to affect numeric digits (as in phone numbers) and I certainly wouldn't
expect the only piece of data to survive any munging to be the @ and
.com in the email address.
My guess is that if that field on the form were not labelled as Email
then this field would also have simply been filled with junk but the
spambot is doing a minimal amount of work to try to ensure that the junk
details pass basic validation (i.e. is a valid email address). It is
surprising that it isn't doing the same thing for a field labelled Phone
and filling it with a phone number (tho the correct format for this is
potentially geographically sensitive so may not have been considered worth
the effort), but in any case I doubt that spambots go through rigorous
functional requirements, design, i18N and testing before being deployed. :)
J
On 19 March 2014 20:10, John C j...@sunshinesoftware.co.nz wrote:
Hi all
I have this website with a contact page (in PHP html) where any person
can submit a request with their contact details which is emails to me after
clicking a submit button.
All works fine, however. So now and then I receive an email from this
website/page but details don't seem being filled in at page level but in
another way. This as the page does a submit validation check and the
submitted phone number is e.g. LbXwjLfDDTFkIuBkPP something my
validator doesn't allow for.
Also other details are like:
Name: Bjmpynut
Organisation: ahTKXyxtYnCdo
Position: Bjmpynut
Phone: LbXwjLfDDTFkIuBkPP
Email: gipnp...@uohrokgr.com
All looks very suspicious. Any clues how this could happen at all and how
to prevent this?
The webpage in question is at http://www.relacs.co.nz/ContactUs.php
The email creator resides in the post process of the page like:
if($_POST['Submit']==Submit)
{
$Name = $_POST['InputName'];
$Email = $_POST['InputEmail'];
$Phone =$_POST['InputPhone'];
$Company = $_POST['InputCompany'];
$Position = $_POST['InputPosition'];
$Subject = $_POST['Subject'];
$Comment = $_POST['InputComment'];
$body = Name: $Name\n\n;
$body.= Company: $Company\n\n;
$body.= Position: $Position\n\n;
$body.= Phone: $Phone\n\n;
$body.= Email: $Email\n\n;
$body.= Subject: $Subject\n\n;
$body.= Comment: $Comment;
$Receiver =
i...@relacs.co.nz ;
$send = mail($Receiver, Feedback website
- RELACS, $body, From: $Email);
$Msg = Thank you $Name for your feedback.
We will get back to you ASAP;
}
Thanks for any help and/or suggestions.
John Ch
___
NZ Borland Developers Group - Delphi mailing list
Post: delphi@listserver.123.net.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with
Subject: unsubscribe
___
NZ Borland Developers Group - Delphi mailing list
Post: delphi@listserver.123.net.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with
Subject: unsubscribe
Re: [DUG] Contact form page
True, although the sorts of people that develop spambots includes those who
just do it to see if they can. Although I rather flippantly said that
spambots don't go through a rigorous SDLC, this might be a first iteration
of a spambot that will evolve as it's author gains confidence, ability and
eventually decides what the bot will do for him/her.
The particular spambot involved might already be out there in a later
incarnation doing something more useful for it's author. I doubt that
the creators of these things are too concerned with going around cleaning
up their older, flawed attempts.
By definition, we aren't talking about people with any sense of
responsibility. :)
On 20 March 2014 08:52, Steve Peacocke st...@peacocke.net wrote:
I do ask though, that if this is SpamBot, where's the message?
Surely they want to sell you bigger body parts, boots, shares, the
Brooklyn Bridge, or get assistance for that 35 mill they have sitting in an
account.
Sending junk specifically designed to get past the email checker seems
pointless for a spambot.
Steve Peacocke
+64 220 612-611
On 20/03/2014, at 8:30 am, Jolyon Smith jsm...@deltics.co.nz wrote:
+1 for a spambot.
The smoking gun for me is the fact that if it was a case of valid
details being munged by a Unicode or codepage issue then I would not
expect this to affect numeric digits (as in phone numbers) and I certainly
wouldn't expect the only piece of data to survive any munging to be the @
and .com in the email address.
My guess is that if that field on the form were not labelled as Email
then this field would also have simply been filled with junk but the
spambot is doing a minimal amount of work to try to ensure that the junk
details pass basic validation (i.e. is a valid email address). It is
surprising that it isn't doing the same thing for a field labelled Phone
and filling it with a phone number (tho the correct format for this is
potentially geographically sensitive so may not have been considered worth
the effort), but in any case I doubt that spambots go through rigorous
functional requirements, design, i18N and testing before being deployed. :)
J
On 19 March 2014 20:10, John C j...@sunshinesoftware.co.nz wrote:
Hi all
I have this website with a contact page (in PHP html) where any person
can submit a request with their contact details which is emails to me after
clicking a submit button.
All works fine, however. So now and then I receive an email from this
website/page but details don't seem being filled in at page level but in
another way. This as the page does a submit validation check and the
submitted phone number is e.g. LbXwjLfDDTFkIuBkPP something my
validator doesn't allow for.
Also other details are like:
Name: Bjmpynut
Organisation: ahTKXyxtYnCdo
Position: Bjmpynut
Phone: LbXwjLfDDTFkIuBkPP
Email: gipnp...@uohrokgr.com
All looks very suspicious. Any clues how this could happen at all and how
to prevent this?
The webpage in question is at http://www.relacs.co.nz/ContactUs.php
The email creator resides in the post process of the page like:
if($_POST['Submit']==Submit)
{
$Name = $_POST['InputName'];
$Email = $_POST['InputEmail'];
$Phone =$_POST['InputPhone'];
$Company = $_POST['InputCompany'];
$Position = $_POST['InputPosition'];
$Subject = $_POST['Subject'];
$Comment = $_POST['InputComment'];
$body = Name: $Name\n\n;
$body.= Company: $Company\n\n;
$body.= Position: $Position\n\n;
$body.= Phone: $Phone\n\n;
$body.= Email: $Email\n\n;
$body.= Subject: $Subject\n\n;
$body.= Comment: $Comment;
$Receiver =
i...@relacs.co.nz ;
$send = mail($Receiver, Feedback website
- RELACS, $body, From: $Email);
$Msg = Thank you $Name for your
feedback. We will get back to you ASAP;
}
Thanks for any help and/or suggestions.
John Ch
___
NZ Borland Developers Group - Delphi mailing list
Post: delphi@listserver.123.net.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with
Subject: unsubscribe
___
NZ Borland Developers Group - Delphi mailing list
Post: delphi@listserver.123.net.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send
Re: [DUG] Contact form page
Looks like a classic spambot message to me: Just enough content that looks plausible enough to sneak through a weak spam filter with a link to entrap the unwary recipient. On 20 March 2014 12:25, John C j...@sunshinesoftware.co.nz wrote: Hi all Gary, I use the PHP GeoIPLocation Library see http://chir.ag/tech/download/geoiploc and created routine and an array to check against wether it will be granted access to my website at all. In case it is from a blocked country (as per my block-country array) the page shows under the header Under construction and doesn't show the menu, so no way he/she can read any pages.The other thing I have added, is that the submitted form reads the IP country and sends it in the email to me. In case of this weird email it happens to be sent from USA. Steve, the message/comment in this submitted form looks quite bizarre, it reads: As I mentioned this she said those that join the official exchange rate of 3% from the japanese leader told him to offer an explanation or resign as chairman of SAM., a href=\http://xn--jpn-qi4b3ah5gqi5isdc.com/\;#12458;#12531;#12521;#12452;#12531;#12459;#12472;#12494;#27604;#36611;/a, [url=\http://xn--jpn-qi4b3ah5gqi5isdc.com/\]#12458;#12531;#12521;#12452;#12531;#12459;#12472;#12494;#27604;#36611;[/url], http://xn--jpn-qi4b3ah5gqi5isdc.com/#12458;#12531;#12521;#12452;#12531;#12459;#12472;#12494;#27604;#36611;, nqdxut, Would this be work of a hacker? John Ch *From:* delphi-boun...@listserver.123.net.nz [mailto: delphi-boun...@listserver.123.net.nz] *On Behalf Of *Steve Peacocke *Sent:* Thursday, 20 March 2014 8:52 a.m. *To:* NZ Borland Developers Group - Delphi List *Subject:* Re: [DUG] Contact form page I do ask though, that if this is SpamBot, where's the message? Surely they want to sell you bigger body parts, boots, shares, the Brooklyn Bridge, or get assistance for that 35 mill they have sitting in an account. Sending junk specifically designed to get past the email checker seems pointless for a spambot. Steve Peacocke +64 220 612-611 ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] Strange Error in Android
It's a bug alright - in the CheckEncoding function in Xml.XMLDoc. I love the way the author of that function naively assumes that the complete encoding declaration consists of only the encoding attribute plus 12 characters. That's 9 characters for encoding= plus 2 for the attribute value quotes and an extra one for an assumed trailing space. It then chops out a chunk of the XML declaration to remove the encoding declaration, but due to the incorrect naive assumptions this results in an invalid XML declaration. e.g. if the original XML declaration was: ?xml version=1.0 encoding = UTF-8 ? Then it becomes: ?xml version=1.08 ? Sadly this isn't even a new bug. The exact same naive mistake exists even in Delphi 2006 (and possibly earlier, but I don't have an older version to check right now). I suspect that the problem stems from a misunderstanding of the formal specification of an attribute name/value pair in the XML specification which identifies it as: Name Eq AttrValue Implying at first glance that there is and can be no white-space around the Eq (=). Except that if you follow the link for the Eq entity, this is defined as S? = S? i.e. Eq means an equal sign optionally surrounded by any amount of white space The reason it doesn't occur if you load the XML via a file is that the code path for loading the XML varies according to whether it is loaded from a file, a stringlist, a simple string or a stream (which is a huge WTF in itself) and it appears to be only the simple string code path which performs this CheckEncoding() song and dance. To add to the complication, in Delphi 2006 (and probably all pre-Unicode versions) the code path for a String is different again for a WideString. With a String (ANSIString) being loaded via the stream mechanism, only a formally declared WideString (DOMString) triggers the problem in earlier versions pre-Unicode. Frankly, this code is a mess and it's a miracle that it hasn't caused problems and been fixed long before now. Jeremy Coulter wrote: ?xml version='1.0' encoding = 'UTF-8' ? ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] Strange Error in Android
CR, LF CR+LF - all are whitespace in XML unless in a CDATA but since the error is occurring before the parser has even dealt with the ?xml declaration CDATA sections are not likely to be in play here. If the Embarcadero parser on Android is broken by variations in whitespace I would think twice about trusting it with anything really complicated. You know, like actual XML. ;) Jeremy Coulter Wed, 4 Dec 2013 10:27 Thanks for the replies. I was away yesterday, but I THINK John might be on the right track. I will be checking it out and will report back.Jeremy ___NZ Borland Developers Group - Delphi mailing listPost: delphi@listserver.123.net.nzAdmin: http://delphi.org.nz/mailman/listinfo/delphiUnsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe Jolyon Smith Tue, 3 Dec 2013 10:50 Could you post the first line of the XML so we can see what it comprises of ? i.e. what XML declaration does the string contain which the parser is rejecting ? As a result of the DOM Vendor implementation model in Delphi, behaviour on Windows is no indication of reliability on Android, iOS or OS X (as you are finding). For Android it seems that the key to your problem is in XML.Internal.AdomCore_4_3.pas, specifically the EvaluateXmlOrTextDecl() method of TXmlInputSource but without knowing what declaration is being presented to this method it's impossible to say whether the problem lies here, in the process of assigning the string from the HTTP response to the XML document or with the content of the XML string itself. There is potential for many slips twixt this particular cup and lip. Robert Martin Tue, 3 Dec 2013 09:03 Hi Jeremy Never done any Delphi Android work but is it possible it is a character set issue? I am only using XE2 nut if I look at XMLDoc.LoadFromXML() (I don't have a LoadXMLData) it takes an AnsiString on at UTF16 delphi string. Thanks Rob On 2/12/2013 11:40 p.m., Jeremy Coulter wrote: ___NZ Borland Developers Group - Delphi mailing listPost: delphi@listserver.123.net.nzAdmin: http://delphi.org.nz/mailman/listinfo/delphiUnsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe Jeremy Coulter Mon, 2 Dec 2013 23:40 Hi All.I am Sending an HTTP request to a server that is returning some XML in an Android app.However, I get an unexpected result. I am using Indy and the idHTTP.get() function which returns either a string or populates a stream.I started out first by loading the results into a string variable, i.e. buffer:=isHTTP.get() which returns the data fine, BUT if I call LoadXMLData(buffer) - (LoadXmlData() is in Xml.XMLDoc.pas) which is a function I have used a number of time in Delphi in normal Windows apps and never had a problem – that wasn’t something I did JHowever, if in the android app, I load the buffer variable into a string list then save that to file the call LoadXMLDocument() that takes a file name, it works fine !!Oh, the error I get is “ET_INVALID_XML_DECL line:-1” which indicates the XML is invalid but if I do a showmessage(buffer) its perfectly fine.I have tried loading the result into a stream and the reading it out into a string and I get the same error. I have tried removing the #13#10’s and STILL I get the error. If I write the XML to file first, no problem.I have tried using String and DOMStrings, but still the same error Anyone got any ideas? I shouldn’t have to write the xml to file then load it, that’s a bit of a pain. Thanks, Jeremy ___NZ Borland Developers Group - Delphi mailing listPost: delphi@listserver.123.net.nzAdmin: http://delphi.org.nz/mailman/listinfo/delphiUnsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] Strange Error in Android
Could you post the first line of the XML so we can see what it comprises of ? i.e. what XML declaration does the string contain which the parser is rejecting ? As a result of the DOM Vendor implementation model in Delphi, behaviour on Windows is no indication of reliability on Android, iOS or OS X (as you are finding). For Android it seems that the key to your problem is in XML.Internal.AdomCore_4_3.pas, specifically the EvaluateXmlOrTextDecl() method of TXmlInputSource but without knowing what declaration is being presented to this method it's impossible to say whether the problem lies here, in the process of assigning the string from the HTTP response to the XML document or with the content of the XML string itself. There is potential for many slips twixt this particular cup and lip. Robert Martin Tue, 3 Dec 2013 09:03 Hi Jeremy Never done any Delphi Android work but is it possible it is a character set issue? I am only using XE2 nut if I look at XMLDoc.LoadFromXML() (I don't have a LoadXMLData) it takes an AnsiString on at UTF16 delphi string. Thanks Rob On 2/12/2013 11:40 p.m., Jeremy Coulter wrote: ___NZ Borland Developers Group - Delphi mailing listPost: delphi@listserver.123.net.nzAdmin: http://delphi.org.nz/mailman/listinfo/delphiUnsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe Jeremy Coulter Mon, 2 Dec 2013 23:40 Hi All.I am Sending an HTTP request to a server that is returning some XML in an Android app.However, I get an unexpected result. I am using Indy and the idHTTP.get() function which returns either a string or populates a stream.I started out first by loading the results into a string variable, i.e. buffer:=isHTTP.get() which returns the data fine, BUT if I call LoadXMLData(buffer) - (LoadXmlData() is in Xml.XMLDoc.pas) which is a function I have used a number of time in Delphi in normal Windows apps and never had a problem that wasnt something I did JHowever, if in the android app, I load the buffer variable into a string list then save that to file the call LoadXMLDocument() that takes a file name, it works fine !!Oh, the error I get is ET_INVALID_XML_DECL line:-1 which indicates the XML is invalid but if I do a showmessage(buffer) its perfectly fine.I have tried loading the result into a stream and the reading it out into a string and I get the same error. I have tried removing the #13#10s and STILL I get the error. If I write the XML to file first, no problem.I have tried using String and DOMStrings, but still the same errorAnyone got any ideas? I shouldnt have to write the xml to file then load it, thats a bit of a pain.Thanks, Jeremy___NZ Borland Developers Group - Delphi mailing listPost: delphi@listserver.123.net.nzAdmin: http://delphi.org.nz/mailman/listinfo/delphiUnsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] IsClass access violation
It is perfectly possible for self to be NIL (the "Free" method relies on this fact). If SetModified is not virtual then you can happily call it with a NIL reference - it will only blow up when the code attempts to access any member data. i.e. if self were NIL then the AV would occur on the FModified := Modify line. Since you are not getting an AV on that line then the one thing you can be sure of is that self is not NIL. :) The read address in that access violation is very odd. If the object were previously valid but destroyed then I would expect a more "random" looking address. It also seems a curiously high address. Another possibility is that the SetModified() method has been called using a hard-typecast on some other value, not even necessarily a valid object reference. If so, then the procedure will be running in some sort of no-mans land where setting the memory that it thinks is "fModified" is acceptable but will do unpredictable damage with the wheels only coming off when calling up the class hierarchy to check the class type. e.g. in a form event: TCustomDetails(self).SetModified(FALSE) will compile and run but the line that sets fModified := Modify will actually overwrite some private member data of the TForm (assuming that TCustomDetails is not a form class) and if it doesn't blow up in your face right away something almost certainly will go "bang" at some point later. If that is what's going on, the fact that it is blowing up when attempting to call the IsClass method suggests that whatever has been type cast isn't even an object reference at all. It's a puzzle, that's for sure. Are there any other potential factors ? Runtime packages ? Threads ? fwiw - an ancestor class referencing a sub-class is unusual and often reflects a shortcoming in the OO model, but I wouldn't go so far as Todd as saying that it should NEVER be done. Without reviewing your class hierarchy it's impossible to say for sure. There may be good reasons for it and it is unlikely to be directly related to your problem in any case (he said, offering up a hostage to fortune!). :) Ross Levis Thu, 14 Nov 2013 15:51 Ive got a strange error occurring for just one user where this procedure is failing...procedure TCustomDetails.SetModified(Modify: Boolean);begin FModified := Modify; if Modify then begin if Self is TCategoryDetails then MainForm.CategoryChanged := True else MainForm.SpotChanged := True; end;end;TCategoryDetails and another class is inherited from TCustomDetails.Access violation at address 004047DC in module 'SPLCreator.exe'. Read of address FFDF.main thread ($87c):004047dc SPLCreator.exe System TObject.InheritsFrom00404742 SPLCreator.exe System @IsClass005dc6a6 SPLCreator.exe SPMain 3831 +4 TCustomDetails.SetModifiedWould this happen if Self was nil or invalid? I dont see how that could happen but just wondering how this can happen.Cheers,Ross.___NZ Borland Developers Group - Delphi mailing listPost: delphi@listserver.123.net.nzAdmin: http://delphi.org.nz/mailman/listinfo/delphiUnsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] Applicarion.ProcessMessage
If the DLL is also a Delphi DLL using VCL controls (as it almost certainly is) then your problem is that the VCL is simply not designed for multi-threading, in so far as all VCL control message processing code assumes that the processing is occurring in the main thread. This is precisely why Synchronize() was devised, to ensure that if you had to make calls to VCL component code (adding items to list boxes, getting/setting edit control text etc) that this all occurred safely on the VCL message thread and thus would be safely serialised with any message processing that the VCL control(s) involved might be dealing with. Even if the VCL were thread-safe, if the DLL is creating windows in the context of the VCL thread (which it presumably is) then you also have the problem that a thread cannot process messages for windows created in a different thread. Each thread that creates windows is responsible for handling the message queue that the system creates for that thread. Again, due to the nature of the VCL it is difficult - if not impossible - to create an application in Delphi that has multiple UI threads. You say that things become a problem when the DLL is doing something that takes several seconds. What is it that triggers the DLL to do this “something” ? If it is something that occurs “internally” within the DLL, triggered by some user interaction with the UI that the DLL is providing then you are out of luck I think. But if the long running process in the DLL is triggered by a call made by your application, and if that long running process itself does not involve the DLL’s UI, then you might be able to make that call to the DLL in a background thread. But you may have trouble even if that is possible, since it is highly unlikely that the DLL is taking care to be thread-safe itself (unless you have the source and can verify otherwise) so the results could be unpredictable. -- Jolyon Smith On Tuesday, 29 October 2013 at 17:02 , Ross Levis wrote: I’m wondering if any experts out there can help with this issue. I’m loading a 3rd party DLL which needs to have Windows messages sent to the DLL from my app for navigation purposes. It has been 10 years since I implemented this code which someone else gave me... procedure TEngine.ProcessMessage(var Msg: tagMSG; var Handled: Boolean); begin if not IsChild(Engine.Handle,Msg.hwnd) then try Handled := IsDialogMessage(GetParent(msg.hwnd),Msg); except Handled := False; end; end; Application.OnMessage := ProcessMessage; Without this the DLL GUI would not show which component had the focus, which was a problem for blind users using the tab key. The problem: When the DLL is doing something that takes several seconds, the function above appears to hang waiting for the DLL to finish, and this causes the main thread in my app to also hang. Is there any way around that, such as using a separate thread to process these messages? That would be somewhat out of my league. Cheers, Ross. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz (mailto:delphi@listserver.123.net.nz) Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz (mailto:delphi-requ...@listserver.123.net.nz) with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] Applicarion.ProcessMessage
If I have understood correctly and the DLL polling is occurring on the main thread then you don’t have the option of changing ProcessMessage once the message that triggers the DLL processing has been dispatched. As soon as that message is processed, causing the DLL to go off and do it’s thing, your VCL thread is already committed to servicing that DLL. -- Jolyon Smith On Tuesday, 29 October 2013 at 19:54 , Ross Levis wrote: It’s actually a C++ DLL, not VCL based. The DLL is polling for a window title to change in my app, and executes when it detects a change. What I thought of doing was set OnMessage to nil when I update the window title, and set it back to ProcessMessage on a timer shortly afterwards. I’m not sure if that will work or not and it will be impossible to test. The DLL is in fact updating a server via the internet, and only if there is an issue updating the server does the delay occur, and I can’t emulate that situation unfortunately. Could be worth a try and send it out to users. Ross. From: delphi-boun...@listserver.123.net.nz [mailto:delphi-boun...@listserver.123.net.nz] On Behalf Of Jolyon Smith Sent: Tuesday, 29 October 2013 7:36 p.m. To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Applicarion.ProcessMessage If the DLL is also a Delphi DLL using VCL controls (as it almost certainly is) then your problem is that the VCL is simply not designed for multi-threading, in so far as all VCL control message processing code assumes that the processing is occurring in the main thread. This is precisely why Synchronize() was devised, to ensure that if you had to make calls to VCL component code (adding items to list boxes, getting/setting edit control text etc) that this all occurred safely on the VCL message thread and thus would be safely serialised with any message processing that the VCL control(s) involved might be dealing with. Even if the VCL were thread-safe, if the DLL is creating windows in the context of the VCL thread (which it presumably is) then you also have the problem that a thread cannot process messages for windows created in a different thread. Each thread that creates windows is responsible for handling the message queue that the system creates for that thread. Again, due to the nature of the VCL it is difficult - if not impossible - to create an application in Delphi that has multiple UI threads. You say that things become a problem when the DLL is doing something that takes several seconds. What is it that triggers the DLL to do this “something” ? If it is something that occurs “internally” within the DLL, triggered by some user interaction with the UI that the DLL is providing then you are out of luck I think. But if the long running process in the DLL is triggered by a call made by your application, and if that long running process itself does not involve the DLL’s UI, then you might be able to make that call to the DLL in a background thread. But you may have trouble even if that is possible, since it is highly unlikely that the DLL is taking care to be thread-safe itself (unless you have the source and can verify otherwise) so the results could be unpredictable. -- Jolyon Smith On Tuesday, 29 October 2013 at 17:02 , Ross Levis wrote: I’m wondering if any experts out there can help with this issue. I’m loading a 3rd party DLL which needs to have Windows messages sent to the DLL from my app for navigation purposes. It has been 10 years since I implemented this code which someone else gave me... procedure TEngine.ProcessMessage(var Msg: tagMSG; var Handled: Boolean); begin if not IsChild(Engine.Handle,Msg.hwnd) then try Handled := IsDialogMessage(GetParent(msg.hwnd),Msg); except Handled := False; end; end; Application.OnMessage := ProcessMessage; Without this the DLL GUI would not show which component had the focus, which was a problem for blind users using the tab key. The problem: When the DLL is doing something that takes several seconds, the function above appears to hang waiting for the DLL to finish, and this causes the main thread in my app to also hang. Is there any way around that, such as using a separate thread to process these messages? That would be somewhat out of my league. Cheers, Ross. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123
Re: [DUG] Applicarion.ProcessMessage
It is both. :) The processing of any message on the message queue consumes the thread pumping that message queue. The DLL is consuming messages from your message queue but instead of responding to an appropriate message by spawning a separate thread to do the work it requires, it sounds like it is performing that work on the message thread. The net effect is that your message thread is not “stuck” or “hung” but merely very, very busy, doing the work that the DLL is asking of it. ProcessMessage isn’t “hanging”. it’s just doing what it’s been asked to do - processing the message. :) It’s no different than if the server request that the DLL is performing were instead part of an OnClick event on a button in your own app. The app would “freeze” until the server request has complete. The only difference here is that the “event handler” is somewhere in side that DLL. This is precisely why event response code should always be as efficient as possible. Ideally you would do all your application work in a separate thread and leave the main thread to be solely responsible for pumping the message queue. But even then, if you voluntarily offer up control of your message queue thread to an outside DLL, there is always the risk that they will “abuse the privilege, as appears to be happening in this case. -- Jolyon Smith ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] Application.ProcessMessage
Weird. It could be that the DLL is trying to do it's work on a thread but is using the same thread for it's actual work and for responding to messages or it may be creating separate threads but have synchronization that causes them to block each other. As I say, without source it's pretty much impossible to say for certain, though keeping an eye on the IDE thread-list window in the debugger might shed some light. Good luck. :) Ross Levis Wed, 30 Oct 2013 14:33 Except that I can disable the ProcessMessage code and the DLL still functions correctly. It was added only to resolve the component focus issue. Without it you couldn’t see which component on the GUI had the focus when tabbing. So I think it may be the DLL simply occupying the main thread when it starts its work, and I was wrong thinking the messages had something to do with it. Cheers. From: delphi-boun...@listserver.123.net.nz [mailto:delphi-boun...@listserver.123.net.nz] On Behalf Of Jolyon SmithSent: Wednesday, 30 October 2013 8:47 a.m.To: NZ Borland Developers Group - Delphi ListSubject: Re: [DUG] Applicarion.ProcessMessage It is both. :) The processing of any message on the message queue consumes the thread pumping that message queue. The DLL is consuming messages from your message queue but instead of responding to an appropriate message by spawning a separate thread to do the work it requires, it sounds like it is performing that work on the message thread. The net effect is that your message thread is not “stuck” or “hung” but merely very, very busy, doing the work that the DLL is asking of it. ProcessMessage isn’t “hanging”. it’s just doing what it’s been asked to do - processing the message. :) It’s no different than if the server request that the DLL is performing were instead part of an OnClick event on a button in your own app. The app would “freeze” until the server request has complete. The only difference here is that the “event handler” is somewhere in side that DLL. This is precisely why event response code should always be as efficient as possible. Ideally you would do all your application work in a separate thread and leave the main thread to be solely responsible for pumping the message queue. But even then, if you voluntarily offer up control of your message queue thread to an outside DLL, there is always the risk that they will “abuse" the privilege, as appears to be happening in this case. -- Jolyon Smith___NZ Borland Developers Group - Delphi mailing listPost: delphi@listserver.123.net.nzAdmin: http://delphi.org.nz/mailman/listinfo/delphiUnsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe Jolyon Smith Wed, 30 Oct 2013 08:46 It is both. :) The processing of any message on the message queue consumes the thread pumping that message queue.The DLL is consuming messages from your message queue but instead of responding to an appropriate message by spawning a separate thread to do the work it requires, it sounds like it is performing that work on the message thread. The net effect is that your message thread is not “stuck” or “hung” but merely very, very busy, doing the work that the DLL is asking of it.ProcessMessage isn’t “hanging”. it’s just doing what it’s been asked to do - processing the message. :)It’s no different than if the server request that the DLL is performing were instead part of an OnClick event on a button in your own app. The app would “freeze” until the server request has complete. The only difference here is that the “event handler” is somewhere in side that DLL.This is precisely why event response code should always be as efficient as possible. Ideally you would do all your application work in a separate thread and leave the main thread to be solely responsible for pumping the message queue. But even then, if you voluntarily offer up control of your message queue thread to an outside DLL, there is always the risk that they will “abuse" the privilege, as appears to be happening in this case.-- Jolyon Smith Ross Levis Wed, 30 Oct 2013 03:51 Ok. I thought it might be the ProcessMessage function that was hanging, but perhaps it is simply the main thread stuck in the DLL and nothing to do with the message processing. Thanks. From: delphi-boun...@listserver.123.net.nz [mailto:delphi-boun...@listserver.123.net.nz] On Behalf Of Jolyon SmithSent: Tuesday, 29 October 2013 8:41 p.m.To: NZ Borland Developers Group - Delphi ListSubject: Re: [DUG] Applicarion.ProcessMessage If I have understood correctly and the DLL polling is occurring on the main thread then you don’t have the option of changing ProcessMessage once the message that triggers the DLL processing has been dispatched. As soon as th
Re: [DUG] XE5 Android questions
All the information I've been able to find relating to LED control has been very involved, Android SDK level info. e.g. http://stackoverflow.com/questions/5503480/use-camera-flashlight-in-android Flashlight control is tied to the camera and (as I am finding out myself) interacting with the camera is a minefield of different device behaviors and idiosyncrasies, not just permissions. If there is some wrinkle with your device that FireMonkey does not take into account you may have to wait for Embarcadero to identify and fix it, or roll up your sleeves and try to get to grips with the JNI bridge to try to apply the techniques suggested by Android developers. I'm surprised though. I thought if the app worked on iOS you could just recompile it for Android ? ;) -- Jolyon Smith On 23 September 2013 11:57, John Bird johnkb...@paradise.net.nz (mailto:johnkb...@paradise.net.nz) wrote: Two XE5 mobile Android questions: 1 - tried the sample Flashlight app on a Galaxy Nexus, and everything works apart from it doesn't turn on the flash. (Have another non-Delphi flashlight app that does). What permissions are needed in project options - anything apart from camera ones which are already on? 2 - Tried connecting a Nexus 4 as well, and this one would not appear on the Project Android target list (for deployment) no matter what I tried. With the Galaxy Nexus it also doesn't appear until the dialog on the phone about Allow USB Debugging - the computer's RSA key fingerprint is xx:xx:xx:xx:xx..OK. Once that is OK'd it appears. But the Nexus 4 never shows that dialog. All the same developer options are turned on otherwise. Any ideas?___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] XE5 Android questions
On iOS you can specify a launch image for iOS to display while launching your app. So you can just recompile your iOS app and it will do the same on Android, right ? Yet again, the answer is No (a bit of a pattern starting to emerge, eh?). Android doesn't have any concept of a launch image as such. There are any number of ways of achieving something similar, none of which I have had to explore though. So far startup times haven't been a problem for me, using Oxygene. ;) Some ideas might be gleaned from this SO question but, as ever, most of the help and guidance is unlikely to be easily applied to a FireMonkey app: http://stackoverflow.com/questions/4394250/android-startup-image -- Jolyon Smith ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] XE5 Android questions
I think your best chance will be exploring the possibility of applying an application theme to the app and specifying a background image that the Android OS can then be responsible for drawing while your app loads. I don't know if this is even possible for an NDK app though (which is what a FireMonkey app is). Anything that relies on runtime code will have to wait for the FireMonkey runtime to complete it's initialization and it is quite possibly this initialization that is responsible for the startup delay in the first place. -- Jolyon Smith ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] [DUG-OFFTOPIC] Visual Studio Training
VisualStudio could be a good course to try on their 10 day free trial. :) -- Jolyon Smith On Thursday, 29 August 2013 at 12:59, Cheng Wei (FMI) wrote: Hi Colin, Yes, I'm looking into this now, another fellow developer recommended it to me earlier (thanks Xander Van der Merwe). Awesome stuff, thanks all. Cheers Cheng From: delphi-boun...@listserver.123.net.nz [mailto:delphi-boun...@listserver.123.net.nz] On Behalf Of Colin Johnsun Sent: Thursday, 29 August 2013 12:51 p.m. To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] [DUG-OFFTOPIC] Visual Studio Training Have you considered on-line course. I've just recently signed up for a yearly subscription to Pluralsight. They offer a massive on-line library of development courses. They have a section on Visual Studios but at the same time they offer courses for C#, Javascript and a whole slab of other related frameworks. A yearly subscription is cheaper than sending one person to do a 5 day course. http://pluralsight.com/training/Courses The Pluralsight courses are of a high quality and well worth a look in. Cheers, Colin On 29 August 2013 07:44, Cheng Wei (FMI) che...@fmi.co.nz (mailto:che...@fmi.co.nz) wrote: Good morning all, Can anyone recommend a good Visual Studio training provider please? What I'm looking for is a short term training course that will hopefully bring a team of Delphi developers (senior intermediate) up to speed in VS. Ideally based in Auckland. Thanks Cheng Wei Software Development Manager | FMI Group Tel: Mobile: Fax: Email: Web: 64 9 984 4917 64 21 410 776 64 9 984 4993 che...@fmi.co.nz (mailto:che...@fmi.co.nz) www.fmi.co.nz (http://www.fmi.co.nz/) Fairview Metal Industries Group 6 Timaru Place | Mt Wellington Auckland | NZ PO Box 51075 Pakuranga | Auckland 2140 | New Zealand ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz (mailto:delphi@listserver.123.net.nz) Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz (mailto:delphi-requ...@listserver.123.net.nz) with Subject: unsubscribe Attention: This mail and any attachments are for the use of the intended recipient only, and may contain information which is confidential and/or privileged. If you have received this email in error, please advise us by return email and immediately delete this email together with all attachments. The contents of this email may only be used, distributed or copied with the consent of the author. Fairview Metal Industries Ltd takes reasonable precautions to minimise the risk of this email containing any viruses but does not accept liability for any damage caused by software viruses and advises the recipient to carry out their own virus check on any attachments. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz (mailto:delphi@listserver.123.net.nz) Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz (mailto:delphi-requ...@listserver.123.net.nz) with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] Digital
Digital expertise in a Jon ad …. would seem fairly obvious, though possibly R18. In a JOB ad on the other hand [sic]… almost certainly refers to digital media, i.e. digital photos, video, audio etc, presumably to ensure they don't get applications from people who still have a bathroom that converts to a dark room and for whom video editing still involves scissors and glue, as opposed to a Mac with Photoshop and Adobe Premier :) -- Jolyon Smith On Thursday, 15 August 2013 at 14:02, Steve Peacocke wrote: Hi everyone, It's only amongst friends you can ask a really dumb question. I've finally got to the point of needing to know. I've noticed that the agencies are starting to advertise Digital expertise in Jon adds these days. I originally put this down to ignorance - everything in IT is digital. However this word has now hot to a sort of status where one must have proven Digital Experience. WTF are they talking about. Yes, I know I'm laying myself out for ridicule here but there seems to be no definition of this which is why I come to this trusted group now. Can someone please clarify this enigma fore and explain WTF they are talking about? Steve ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz (mailto:delphi@listserver.123.net.nz) Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz (mailto:delphi-requ...@listserver.123.net.nz) with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] Just In Time Debugger
Have you tried clicking OK and just going ahead and updating the setting as is suggested ? The only consequence of that is that when Windows would ordinarily launch Dr Watson or whatever other JIT debugger may have installed itself before, Windows will now try to use Delphi to debug any crashed process. But if I recall correctly, this eventuality only arises when an app crashes (when running normally, not within an IDE/under a debugger) and you get the Windows crash dump message asking if you want to debug the crashed process. If you never respond Yes to that inquiry, then it really doesn't matter what JIT debugger you have configured, and if you never do JIT debugging in such situations then it matters even less. At least, that's what I've always thought. Right or wrong. :) On 17 October 2012 10:12, John C j...@sunshinesoftware.co.nz wrote: Is there anybody who can help me? If you can, please do, much appreciated:) ** ** John ** ** *From:* delphi-boun...@listserver.123.net.nz [mailto: delphi-boun...@listserver.123.net.nz] *On Behalf Of *John C *Sent:* Tuesday, 16 October 2012 2:09 p.m. *To:* delphi@listserver.123.net.nz *Subject:* [DUG] Just In Time Debugger ** ** Hi all ** ** After a pc crash and a full reinstall of the lot, my D7 starts with the message: ** ** *Your just-in-time debugger is currently set to . In order for just-in-time debugger and distributed debugger features to work correctly, it needs to be changed to:' C:\Program Files\Delphi7SE\Bin\bordbg70.exe - aeargs %id %id' . Do you want to change these setting?* ** ** The file bordbg70.exe doesn't seem to exist. ** ** Can someone please help with what I can do to fix this? ** ** Thanks a lot John ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] Just In Time Debugger
Just in Time Debugging is an OS setting, not a Delphi setting. It seems that the IDE is trying to be helpful... something has turned on JIT Debugging on your system (it can be disabled) and the Delphi IDE is basically saying if you want to use me/my tools to do JIT debugging then I need to change those OS settings to point to me/my tools. If you aren't interested in JIT debugging then you could just disable it in the OS, or you could let Delphi go ahead and change the settings by clicking OK, or you could just keep ignoring the message and clicking Cancel each time. It won't affect the normal develop/debug capabilities of your IDE at all. At least that's my (somewhat hazy) recollection of the various options when this has occurred to me in years past. :) On 17 October 2012 12:20, John C j...@sunshinesoftware.co.nz wrote: Hi Colin Thanks for your reply. I'm not sure what your mean. I bought a copy of D7 Professional (a while ago obviously) what I used to use without any problems (until my pc crashed). You mentioned an unofficial lite version. Are you referring to my copy, or? So with my official/purchased D7 copy I should be able to run this without any just-in-time problems, or not? Thanks for any help. John -Original Message- From: delphi-boun...@listserver.123.net.nz [mailto:delphi-boun...@listserver.123.net.nz] On Behalf Of Colin Johnsun Sent: Wednesday, 17 October 2012 11:14 a.m. To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Just In Time Debugger I think your problem is that Borland never released a Delphi 7 SE (Second Edition). This is an unofficial lite version of Delphi 7. It probably wasn't included in this version. On 17 October 2012 08:12, John C j...@sunshinesoftware.co.nz wrote: Is there anybody who can help me? If you can, please do, much appreciated:) John From: delphi-boun...@listserver.123.net.nz [mailto:delphi-boun...@listserver.123.net.nz] On Behalf Of John C Sent: Tuesday, 16 October 2012 2:09 p.m. To: delphi@listserver.123.net.nz Subject: [DUG] Just In Time Debugger Hi all After a pc crash and a full reinstall of the lot, my D7 starts with the message: Your just-in-time debugger is currently set to . In order for just-in-time debugger and distributed debugger features to work correctly, it needs to be changed to:' C:\Program Files\Delphi7SE\Bin\bordbg70.exe - aeargs %id %id' . Do you want to change these setting? The file bordbg70.exe doesn't seem to exist. Can someone please help with what I can do to fix this? Thanks a lot John ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] Can anyone explain this one?
If adding an extra prolog fixes it then I would ask if the prolog is really there in the original xml to start with ? Some XML viewers will add a default prolog when viewing xml that doesn't contain any prolog. When viewing this xml in IE for example: root child / /root What IE actually shows is: ?xml version=1.0? -root child/ /root I am sure I have seen similar behaviour in other xml viewers. I find this an increasingly prevalent problem, with computer software trying to be too helpful; especially irksome in data viewers that introduce artefacts in the data being viewed that aren't actually present. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
Re: [DUG] Unicode help in D7
The problem with the it just works approach is that it only 'just works' 98% of the time. For a large number of people that will be close enough to 100% that they won't even notice the 2%, but if/when you do run into that 2% the fact that you haven't had to understand or adapt anything leaves you high and dry when it comes to understanding what's going wrong, how and how to fix it. All those oh-so-convenient automatic codepage conversions going on behind the scenes are great, except when they are either unnecessary and merely serve to exact a performance penalty you could do without, or actually cause problems because your code knows better than the compiler what it is doing and the compiler doesn't even take cues from your code to figure out what *it* should be doing that you think your code already *told* it to do so ends up doing what you don't expect but not telling you. Not to mention the wholly confusing plethora of string related RTL routines that we now have to live with. Need to convert a Unicode string to Uppercase ? That would be ANSIUppercase() then, obviously. Or ToUpper(). But to use ToUpper() you have to turn your back on pre-Unicode compilers since it is wholly new and lives in a newly introduced Character unit (why the contents of this unit couldn't be added to StrUtils is anybody's guess). So on the one hand, they went to all this effort to enable a seamless transition to Unicode, but then to write Unicode handling code that _actually_makes_sense you still have to make changes that amount to a NO-OP, but you have to go searching for areas where these changes might be desirable because the compiler will just continue compiling your old, non-Unicode sensible code anyway. A recipe for a great open an old project and recompile experience (i.e. demo's), at the expense of a head-numbing, wall-denting maintenance of existing code especially where needed to share between pre and post Unicode compilers experience. imho. ymmv. Your file streaming example is a good case in point: So I can recompile and my project is automatically Unicode throughout? 'It Just Works' - GREAT!! ... time passes ... Hey, how come my file output is still not Unicode ? What happened to 'it just works' ? (then there's db schemas that won't automatically unicodify on their own, but you code will just work regardless). The way they did the upgrade is convenient, but it's not consistent (there may be reasons for the inconsistencies but they are still inconsistencies). In fact I seem to recall having seen a stackoverflow question that involved this stream/stringlist encoding behaviour only earlier this week. [ disclosure: I have projects which deal with what most people would consider very low level string handling and characteristics, so my experience may be somewhat of a niche, but ime when the foundations are shaky the wobbles are very often felt throughout the building even if it's only the basement engineers that actually see the problems. Those on the top floor might even think the wobbles they occasionally feel are caused by the wind - :) ] On 4 October 2012 09:06, John Bird johnkb...@paradise.net.nz wrote: Thats one of the advantages of how they did the upgrade – if you use the same D7 code on XE2/3 and using standard methods of writing to files such as FileStream or TStringlist.savetofile then you will find that the strings in memory are Unicode, and saved to disk will be ANSI by default (you have to specify to save as Unicode as a format to get it). ie it is pretty close to “it just works”. Source code similarly remains ANSI until you start saving Unicode strings – in that case it automatically switches to unicode. ___ NZ Borland Developers Group - Delphi mailing list Post: delphi@listserver.123.net.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@listserver.123.net.nz with Subject: unsubscribe
