Amazing what happens after a weekend of thinking about something else.
Last week, I moved all my source code around for my Access project. I reopened my project and BOOM nothing was there. After a brief panic, I got distracted by other things and it's sat until this morning.
Re-opening the project this morning, there's still nothing in it (shocking, I know...), but it hit me - use OASIS-SVN to import the code from the new location!
Because Access only knows that the modules exist in the directory they were originally created in. Wait... that makes no sense... Access doesn't export/import files by default.
Why did Access loose visibility to all my code/queries/tables/forms when I moved the export/import directory?
This still makes zero sense...
(but it sounded good for a sec. And at least I'm not panicked about what to do about my missing code...)
I don't remember 100% of my steps from last Thurs/Fri, but I'm certain that I did not do an import.
I'd moved everything from project to project\Forms, project\Modules, etc. because I like that structure better.
All was good. Then I read @this' article on OASIS set up and decided to move to project\Source\Modules, project\Source\Forms, etc. That's when everything disappeared from the .accdb
I right-clicked and used TortoiseGit's move with git function to move the files
After reimporting this morning, though, I'm finding issues with my code.
I foolishly reused a branch that seems to have been somewhat incomplete and behind the times.
I did git stash push, then git checkout master and it tells me error: The following untracked working tree files would be overwritten by checkout: for every file in the project.
I thought a git stash would effectively leave you with a clean working tree and you could checkout a different branch at will...
git status yields:
On branch FileReorg
Untracked files:
(use "git add <file>..." to include in what will be committed)
Forms/
Modules/
Queries/
Reports/
Tables/
nothing added to commit but untracked files present (use "git add" to track)
I'm discovering git is somewhat like C - plenty of rope to shoot yourself in the foot with. :(
but they were all tracked on Thurs/Fri... no, things were still a bit fubared then, too.
Above is the output of git status - everything looks clean. I'm OK with the untracked files because I want to get to a different branch and things are good sitting where they are.
$ git checkout master
error: The following untracked working tree files would be overwritten by checkout:
Forms/DataMove.def
Forms/DataMove.layout
Forms/GenQuarterlyRpt.def
followed by a complete list of every file in the project.
it's like git is internally confused.
oh... the following untracked files...
#ReadingFailure
These are the 'broken' set of files that won't compile at the moment. I need to physically move them elsewhere for now to make git happy, then I'll probably delete them once I get myself to a known good state.
$ git checkout master
error: The following untracked working tree files would be overwritten by checkout:
Forms/DataMove.def
Forms/DataMove.layout
Forms/GenQuarterlyRpt.def
That is what I expect in an output. Just Forms/ is unfamiliar to me.
from the command line, I've seen it list the folders like that since I first moved things to folders, so that's expected to me. Not sure it's right, but it's what I've seen...
OK, I moved the folders out of git & OASIS' sight and now git status is telling me everything is deleted. Makes sense. Another git stash push should put me right so I can get to my master branch, right?
I was able to git checkout master. However, upon importing all the code via OASIS, 2 of my forms ended up with all code duplicated and some random text between the copies
I wonder if that was because I was originally using my import/export that wrote the code & layout in one file then switched to OASIS and had it break them up.
Remember that git has no semantic knowledge of the code; all conflicts are resolved line by line and evidently, git decided that there wasn't a conflict; just an insertion in a different place.
Once you're satisfied this is all good, then you 'll need to push this to your master but specify that it's not to merge but rather take all changes from the new branch.
1. Copy known good prod .accdb to dev 2. Make a new branch in dev 3. delete all files from the new branch 4. commit to create an empty working set 5. export to desired folder structure 6. git commit 7. git push -f (from branch to master) to force all changes overwriting master with known good status
based on HEAD or master is the same thing and what I want, right?
actually, it doesn't matter since I'm going to blow everything away...
never mind...
All was good through step 6.
MINGW64 /h/git/ROIReport/Source (ReorgCleanup)
$ git push -f
fatal: The current branch ReorgCleanup has no upstream branch.
To push the current branch and set the remote as upstream, use
git push --set-upstream origin ReorgCleanup
Do I need to checkout master then do a git merge ReorgCleanupthengit push -f?
$ git status
On branch ReorgCleanup
nothing to commit, working tree clean
$ git push master -f
fatal: 'master' does not appear to be a git repository
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
just to be sure:
$ git status
On branch master
Your branch is ahead of 'origin/master' by 2 commits.
(use "git push" to publish your local commits)
nothing to commit, working tree clean
$ git pull ReorgCleanup -f
fatal: 'ReorgCleanup' does not appear to be a git repository
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
with named arguments, there's no real effect (except maybe for readability), so it should be in its own section so you can rearrange among other named arguments but not before any positional arguments which always come first.
I would think that the rewrite would have to look at each individual call site, reorder the parameters, and if there are named parameters, either name all parameters, or name only those that come after the first named param for this call based on the new order.
Correct and that depends on finding the first named argument to divide the argument list into 2 logical sections, then see whether the reordering will need named or not, depending on how reorder should happen.
The problem is if I have (ByVal a, Optional ByVal b, Optional ByVal c). and my call site is "x", c:=7. then I reorganize the parms to (ByVal c, Optional ByVal b, Optional ByVal a). A simple reorg is c:=7, "x", but that won't compile
Well, you could either leave it as it is (they manually specified the original out-of-order position anyway), or you could reorder within the two sections.
Interesting: In my ToDo explorer settings, I've got @ since I was trying (unsuccessfully) to get it to pick up annotations to make them easier to find.
FWIW, I dislike several commas which makes for a confusing reading and even if there's only one comma, it is possible to create a seemingly valid call that still assigns wrong value to the parameter.
So, should I simply go with the following strategy: if there are named arguments, make them all named and drop missing arguments, if there are none, reorder the arguments?
So back to Max's question - if we are not going to normalize the calls, I think the best thing is to do the least impact, depending on the call sites. Meaning, we should prefer positional parameters whenever it is possible and failing that, name only what must be named, based on the new positions.
they should be put int a procedure or at least a tabled valued function
so at most, it'll be just a name & parameters, no more than that.
thinking about it further, I'm pretty sure I do have a repository class as to abstract out the mechanics of creating the parameters & naming the procedure/function
in my case I have parts of the logic that need to hit a linked server hosted on AWS. code only needs to care for 1 single connection string because everything happens in SPs. Otherwise I'd need 4 connection strings, and my life would be a nightmare
I'm trying to make a "Filter" button and have it aligned to the right of the column header, but for some reason it doesn't want to hear it and keeps sticking to the header text
I'm trying to make a "Filter" button and have it aligned to the right of the column header, but for some reason it doesn't want to hear it and keeps sticking to the header text
We do talk some about considerations that should go into the views & procedures. I can't remember off the hand if we include table-valued function because that is more SQL Server specific and the book is toward SQL standard.
@Cyril that's the thing - I have no problem making the button look like it's right-aligned if the table column can't be resized. But the user can resize it, and if I made it 100-wide, then it looks very very awkward if the user made the column wider, and even more wrong if the column was made narrower (gets clipped)
the infuriating part is that the popup does work
^ "x" button right-aligned as intended
going to leave the button left-of-heading and move on :)
> Version 2.4.1.16231 OS: Microsoft Windows NT 10.0.18362.0, x64 Host Product: Microsoft Office x86 Host Version: 16.0.12130.20272 Host Executable: EXCEL.EXE
**Description** If the user uses the Close button rather than the Cancel button to dismiss a refactoring dialog, the refactoring executes rather then cancelling.
**To Reproduce** Steps to reproduce the behavior: 1. Attempt to Rename or Encapsulate a field. 2. Click on the Close button 3. The code pane is updated with refact
VBA Rubberducking
VBA Rubberducking