David Schwartz

For the situations where I need to launch and not wait for return, I create an instance dynamically and did some contortions so the OnFinished event handler kills the instance. But when you open a file in, say, Notepad++, it's really irrelevant. If you close the program before these instances have closed, they get freed anyway. The Windows API doesn't seem to care, so I could probably just launch them and forget them. As an aside, I was also looking for some code to launch a command and get the STDOUT back. Someone pointed out that JVCL has something built-in, an Execute function. There are actually several variations. But I couldn't find one that lets me set the working directory, which seems rather odd for such a complicated bunch of code. I found something else here that takes a working dir param, https://delphidabbler.github.io/delphi-tips/tips/61.html but it doesn't capture STDERR. Seems to always be something missing. 🙂

That is something I want to do. In fact, I added right-click menu options for "Move up ^^^" and "Move down vvv". It's simple to move them on the list and then refresh the display. A drag-n-drop approach would be nice, but it's not worth the trouble for what I need.

since you're familiar with it, maybe you can tell me if it would suffer from the same problem?

I posted this in SO and it was closed with a ink to another post. @FPiette offered to share some code he had done previously that does it. I thought this might be a better place for that.

I didn't come up with this. The guy who made it added the "... resolve conflicts" bit because we keep getting conflicts arising in stuff we're not working on. Our boss has even experienced that and he can't even explain it. Our so-called "git experts" said, "Well, you shouldn't be getting any conflicts". That's nice to know, but we are. At one point I _did_ stash some changes, then 5 minutes later I tried to pop them and got an error saying there were conflicts. I do not understand this stuff very well, obviously. I'm being told to "follow the scripts" and we get problems. Then I'm told the same thing you're saying, "Well obviously you DID mess something up and so you need to FIX it!" No, all I did was edit some files in the one folder that was associated with what the ticket I was working on related to. I did not touch anything else. And again, when I say that last bit, everybody hears "he's being defensive and trying to blame someone else!" I'm just trying to get ahead of this a little bit. I'm fed up with all this crap happening in other folders that I'm not visiting, and people suggesting that it's something I did. They don't want to listen to my explanations. From my standpoint, I just want to get rid of all these other folders and just focus on the few I need to do m work. But that will cause other problems. 🙂

I'm looking for design ideas in terms of how to approach this process model from a UI perspective. This isn't something that gets discussed very much here, so I thought it would be fun to see what others have to say. FWIW, this is something I'm building to save my own sanity at work. 🙂 Say you have a process that has several steps, eg: o Prepared o On-boarded o In Progress o On hold / problem / issue o Waiting for more info o Pending signoff o Completed I set these up using a TRadioGroup. It works ok, but I'm finding things "falling between the cracks". So I'd like to break each one into more detailed steps. If there are sub-steps, each of the sub-steps must be checked-off in order to get the entire step marked as complete. Some can be optional, but the required ones need to be checked or some alert will be displayed. The nature of things is you can't really jump ahead, but you can go back -- mainly to the hold or waiting steps then back to "In Progress" "Pending signoff" might breakdown into these sub-steps: -- Team code review (optional) -- Team signoff -- Publish to QA server -- QA tests complete -- QA signoff FWIW, this is not intended to implement a fancy and highly-controlled workflow of any kind. Rather, it's intended to be more of a GUIDE ... a list of things to remind us of all the detailed things that need to be done for different kinds of tasks, like a checklist. There's a similar approach to each task, but they have some variations depending on different things, and it's often hard for us to keep the differences straight. So having a list that's customized for a related set of tasks (or task group) will help us keep from doing stuff that's not needed, or forgetting things that are needed, for each kind of task. For example, one group of tasks might require you to paint things green, while another might require them to be painted white. They all require being painted, but having a specific thing that says what color for a given group is often very helpful, so you don't have to ask someone or go searching through your notes. It's not obvious if you don't know, and not well documented otherwise. Until you've done it a few times, that bit of missing data can slow you down quite a bit. So rather than simply saying, "Apply paint" the step would say "Apply GREEN paint" or "Apply WHITE paint" or whatever, depending on which task group it belongs to. That's what I'm trying to get at here. For any given group of related tasks, their lists would be pretty much static -- that is, the steps involved change very rarely. (They've been in place for years. The problem is, one guy has been doing them for years, and he has forgotten more than he can recall. In training us to do this stuff, he's missing lots of little details, and we're having a hard time documenting this in a way that makes it obvious at the time we need to know.) Timing wise, a lot of these tasks can be handled in an hour or two, most within a single workday. Sometimes they end up spanning several days, especially when they get put on hold while we wait for clarification of ambiguous or missing details. This would also make it easier to bring on new people. How might you approach this from a UI design standpoint? (I don't expect to see a single component that does it all, but who knows?) (I'm not looking for how to store this data in records or lists ... but how to represent it visually on the screen using VCL components.)

Someone earlier asked about the flow we follow. Here's the current iteration. ------------------------------------------------------------------------------------------------------------ Start day Open git bash from I: or V: > git checkout master ...if not in master > git pull ...resolve conflicts > cd /i … or /v, I.e. CD to the other drive > git checkout master ...if not in master > git pull ...resolve conflicts Create a new branch – only create a ticket branch from master > git checkout master > git pull > git checkout -b <ticket-branch-name> Interrupt current work to change context > git commit [-m"<comment>"] ...changed files as work-in-progress > git checkout master > git pull … should be current Continuing work in existing branch > git checkout <ticket-branch-name> > git pull origin master ...resolve conflicts Commit branch changes (while in branch) > git add file1 [file2] […] > git commit -m"<commit message>" Commit branch to the repository > git checkout <ticket-branch-name> ...switch to the ticket branch > git pull origin master ...resolve conflicts > git checkout master ...switch to master > git pull ...pull changes from repo, resolve conflicts > git merge <ticket-branch-name> ...merge the branch into the local master > git push origin master ...merge local master into remote master > git branch –D <ticket-branch-name> ...delete the branch ------------------------------------------------------------------------------------------------------------ Would it make sense to set these up as macros that can be triggered by buttons in a tab that's got a memo set up as a command prompt window? Or have them done automatically in certain situations? For example, I have something I'm fiddling with that lets me manage things I'm working with for a given ticket. It records contextual info (project name, folder, files, notes, etc) for a that ticket. So if I were to create a new ticket in this tool to respond to a ticket I got in my ticketing system, it could set up a new git branch and enter it. And if I switched to work on another ticket, it could do the necessary saving and context switching in git. If I close the app, it could prompt me to do a commit of my current work and switch back to master, or just leave things as-is.

Personally speaking, I'd rather not have to deal with things in other folders than what I want to be working in. I can see situations where that kind of behavior (updating files everywhere) would be helpful. But in this case, it's not. It slows things down, it creates a distraction, and unfortunately it leads to conflicts that you have to deal with before you can continue doing your own work. If someone else is misusing a tool, why should you be impacted by it?

I've never figured out why they change so often either. And with or without them, in the rare cases where I select None for an alignment, it usually just leave the object in the same place and dimensions. I don't care if it reverts back to something else or not.

What are they used for? I could never tell why they even started showing up.

I'm not clear enough in what git is doing to explain this much better, but here's what I think is happening... You make some changes to code in folders A, B, and C, while I'm working in P, Q, and R. I set up a branch and do a pull from master. It updates the files in my local A, B, and C folders, because you made changes to them. I'm not touching them. I make some changes to P then go home. In the morning I come in and do a git pull and get a bunch of stuff from A and C that you've been working on today. I finish up work on P, commit it, try to push it, and then I get a warning from git saying it cannot push because of a conflict in some files in A. So I have to stop what I'm doing and figure out what in the hell is the problem with files in a unit I had nothing to do with that's preventing me from pushing my changes in P into master. I've got customer service people pestering me to get these changes pushed into production ASAP, and you're at lunch, and whatever I do to proceed is going to screw up your work. This is what we're running into. I'm probably not even explaining it fully accurately, and it probably suggests we're doing something wrong. But all that sticks in my mind is that this issue is arising because of timing dependencies between when you pushed some stuff to git, when it got copied down to my local repo, when you then made some updates, caused a conflict yourself, and that got pulled to my local repo before you resolved it. So that left it to ME to resolve locally. In these situations (which have come up at least a dozen times in the past couple of weeks), I can neither pull nor push anything until I "resolve" the issues in YOUR code on MY local repo. I notify my boss who goes haywire, immediately sets up an emergency video conf call with 8 people, and we all spend 45 minutes trying to fix this mess. And the bottom-line is that people point their fingers at ME for screwing something up. All I know is, I did not touch any of the files in either A, B, or C, and everybody gets their knickers in a wad when I say that because it makes me sound defensive and trying to shift the blame. From MY perspective, I just keep asking, "Why in the world can't I just work on the files in folders assigned to me and not have to deal with all these other folders getting their files updated and having issues when they have nothing to do with anything I'm working on?" I'm still relatively new here, and the guy who has been single-handedly maintaining this code for the past several years left, but he made it all look like a walk in the park. We are now tripping over ourselves every other day with weird stuff like this that everybody says should not be happening. I'm pretty sure we're doing something wrong in how we're interacting with git. But we've been given three different scripts to follow now, and they all seem to result in the same problems coming up, but at different times and contexts.

Nope. I think if you understood the problem better, how our solution is organized, and the environment more, you wouldn't say that. Some of our other facilities take that approach, and our effective down-time is an order of magnitude lower than theirs, if not more.

I did. You don't seem to like that idea. Why? They're all independent. Actually, what I have in mind more specifically is moving towards a folder structure more like this: <client>/<account>/<type> Where each <client> would have their own repo. I'm guessing we have maybe 75 active clients at the moment. Some of them only have one or two accounts, but some have 50. The accounts a given client manages sort of cross-pollinate each other because there's a lot of stuff the client sets up that's common across several accounts. Otherwise, there's virtually nothing shared between the clients other than structural stuff (eg., they all use the same types of files, etc.) The <type> relates to the thing getting printed, like a Statement, Letter, Invoice, Flyer, etc. Right now, everything is flat: ABC035_stmt_imp would be ABC/035/stmt in this new scheme. We have around 850 of these folders (like ABC035_stmt_imp) right now, and there's on repo that manages all of them. In my mind, having a single repo per client makes a lot more sense. At the moment, management is totally opposed to any changes at all, but the last man standing who knows how all of this works left recently and all of the plates he has been juggling for so long are starting to come crashing down around us. This is all process-oriented stuff that has very little to do with Delphi other than that's what the import apps are written in.

I think I forgot to save a reply I made to this ... unfortunately, we don't have either DevExpress or TMS here, and I know they've both got components that would be handy. I got something working based on a TScrollBox, which is surprising to me because I think it's the first time I've ever gotten one to work right! The 3rd item reflects a problem I had that is probably due to rendering the subpanels directly on the panel controlled by the splitter. I changed the implementation so I have a TObjectList<TPanel> to hold the subpanels. Actually, these are not TPanels but a helper class for them to provide access to the objects added to the panels. Again, I find this a much simpler approach than using TFrames. I also added a helper class to the scrollbox that adds a method to display the list in the scrollbox' display area. I realized it's probably easier to add a way to move items up and down in the display if they're in a list and I can move them relative to each other in the list versus on a panel or something, where they can get rearranged due to logic of the thing they're sitting on. With the list, I can rearrange elements, then just tell the scrollbox to refresh itself from the list. It works great. I implemented the scroll wheel with an increment = the height of each subpanel (they're all the same). You can adjust the splitter up and down, and it smoothly shows more or less of each row with no flicker at all. One little trick I did was put the mouseEnter/Exit and double-click event hooks in the scrollbox even though it doesn't use or need them. But when I tell the scrollbox method to set or refresh the list, it goes through each item and copies these hooks from itself to each of the panels, so I don't have to tell the list or the panels this information. They're informed by their host. (The panels have the same hooks as the host, so it's a simple matter for the host to copy them when it attaches them to its back, so to speak.) The only quirk in this whole approach was that because I used some helper classes, I couldn't add any data members anywhere. So there's no way to inject the list itself anywhere. (I'd prefer to add it to the scrollbox helper, actually, but I can't.) Because the scrollbox is a visual control on the form, creating a child class from it can pose challenges with the form (in my experience). So I resorted to setting the list var up as a global var in the implementation section. This just seems so much simpler than other approaches I could think of at the time. Luckily, I've only got one, and its lifetime is equal to the life of the form. So ... meh. It works. 🙂

That's also very nice and organic. I've set something up using a kind of "drill-down" approach, and I'm not sure I like that it hides the overall process. I like that this approach also resembles a progress bar.

no, there's ONE repo -- it handles EVERYTHING in the whole virtual I: drive. It's certainly an unusual approach based on my experience. I'd set up a repo in each folder that only captures changes for that project, because they're independent of all others. Why mash them all together? In the bigger picture, most of the work is the same: changing things like branding (logos, colors, etc.); changing the monthly message on statements; address / phone# changes; and verbiage for things that changes to local laws require be adjusted. (We support a lot of collection agencies, for example, and we are constantly updating those little paragraphs on the back of their notices that specify your rights and whatnot depending on what state you're residing in.) Virtually none of it is programming.

I think you're thinking we spend months working on stuff. Our work is very quick turnaround -- sometimes less than an hour. We can be faced with git conflicts several times a day. I've spent more time "resolving" conflicts on code I had no hand in than it took me to do my ticket. It's a serious distraction.

Boy, this terminology is making mincemeat of the discussion.... We have 850+ project folders that are used to build standalone EXEs for parsing unique input data formats and turning them into something similar to PDFs. The original developers could just as easily have chosen to make them DLLs since they all have the exact same "footprint". They're all for "clients" of one kind or another. All 850+ of them. Our routine work involves very little with Delphi, however. I may need to change a logo, or a return / remit address, or a monthly greeting on a statement. There's virtually no programming involved, although they call us "programmers". I suspect they see the value of having Delphi experts on hand is exemplified by a request I got today: we have a data file that aborts; after looking closely at the data, I can't find anything unusual. Please spend some time stepping through the code and let us know what the problem is." Such fun. Back to git ... personally speaking, I think the repos should be set up on a per-project / import EXE / folder basis. That way there would be no interference with other projects when it comes to managing the stuff we do on a day-to-day basis.

I've never really seen any discussions about this kind of a workflow in git, and it's very different from anything I've been around before. A couple of the others at work find it very unusual as well. But if it's familiar to you, then you can probably help. This is exactly what we're running into. Not just me, but others. I don't understand what's meant by "use pull requests to merge into Master". I see people on GitHub say that if someone wants to make changes, ask for a pull request. Anybody can download files and change them. I don't get why you ask for a pull request when you basically want to "push" stuff up to the repo. I did do something in master after making some changes in a branch, and effed everything up. I think I collapsed origin onto master with a "git pull origin master" from master when I thought I was in a branch. I think in pictures, and I've never seen any good illustrations about what goes on when you're working in git. Everything is text. I just haven't had that "aha!" moment yet where I can visualize what's going on in my head. It seems to be like you're interviewing yourself. You start out in one chair, do some stuff, switch seats, talk for a while, switch to the other seat and process what you said earlier, then say some stuff, go back to the other seat and process that, and so on. Nobody likes that we do work in one folder and git is constantly shuffling around files in other folders, and throwing up conflicts because someone else is in the middle of doing some work that has nothing to do with what you're working on. Branches only seem to make things worse. When I do a branch, I only want to focus on a given folder. What happens is we pull along a ton of other unrelated crap, and if someone happens to push an update to any of it while we're working, it can cause a conflict with stuff we didn't touch. I'm trying to figure out if we could reorganize things so that each client (reseller) has their own repo and folders beneath them for each of their customers, rather than at the I:\ root. So we'd go into a folder and then create a ticket there and it would only affect that repo. I don't know what would happen if we switch to another folder / repo and work on a ticket there. Honestly, having a file system with no history and a history manager that fiddles with the file system is quite confusing to me because it leaves it up to you to remember to tell the history manager that you moved somewhere else in the file system or the history manager gets totally confused.

This is a nice idea for a summary dashboard, for sure. But in this case, I'm looking for something that only applies to individual tickets. It's a tool to help both show the person what's needed as well as signify what's done and what's left, sort of like a check-list.

I'm looking for some help with our particular usage model, not individual commands. It seems it has been working fine with one guy and a part-time assistant when they could coordinate things, but with three people now working in parallel, it's got us all tied in knots. I suspect most folks here are mainly using git alone. This is a small but growing virtual team of devs we've got and most of them are familiar with TFS. Git has them scratching their heads. And our production schedule / model is not what something like gitflow was designed for. I'm wondering if anybody here knows of any public discussion groups (of whatever kind) that focus on this kind of topic?

Yes, that's our thinking exactly. Which is why I'm looking for some input from others about this. I'm not very fluent with git myself; mostly it confuses me.

Ok, well, I posted the issue in a separate thread if anybody wants to look at it. It's a "real world" scenario, not something over-simplified as a class exercise. Maybe I provided too much info, but I tend to try explaining all relevant aspects rather than just one piece and wait for people to ask about other sides of the issue.

I'd have a list of unprocessed requests that feed the sending agent. If the agent dies, the list sticks around. The challenging part is the potentially diverse time dynamics involved. You could use a multi-threaded design to feed hundreds of messages per minute to an API for a commercial SMTP service, like SendGrid, or just use a simple loop that sleeps for sending to a shared hosting account that limits you to 100 per hour or 500 per day. If you try sending through your ISP, like your cable company, you risk getting shut down if you exceed certain limits that they don't like to disclose. Sending stuff through an SMTP relay is, on the surface, one of the simplest things you can do. But the practical implications of it -- being that it's probably the single most widely abused resource in the entire internet world -- are that your sending agent needs to be highly resilient and pay close attention to the error codes it's getting. It needs to be programmed like that song about The Gambler -- know when to hold 'em, know when to fold 'em, know when to walk away, know when to run... You do not want your SMTP host to shut you down, especially when it's your ISP or web host b/c they could just as easily shut down your entire frigging account! That's a really big benefit of using a 3rd-party SMTP host -- the worst they'll do is shut of your SMTP account. And it's easy to find another one. (Better yet, set up several before you even get started.)

in this case, we know its hierarchical. But there are probably dozens of ways to display and navigate a hierarchy. 🙂 * vertical (trees), horizontal (org charts), or free-form (mind-maps) * bubbles, boxes, graphics, text, both * lines or not * static or dynamically expandable/collapsible * background colors / graphics / highlights * editable (inline, popup, separate form) or not (configurable vs. hard-coded) For what I described, I'm curious what comes to mind most naturally. I rather doubt something like a mind-map would flash up immediately. We don't have either DevExpress or TMS, unfortunately. They've got some stuff that would be great for what I'm building here.