Jump to content

Gary Mugford

Members
  • Content Count

    55
  • Joined

  • Last visited

Community Reputation

3 Neutral

Recent Profile Visitors

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

  1. Gary Mugford

    Slight Refinement to Component Property Replace

    Dummzeuch, Thanks for getting back to me. The reproducible answer would be, by necessity, a small project and the answer would inevitably be, have all database connections start with being off (perhaps through the expert in question) and then start them at run-time according to need. That way, when working with ReportBuilder on a single form at any given moment, you can ignore the fact that RB ACTIVATES the datasource while working on it within the IDE. IF you forget to deactivate the datasource before compiling, then come runtime testing, it will hit for example, table.emptytable, the program will throw and error, citing that the table is busy, Again, if you are starting over and (in good programming form) starting up the databases at run time in the code, this is the obvious situation the expert is for. MY Problem is that this is a 30 year old program that wasn't designed all that well at the beginning and only got worse as kludges and new features were added willy-nilly. I have, over hundreds of forms, and the two datamodules, several hundreds of database connections (I think a shade more than 400 at last count). Some are inactive. MOST aren't. They come up ready to go without me writing any lines of code. The expert DOES say it will only affect the active files in the editor, which in my case includes the BIG central form, with around 80 active databases on it .... yes, I can read the comments to be written already and acknowledge, in advance, their correctness ... as well as two data modules with about 200 connections, mostly active in the dLookUp module and mostly in active in the dData module. The expert, despite neither datamodule being in the editor at the time, indicated it would reset all connections in them, as well as the big central form and the one form I was working on. I needed it to be on the form I was working on ONLY. I think my narrow niche need for work on this is beyond making a request official. It's not worth other programmer's valuable time. Sigh. I was hoping the change would be a minor effort. Since it's not your expert, I understand what I am asking for. So, I will have to change things around just a little bit. I've lowered the top edge of the IDE and overtop of the button that I click to compile, I have placed a graphic telling me to DEACTIVATE the CBOX.DB. Crude, but it seems to be working. Again, thanks for all you do for the community. GM
  2. First of all, kudos to all the folks who participate in making GExperts. It is all appreciated. And in this particular case, I guess Robert Wachtel gets a big share. Thanks. Now, I THINK the reason for the expert is that people get busy working on a form and at some point, the compiled application won't do something particular, like say emptying a table, because it's still active in the IDE. I'm running head on into that nightmare right now. The Component Property Replace expert would save my mental fugues if it was JUST a little more particular about what it chooses to switch and what it doesn't. I have a BIG project, and it's an OLD project done in D7. There are a couple of data modules, one BIG central calling form and a nightmarish number of sub-forms. All of this grew organically and is out of control. A replacement is underway, but it's nowhere near usable yet. So, I'm stuck updating the old app. I'm working on a form that centres around a central database ON THE SUB-FORM that a number of reports run off of. I change things in any of the form's report objects and it auto-starts the database in question which I later need to deactivate before compiling. Something I do about HALF the time. Getting old and stupid. I would very much like this expert to replace my brain and do what I forget ... set the database.active to false JUST ON THIS FORM before compiling. Which the expert will be happy to do. But it also will reset the data modules and the big form, the latter one I expected from the fact it is open in the IDE, the former two, the data modules, somewhat surprisingly. There is a setting that allows you to limit the resetting to just the forms open in the editor. I sort of have to have the main form up all the time. I COULD try going without it just for this focused (or lack of focused) programming frenzy with the sub-form in question, but it would cause other issues. So, I make the following suggestion: Please have the expert ONLY apply to the SINGLE ACTIVE File TAB in the IDE's editor. Alternatively, the open files in the editor (which should exclude the data modules in MY working example because they don't have an actual tab in the editor). That would let me make the decision to temporarily shut down the main form to concentrate on the sub-form. The best of all worlds would be a radio box that allows: All files in project All open files in editor Just open file TAB in the editor Maybe reverse the three based on left-side/Top-side DEFAULT bias for picking since it's the small end of the working group numbers. Lastly, and this is probably the fly in my ointment ... I use Castalia as my editor. That MIGHT be why the data modules get included in my run of the expert. Or would, if I turned it loose to actually protect me against the ONE thing, while causing me to go back and but in the code to turn on databases on Form Creation for all the affected switch offs. A daunting task and why I am not actually USING the expert currently. Second lastly, a different approach, which I think is impossible ... letting me cite Form and component as a direct target. I'm actually doing this for ONE annoyance currently. Say I could put in TWorkingForm.TTable and have THAT set to false on compile FIXES ALL MY PROBLEMS and it doesn't create the possibility of mistakes spreading if I pick the wrong choice in my hypothetical radio box above. Regardless of whether this spurs anybody into their own programming frenzy, just want to repeat how much appreciation GExpers has from me. Thanks.
  3. Gary Mugford

    Combining several applications into one

    Actually, I'm unfortunately going to have to agree with Mr. Heffernan. The end goal is a working umbrella process, it's true. BUT the end goal is also to have one cohesive program to run against Delphi Parser with a capped licence of 1M lines of code. So, I'm trying to pare down everything, no duplication, no sub-folders. Just code to update via Parser so as to change Database backbones. The idea of calling exe's would BE a solution if there was no next step. But there is. At that, they have the umbrella already ... the Windows desktop, in the form of LOTS of icons. Well, not lots. Each user gets icons for sub-applications that are pertinent to that user. My problem right now is that I have apparently wasted my time collecting all the code into one great-big folder and 74 sub-folders with subfolders and subfolders etc. That action was premature. I was hoping to speed things along, but the opposite has happened. The issue is that in ADDING units that weren't in the settings as search path entries LIKE my own home-grown utility libraries, they hard-coded PART of the paths in the DPR's uses unit. Now, I'm DISCARDING the DPR, but there's something in the DNA of the program that when I bring it up to rename the form, planning to save this copy of the form PAS file into a different name, something goes astray every time. It MIGHT have something to do with AJC Active Backup maybe getting confused given the file name no longer tracks back to the last version in it's database. Don't think so, but I'm throwing mud against the wall looking for a hidden message. Not everything, Maybe one out of four or five, but then the time with that one takes FOREVER to get done. Also, any mini-app with sub-forms takes two or three times the time of a single form, but that's to be expected. As I asked in the OP, I was looking for pitfalls. And I've found them. For future readers similarly run afoul of their own design, I hope reading this in advance of trying what I'm doing will help, although the better advice is ... Don't Screw It Up In The First Place.
  4. Gary Mugford

    Combining several applications into one

    Frost, The renaming is not quite as easy as I thought it might be. I wanted to go in and edit the DFM and the PAS files and replace FrmMain with FrmMainActivityReportToolset in the copy I had made of FMain.Pas renamed to FMainActivityReportToolset.Pas/DFM. Then, I used the search and replace to find frmMain with the longer monicker. But I'm getting a lot of errors when calling up the form from the umbrella. The DPR file in the sub-folder might be involved somehow. So I'm going to work on that theory for the next few hours and then cutaway to watch the Clippers Raptors game. Back at it come midnight. Thanks for suggestion. GM
  5. Gary Mugford

    Combining several applications into one

    Rollo, GIT and whatever CI is are beyond my skillset. I'm just a slogger working through it, one app at a time. Problem is, it's one app every six hours at the rate I'm going. And year end is 80 days away. Seventy if I want to try things out first. Which doesn't leave much time for basketball on the TV and things like eating, sleeping and going to see the doctors. Sigh. Deadline pressure is good, if it doesn't kill you first. [G] GM
  6. Gary Mugford

    Combining several applications into one

    AE, Actually, there's a ground-up rewrite using a wholly customizable user interface that I was in the middle of when the breaking of BDE by the Microsoft Windows Update Fall 2017 made continuing to use the app, which dates back to DOS days as a Paradox app and went Windows in the late nineties with Delphi 1, untenable. So, it's past 30 years old and nearer 35 than not. What I think of Microsoft is not allowed to be printed here, I think. In order to survive until I can get the new software up and running, the plan became to get the app and ALL the satellite apps together and use Delphi Parser (a SHOUTout here for the amazing customer support) to do the backbone switch for me. There's also a gazillion instances of components from companies no longer in business. They have to be replaced along the way too. And I was shocked and dismayed to find I hadn't produced XE7 for my OWN components (merely extensions of existing components with more properties set). When I wrote ComponentKing to find the mish-mashes between D7 and XE7, it found the expected ones missing in XE7 like the long-cherished, but forgotten ABC components from Australia. At least I know what has to be replaced and have a Rosetta Stone of what goes where (technically, what gets replaced by what and WHAT I have to do post swap). And ComponentKing did give me a list of units to un-use via Parser or Replace. So, I've got a decent start. I never used things that trigger spasms from unicode. Replace will do the string/ansistring swap and the assorted cousins. BUT the whole shebang has to be ready for Parser to do the backbone swap and for me to have the app working lickety split. I've never had a single day of parallel testing and the longest beta test on record was one day. I'm expected to be functionally perfect (acknowledging I might not catch EVERYTHING ... until day two). I would follow your advice in other circumstances. But I agree with it one hundred percent. Thanks, GM
  7. Gary Mugford

    Combining several applications into one

    Lars, Rollo and Frost, Appreciate your comments in toto. Unfortunately, I wasn't clear. ALL of these applications, save one in Delphi 2010 and a half-dozen in XE7 are in Delphi 7. In creating the umbrella app, I want ALL the source code of the umbrella app and the 74 independent apps in ONE folder. There's a reason for this, I need to bring them all together for Delphi Parser to help change the database backbone. The end result needs to be a case of all the software working with the new backbone,, the apps being menu items in the umbrella main app. It's ballpark three quarters of a million lines of code. And it has to be ONE APPLICATION, ONE FOLDER. Oh, and working in Delphi 7 with an eye towards the lot being transitioned to XE7. I LOVE the idea of frames and looked at them. But I didn't use them, preferring composite components. Bad decision. But I've been in the 'Get it to work' business for a long time, once releasing more than 250 updates in a single year (and that was one a day) back in the early days. My employer suffered from the dual scourges of not telling me enough and then having an active imagination when seeing what was possible. But those days of turning in updates two days out of three are long gone. The kludged together main program and all the satellite apps now need merging. Faster the better. I'm stuck on something I managed to change into non-usability back in 2017 but left it like that since the 2015 version of the software worked. Now, I NEED to fix what I broke. But once I get past that, I THINK I have the routine of work down pat. But that leaves me thinking I'm missing something. It's worrisome. While not being able to immediately take advantage of your advice, it's in the bank for moving forward. Thanks!
  8. I have an archaic programming creation structure. For every project I create a folder. Inside that folder, a sub-folder called data and a sub-folder called proj. Within the proj folder, the application's main form is always called frmMain, saved to a PAS file called fMain. The project file is named after whatever I'm calling the program. Usually a short name rather than a full flowered name. i.e. ManifestMgr that runs windowtitle-wise as Manifest Manager version 5. Or somesuch thing. Each sub-form obviously runs separately but many will have a uses FrmMain in the clause. There are separate utility files that I use across all of my programming, so uses uGlobals, UGProcs and ESBDates are very common. The development folders are spread across four different drives. I INITIALLY thought to develop using a drive per group, but got sloppy and now any program can be anywhere, although the central utility libraries are with the Delphi install on drive E. What I want to do now, is to take a selection of those programs and combine them into one. There are three different versions of Delphi involved. My plan is to go through each program and change the FrmMain structure into something more applicable ... FrmMainEncryptedPasswordGenerator, for example. Which means going through all forms on the given example and changing FrmMain to FrmMainEncryptedPasswordGenerator, fMain in uses clauses to fMainEncryptedPasswordGenerator (or more likely, fPWGen). Having done that, I intend to glue the full contents of the folder to the one folder's contents that I intend to be the master program and set up a menu item in it to call on the file FrmMainEncryptedPasswordGenerator as a new sub-form. I worry that each of the new now-sub forms rather than standalone VCL projects, will have issues with things like auto-create and the such. I am not an accomplished programmer. I slog through things. I have never used pointers. Rarely used classes. Don't think there's an actionlist in the lot. I DO use third-party libraries, but they will call and use whatever tricks they have regardless of the new order in the universe. So, here's the question ... Anything I should be aware of in my stated course of action?? Beyond the finished product needing to be upgraded to the most current Delphi version of the three. I just want to know if the slow-and-steady process of changing the main form's name to something unique throughout the project and then gluing it into the central calling app, is a reasonable approach. Or might there be a better, faster, less-labour intensive way? Thanks for taking the time to read this and answers are always appreciated.
  9. Gary Mugford

    ANN: StyleControls VCL v. 4.53 just released!

    Tim, And then the drones set it back. Or to something worse. And they obsess over themes. PLUS, Teamviewer (I'm housebound and haven't been to the office in eight years and counting), which I use for remote access, takes the colour out to speed communications and I have to take that option due to the small pipe at my main customer. I'm hoping styleControls overrides that for me, while maintaining the rest of the windows I'm NOT interested in being useless white. Ack! More whining. If they give me the thumbs up that I can pile a NextSuite TabControl notebook on top of a themed form with nifty title bar and then on the pages of the notebook I can use MY choice of components and they'll get themed, then I have my hot plastic STARING at me from a shelf on my desk. GM
  10. Gary Mugford

    ANN: StyleControls VCL v. 4.53 just released!

    Almediadev Support, Thanks for the reply. I DID look at your third party list as I mentioned in my comment and saw a large proportion of my libraries there, but not all. (By the way, the link included above doesn't lead anywhere). That said, the question remains, what does the presence of say a NextSuite tabbed notebook look like on a page of your otherwise themed form WITH controls that are themed? Does the parentage of it being the NextSuite control mean the theming doesn't apply, or do the controls theme regardless of ownership? As for the dialogs, I'm curious, but they are not a show stopper for me. In fact, having dialogs that STAND OUT from the background would be something good rather than not good. Frankly, the overall look isn't something I'm overly sensitive to. What I AM sensitive to is that the default Windows 10 'theme' is horrible. The white window title bar header is beyond useless against a sea of windows with white from edge to edge. In the old days, I had control of things. A simple GREEN for active window and RED for inactive windows made screen recognition easy. But through aero and glass and all that, Windows became something that almost beggared being run full screen. Which I hate as I remote in to see all my apps being run full-screen. I run multiple monitors with maybe a half-dozen windows open at any given time, usually more, and some of them over-lapping. Title bars that instantly show me active status help immensely. What I particularly like about your StyleControls is control over the title bar. One last question if I may. I have a project I'm updating from D7 to XE7. On the form, I have a lot of controls where I've manually set the colour, the font specs and various other visual bits (transparency, alignment, etc.) Now I have the form ready for the addition of your StyleControl, which I assume is a non-visual control. On it, I pick one of your themes. What happens next? Do all the defaults I have NOT adjusted switch to the theme, but the ones I manually set stay the same? Or does everything switch over? e.g. If I have the font.color set to clNavyBlue, but the theme I've set it all to is orange and black, does the font colour still stay blue or does it switch to black (or orange) in my example? Does the theming over-ride Transparent? Thanks, GM
  11. Gary Mugford

    ANN: StyleControls VCL v. 4.53 just released!

    I've looked at your product several times over the years. But being mostly D7 programming into a Windows 7 environment, I let the urge pass. NOW, I'm stuck re-doing a project that is the hodge-podge result of about 35 years of programming starting in the era of DOS and Paradox 1.11i. We now face the Win 10 apocalypse that broke BDE almost completely. The result, well now I am looking at homogenizing things moving forward. I like the TMS and JV sets of components and I have a variety of other ones that I dip into (DevExpress, Woll2Woll, etc) as the case may be. But what I don't see on your list of compatible component sets are NextSuite and ESB controls. There are others that are more single use than most. What is the ... compatibility with what to you are third-party components, while vitally necessary to me?? If they aren't compatible and WON'T be moving forward, what is their look on one of your themed forms?? And dialogs. I use the JSDialog's with D7 and then their more-or-less descendent NG dialog pack from LMD in DXE7. Do they stand out (which I'm NOT against), or get themed too?? I'm aware you have your own controls. But I KNOW the options and coding of the others. The learning curve and versatility vs. the Known. It's a big thing. The pricing is quite reasonable. The time might not be. So, you see I'm fence-sitting willing to teeter or totter depending on what you say. Thanks for taking the time. GM
  12. Gary Mugford

    Find all your components

    You really should investigate Peganza Software's Pascal Analyzer. The Lite version is an easy test and is free. Look at the Controls report to give yourself a flavour for PAL. Now, the fact is, that the full version is full of goodies. For example, it has the PalCMD.exe program to use as a potential command-line interface to the full reports. You want to look at Uses and Control Index. Those are the money makers. Combine PalCMD with a program like SWEEP.exe that lets you iterate through a folder and all it's sub-folders running a command line. For example, I use the following lines to explode a bunch of 7Zip files in their respective folders and then delete the 7Zip itself. Not exactly the toughest of high-level programming but it works ... G: E:\apps\Utilities\Sweep.exe E:\apps\Utilities\7zip\7z.exe x *.7z E:\apps\Utilities\Sweep.exe del *.7z Not every folder HAS any 7Zip files. But when sweep finds them, and it will, it explodes them. The next pass then deletes the 7Zip files. Now, switch the concept to running a PalCMD command-line and you can generate all PAP reports of what it finds. Then you can sweep all those PAP files into one folder. (I use AutoHotKey instead, but sweep CAN do the job with a copy command). Then, you write your utility to PARSE the reports one-by-one and there you have your Master Concordance. I wish I could offer help with your HELP.zip file, but unfortunately, I don't have YOUR version of RAD. I've spent part of today trying to genericize ComponentKing to READ in REG export files and show the concordance between two versions, dubbed OLD and NEW. Not QUITE getting it all right. But it's because I've played around a little TOOO much trying to fine-tune the output to get rid of extraneous information, such as the TcomponentBased. prefix for what I call the source in XE7. Unlike the Palette key in D7, where the source can actually be listed, the Mapping key in XE7 doesn't directly list the source. It's more SOURCE TYPE, instead. But I can live with that, since the whole purpose of the exercise for me is to help develop better ReFind change command templates. If I get something together that's worth others looking at it and using it as is, I'll post ComponentKing here. It's not pretty, but it does what I need it to do. Your need for a master concordance is different than mine. Hope PAL and Sweep or variants of each help you out.
  13. Gary Mugford

    Find all your components

    I'm hoping this becomes everything you want. I make use of Pascal Analyzer Lite to help me compile master lists. Still, that's a little Project-by-Project centric. I make use of Xplorer2 as a file manager and that lets me actually quickly find and list all the pas/dfm's on my ide drive and copy them to one master folder. I then let PAL loose on the accumulated lot. That helps to a certain extent. Oddly enough, I did spend time on the weekend creating an app to list all the components for D7 and DXE7 that I have installed. I have a version that worked in the Delphi's up to 7, mining the [HKEY_CURRENT_USER\Software\Borland\Delphi\7.0\Palette] for all the tabs and their contents. * Replace the 7.0 with each preceding version number. But looking for the Palette value with XE7 was useless. The compilation keys were at [HKEY_CURRENT_USER\Software\Embarcadero\BDS\15.0\ToolForm\Mapping]. There were other issues. XE7 separated items via commas, D7 and before by semi-colons when breaking the key value into stringlists. And the source library prefixes are considerably lengthier in XE7. For example, TMS' AdvStringGrid is TComponentBased.Vcl.Controls.TControl.TAdvStringGrid in XE7 but only AdvGrid.TAdvStringGrid in D7. I basically gathered each version's components into a master database that had fields for CompName A40 InD7 Bool InXE7 Bool Pg A40 D7Lib A50 XE7Lib A80 I had to make the XE7Lib entry A80 to accommodate items such as TComponentBased.Vcl.Controls.TControl in the above example and half that to accommodate AdvGrid in the D7Lib field. TMS Grids went into the Pg field and the two In fields were boolean fields. TAdvStringGrid was the Comp Name. I did this to clearly map where the Comps were that weren't common between the two versions, with special interest in the InD7 but NOT InXE7. I was surprised to find that a few of my OWN written components failed to make the trip to XE7. Which I was able to rectify quickly. This has helped me attack an upgrade mission. I'm still pretty clumsy with ReFind. But I'm missing less stuff. I'm still thinking about getting a list of properties between ReFind targets. I have a master dictionary of replacements, but it's still more trial and errors than science. Sigh. But with the PAL list and my little app, at least I know where the holes are. Will be watching this space to see how you are doing.
  14. Gary Mugford

    With's the deal with "With"?

    Regardless of whether using WITH is a good idea, there IS a solution ... The Convert WITH expert in MMX. It's not perfect and I always take the step of DUPLICATING the block I'm playing with and commenting out one copy, but the expert does a VERY GOOD JOB MOST OF THE TIME, in converting WITH's to object-referenced individual lines. I know, because I was one of (if maybe not the first) the early requestors for this expert. I'm a self-admitted WITH user. I find it easier on my eyes because I indent more than most. Albeit only two spaces per indent. With Uwe doing such a great job keeping MMX alive ... and for a most reasonable price 😉, whether you use it as a crutch early in development or go back through on refactoring passes, the decision to use WITH is only an installation of MMX from being made to go away.
  15. Gary Mugford

    IDE changes monitor when debug run

    A version of this problem goes back to at least Delphi 7. I have most of the IDE and forms on the left monitor, the source code window and some of the other windows on the right monitor. I'll click on the menu and then options (yes, there are hot keys and/or icons in both the IDE and the Editor to do the same thing, but I'm old and set in my ways) and the Project Options will open up in the middle of the right monitor, even past the edge of the Delphi setup itself (I always have visible windows monitoring this that or another in the remaining space on the right). I click on the UltraMon button to move the dialogue back to the left monitor, but the next time I go get it via the menu, it's back to the right. Never learns my preference. Now, is it different if I use a button or a hotkey? Don't know, never occurred to me to find out ! Still, it's indicative of this being a long-standing problem with Delphi. For whatever that's worth. GM
×