Your Rank: 32
While I understand the prudence of "always test in a VM first" I think users who pay £1000 + for a product are entitled to expect their purchase not to behave like a "trial" app. It certainly should not "break the system". There are still many people out there who run s/w on PCs without virtual machine technology (for example because they do not have a powerful / large memory device).
OK, so you have a test code that works. You have a "identical in principle" bit of code that doesn't work. Your "stupid question" has now become "how can I debug my code" - there are volumes and volumes (many very good) that aim to answer this question.
The next thing I might choose to try were I in your shoes is to temporarily add frmTarget to your big project and confirm (or otherwise) if the show modal call using this form works in your big project. This will point towards the problem being with the other form you are trying to use show modal (or to it being something related to the project).
It may look like a simple question. But we all expect this line of code to be ok. So the problem must be elsewhere in the code (as is so often the case with issues that don't (on the surface) appear to make sense.
So if the community is to be able to help you do need to provide details such as version of Delphi, the framework you are using (VCL or FMX) and the target you are generating binary for (Win32, Android etc).
Like you, I tend to feel that sarcasm has no place in the postings, but equally asking our esteemed expert colleagues to guess rather than giving them precise details and or examples is hardly courteous either.
It's an interesting problem so do please offer more details.
If you open the IDE by double clicking on the MYGROUPNAME.groupproj file the IDE will use the MYGROUPNAME.dsk file rather than the *.dsk for the individual project.
DeleteFile expects a String (the file path) not a TStringDynArray. Is this the problem?
C++ or Delphi ? Which version ?
Firemonkey or VCL ?
As a first attempt I would suggest running a new project - with an empty form and just confirm that this compiles and runs ok (if you want to be thorough you could repeat this for both static linking and dynamic linking.
Using TFDMSAccessService to "unset" the password on an MS Access compacted database
I have a local MS Access database. I am using FireDAC with C++ to "compact" the database.
I do this using TFDMSAccessService. I want the compacted database to have no password.
The database I am compacting does have a password. I have two paramters to set up prior
to calling TFDMSAccessService::TFDMSAccessService. These are
What do I set these two to in order to achieve may aim?
ie is Password needed to open the database to be compacted or to set a password
on the compacted database?
Does "ResetPassword = true" cause the password on the compacted database to be
cleared (ie no password) or does this actually set the password on the compacted
database to the new value in "Password"? (in which case it would have been better
named as "SetPassword").
I agree with Ted "best class" is not a good description as "best" very much depends on what you are trying to do.
For simple text i/o a good method is to use a TStringList variable and use the LoadFromFile() and SaveToFile() methods.
I would have expected ADO to still work fine with a local database.
I am not so sure about your line
newdate1 := '2018-10-24';
Are you sure your database supports a date format with yyyy-mm-dd using hyphens?
What happens if you use
newdate1 := '24/10/2018';
Or if you are wanting to use COM interface (as you state in your original posting) you should use the type OleVariant.
In VCL, C++ code the following works ok:
An obvious question: Is your PC clock set to the correct time? Why is your error message reporting a time in 2019 ?
One time this is useful is if you break into a running program/app and it comes up in the IDE in the niddle of a low level VCL library in assembly code. In this condition single stepping steps through each line of assembly code. Trace to next source line then runs to the next assembly line that corresponds to a C++ or Delphi source code line. You can then close the assembly file and the IDE puts you back into the C++ or Delphi source code.
It is possible but not necessary that the compile time issue and the IDE debugging issue are related. Generics can result in large code generation and large compile times if the generic objects are used with lots of different types, Does your code do this? If you construct a simple dummy Delphi VCL Win 32 bit project without any generic definition(s) does this compile in a similar time on each system?
I'm not sure that I know why you are seeing your slow performance but I can reassure you that this is not typical. Firstly your two set ups would not be expected to see such a big change in the Delphi compile time. Secondly debugging a Win 32 application would not normally cause any significant "cpu useage" reading in the Windows task manager. I use "Trend" anti-virus and this doesn't get in the way at all. I am aware that this reassurance isn't much help as I can't offer any immediate suggestions on what to try to get you to a normal running condition.
About meIndependant professional C++, microcomputer embedded software and SQL software engineer
City / TownColyton, East Devon
College / UniversityUK: University of Manchester, Dept: Electrical & Electronic Engineering