Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


ByteJuggler last won the day on March 26

ByteJuggler had the most liked content!

Community Reputation

32 Excellent

Technical Information

  • Delphi-Version
    Delphi 10.2 Tokyo

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Yes, IIRC you're correct. We had to (IIRC) use the .dproj file switch because for whatever reason (bug?) the compiler ignores the compiler directive but does respect the .dproj flag. (To add, in our case the "C++ output file generation" was also already off, however the compiler still emits/emitted this warning from one of the Synopse modules e.g. SynCommons.pas: "'ESynException.CreateLastOSError' with identical parameters will be inaccessible from C++" (and checking the module was being recompiled from scratch.) The only way that worked was the .dproj flag.
  2. You are of course correct. Thanks. I should've looked and thought harder before posting.
  3. I haven't, thanks. I'll try it Monday. (Seems a facepalm is incoming.) Thanks again. 🙂
  4. I have an irritating hint that I'm trying to get rid of ("warning W1036: Variable 'xxx' might not have been initialised" or with initialisation supplied and with project options disabling Assertions the same block of code emits "Value assigned to 'xxx' never used".) The root of the problem is that there's an initializing assignment which sets a variable to zero, followed by some logic, followed by an Assert that checks against the variable. The trouble happens because of the different "Assert" compiler option in force between RELEASE and DEBUG. Under DEBUG mode (for this particular project) "Assertions" are set to True, which means during compilation the Assert() line is not elided (removed), and the compiler therefore (correctly) demands (hints) that the variable being asserted against should be initialised with the first message if not done. Obviously adding an initialising line fixes the hint for DEBUG mode. However, if you then compile the same code in RELEASE mode (for which "Assertions" are set to False), then the Assert() line is elided during compilation. This means the variable initialization is now redundant and then the result is the compiler hint "Value assigned to 'xxx' never used", which (correctly) demands that the initialisation line should be removed. The question is essentially how to fix this so the code can compile successfully without hints both with DEBUG and with RELEASE settings, e.g. both with Assertions enabled and disabled. More concretely, the implication of the above is that to fix this, the initialization code must be conditional and somehow only be included only when assertions are enabled and omitted/removed otherwise, since the initialization is required only if the Assert() check is going to be done. Hence the title of this post and my question: Does anyone know of a compiler directive or something to detect whether assertions are active that will allow me to correctly condition the inclusion of the initialisation assignment so as to eliminate this hint both when Assertions are enabled and disabled?
  5. ByteJuggler

    Importing Excel2016 Type library into Delphi

  6. ByteJuggler

    Importing Excel2016 Type library into Delphi

    No it doesn't appear in that list. And I've by now managed to solve the whole problem, thanks! 🙂 (As far as I can tell 🙂 Oh, and sans designtime component icons but that's hardly important.) I (vaguely) remembered that the Delphi IDE only lists the servers/type libraries/components listed in the 32bit registry, and then managed to (re)locate this page, which states this and mentions that despite the IDE choking on 64-bit imports (as I've found), the TLIBIMP.EXE command line tool works fine. I hence successfully used it to import the Excel 2016 library and built and installed them into the IDE. For reference the command used to import the type library was: "C:\Program Files (x86)\Embarcadero\Studio\18.0\bin64\tlibimp.exe" -P "C:\Program Files\Microsoft Office\root\Office16\EXCEL.EXE" There's some fiddling required with the output files to make them match Embarcadero's conventions on their own imports (e.g. change from *_TLB.pas to *2016.pas in this instance). You also obviously need to create a Delphi component project to contain the wrapper components, which should be named dclOffice2016.dproj assuming you want to again match Emba's conventions. Inside the project options you should then also set the library suffix to match the product version that you're using and probably set a suitable description. (In my case Delphi Berlin which is product version 24 and suffix 240 as shown here.)
  7. Hi all, I'm trying to import the Excel 2016 type library into Delphi in the normal way via "Component"->"Import Component"->"Import ActiveX Control", click "Add", browse to "C:\Program Files\Microsoft Office\root\Office16\EXCEL.EXE" (list changes and has only the selected type lib loaded), "Next>>", filling in the fields as desired, and then clicking "Next >>", Selecting "Create Unit" and clicking "Finish" which then generates the below error ("Error loading type library Excel (Version 1.9).") https://i.vgy.me/DvFI6h.png I've also gone to the trouble of extracting the actual Type Library resource from Excel.exe using Visual Studio and importing that directly instead. (In the above process you select "Import a type library" instead of "Import ActiveX Control".) The result is essentially the same, e.g. the same error is generated. I should note that this is the 64-bit version of Office that is installed, and I'm aware that I've tried to directly import the server/tlb interfaces directly from the 64-bit Excel executable and that this might be part of the problem. I'm unsure whether this is legitimate or whether that's part of the problem, but if this is a problem I'm not sure what I should be importing instead? (Is there some kind of 32-bit wrapper library that I should be importing instead? If so what?) Thanks!
  8. ByteJuggler

    Creating a "pull request" for jvcl

    Ah, I'm sorry you feel a bit burned. 😞 Out of interest and for what it's worth: I had a look at what your patch is for, it seem to me from the StackOverflow discussion that the issue your patch works around is only present in a specific build of Windows and that's there's a fix for it [in Windows] since about a month ago? The maintainers need to respond and state whether this is the case, but it might be that they don't really want to fix OS bugs in the JVCL, an understandable position to take. (Aside, we maintain our own versions of some open source libraries as well as Delphi Source because of similar reasons, being that long ago issues remain unpatched in the official source whether due to lack of interest from the maintainers or lack of demonstrability/completeness/quality/testing or whatever of the issue and/or patch on our end. Sometimes just the way it goes. 🙂 )
  9. ByteJuggler

    Creating a "pull request" for jvcl

    Yes. One of the nice things of open source is that if a project isn't well maintained you can simply "run with it" yourself. Your fork may well eventually become the de-facto official version, if it should turn out that your version of the code in question ends up consistently better maintained and up to date than the original. To be clear: I'm not casting shade at the JCL/JVCL project per se here, just agreeing with your point that there's nothing wrong with maintaining your own fork and the consequences that may have, and that this is sometimes no bad thing. 🙂 Also as a minor digression, while this does obviously require some necessary conceptual branching understanding and how this is handled in git, it's reasonbly easy to create a new feature branch from a master branch even after the fact to fix the "problem" above with multiple pull requests. And it's also of course possible to just roll both sets of changes into a single new pull request. Given that there's some issues with the existing pull request in terms of supported versions (it seems, perhaps?), it seems this may be a fair course of action.
  10. ByteJuggler

    Creating a "pull request" for jvcl

    Especially with new contributors to open source (but also in general) it's usually advisable in the interests of friendly cooperation to exercise some patience and politeness and give contributors some friendly feedback about their pull requests if they should accidentally miss this or any other type of requirement that change requests should comply with (and to do so in the context where the pull request was submitted.) If the JCL/JVCL maintainers are not giving at least this feedback to people trying to contribute then that's rather a shame. 😞
  11. ByteJuggler

    Creating a "pull request" for jvcl

    Nice. Now nosy people like myself can also go have an, er, nosy around to see what you've done and even grab the change if I want it. 🙂
  12. ByteJuggler

    Creating a "pull request" for jvcl

    Without wanting to be polemical and for the sake of anyone else reading this thread: As written that doesn't make sense, I assume you must've meant to write: "You need to commit the change to the local repository, then push it to your remote fork, then create a "pull" request in github" against/from your remote fork.
  13. ByteJuggler

    Creating a "pull request" for jvcl

    Just to emphasise: Yes -- they must have somewhere to pull from that's accessible, which is kind of the point of github (So you're not too stupid to use git after all! )
  14. ByteJuggler

    Creating a "pull request" for jvcl

    Guys, while pulling updates from a remote repo is part of git (e.g. git pull from the command line for example), a "pull request" is not something intrinsically part of git, but something that github institutes, or that we agree between ourselves as developers. It literally is saying to someone else "Please {git} pull from me as I've got something you might want to review/use." It follows that in order for someone else to "pull" changes from you, that you must have some accessible place for them to pull from. Obviously users on the internet won't have access to your local repo on your developer PC, so they cannot pull from there. Nor would you normally be able to push to their repo (or their github repo) if that is where you originally pulled from (unless you're one of the project administrators/owners of course.) There therefore needs to some other repo, that must belong to you and is accessible so that someone else can pull from, that you can also first push to. (Just like there needs to be a shared SVN server, say, if you want another dev to get some changes you've made and are using subversion.) And this is where github comes in. It provides an easy to access place where you can fork and create your own remote repositories (from others) that are therefore just as easily accessible by others too. All that background is to help you understand the following: The normal process for working on github, if you want to contribute changes, is to 1.) Fork the repo of the project you want to contribute to in your github account. This creates a cheap remote repo (think "my own SVN server at github" if that helps) that belongs to you, than you can push to. 2.) Clone this fork (your own copy of this github repo) to your local PC. 3.) Do your work, commit locally. Once totally happy, git push, which obviously goes to your own remote repo (from the fork.) 4.) Now you're a few revisions ahead of the original repo, and you can then tell the original upstream repo maintainers that you'd like them to pull from your repo as you've got changes to fix some issue or whatever. In github, you do this by simply clicking "New Pull request" button in github. Hope that helps! Edit: By the by, if you've previously pulled from someone else's project directly, made some changes and now want to push this somewhere else, it's quite easy to fork the project "after the fact" and then tell git/update that "remote"/"upstream" is now else, to e.g "push" to your fork instead. (It's also possible to have multiple remotes if you want, but I digress...)
  15. Thanks, Correct yes. That's what I read/was referring to. And my apologies, I shouldn't have used "won't" in my post, should've been "can't". As it happens I see I've been prompted with an OS update/upgrade notice last night on said phone (which will upgrade to Android Pie) so hopefully the problem will be gone later today! 🙂