Fred Slota

Call it "Review Mode".

Whether it's for confirming a pile of just entered comics, or confirming a pile of being sold comics, or flipping through the contents of a box (assuming in all three cases that you have things sorted appropriately) how about a mode that will auto-advance through a list? Minimize the list, maximize the cover view, you visually confirm each book to the screen and it moves on as you thumb through. Configurable with how long to pause. Configurable on how to handle list entries with quantities of more than 1; I can see having a single show with a single pause, or having it show multiple times; either way, with a big indicator on the screen showing "x5" or "1/6", "2/6", etc. I originally thought of this being voice controlled, "next", "back", etc., or just sound detection for advance like "The Clapper"

I don't know if I'm late to the party. but I think what the original poster is trying to point out in his graphic is that, while the window is announcing that "An update to version 22.0.1 is available", the section that is describing all the nifty new features appears to be describing the features of "ComicBase 2021 v21.0.1"

Doing a grand merge, noticed odd title alphabetizing, was going to append this to my earlier post, and I see that the odd alphabetizing will be mooted by correcting the titles. I looked at the indicia of all the above titles when I posted this originally.

Should be under Books. This book contains headshots and brief bios of Comic Book Creators.

Is there a way to package the weekly cover scan additions into a weekly zip file? Is there a date that could be checked for last update and the newer zip file(s) could be downloaded and imported? Would this process faster than the current apparently one-by-one download and add?

If you add with ComciBase mobile, you can append the date in the Notes field. After merging into a ComicBase database, you can search on this, or can transfer this to a Custom Field of your choice.

Add subfields of Series, Volume and Publisher to my above list, as these are also repeated information types that are included in FullTitles.

(sorry, hit Shift-Enter trying to make a new line, then took to long to edit the original... continues here) Title: The Dark Crystal Subtitle: A Discovery Adventure Creator: Jim Henson FullTitle: 'Dark Crystal, The: A Discovery Adventure (Jim Henson's...)' Title: The Bells Subtitle: Creator: Edgar Allen Poe FullTitle: 'Bells, The (Edgar Allen Poe's...)' Separated out, you can guarantee consistent formatting of the FullTitle. Separated out you can more easily deal with related title groups as a block, which might make for interesting reports broken down by Title versus FullTitle. Separated out, you can more easily group by Creator. Separated out, maybe you could consider Alphabetizing without using unimportant words in Subtitles (like leading 'The'). *ducks behind a crenelation to avoid the inevitable ensuing slings and arrows*

Data Structures 101... If you have a pattern in your data, and especially if you want to enforce consistency in the representation of the pattern, you should organize your data structure to control it and then generate a consistent presentation from that structure. I recently saw a reporting of non-standard Title naming being requested to be corrected. Things like: Dark Crystal, The: A Discovery Adventure -> Dark Crystal, The: A Discovery Adventure (Jim Henson’s…) and Bells (Edgar Allan Poe’s…), The -> Bells, The (Edgar Allan Poe’s…) Which leads to my probably unpopular suggestion Just like Item# (such as a potential Anl 1/A-2) is a presentational compound field built out of the more basic subfields of Type, Number, Variation and Printing, I suggest that Title should be transformed into a presentational compound field built out of the more basic subfields of Title, Subtitle and Creator. Title: The Dark Crystal

I was getting this error consistently a few weeks ago with Check for New Sales and Purchases. Was eventually corrected by emptying the %temp% directory in file explorer. Might give that a try.

Let me be clear. I hate, hate, hate, hate, HATE the mixed use of the Notes field. It requires programming contortions to support it and instead of allowing the maintenance of a clean, unified dataset across users, it produces local databases that either gradually diverge because old info is blocked from get updated with new, or that gradually bloat because old info is retained as new info is concatenated. Or worse still, info is never changed because HC doesn't want to cause the bloat in the first place. I understand how we got to this point. Evolution over time, expanded user base, entrenched system, maintain the status quo. I can understand the unwillingness to change this, because it would impact so many people and so many entries per person. But the willingness to continue to live with this, I don't understand. Doubly so if, by not just adding Grading Notes to the selling presented information (which makes perfect sense, a buyer would obviously want to know the condition of the offered item, if the info is available), you are telling me that Grading Notes "... is the recommended place for that kind of info [user-level descriptive info]." The first step has been taken. If this is the preferred place, than let's gradually proceed to make it the only place. Yes, the shift will make people unhappy. I sympathize. Do it gradually. Give warnings ahead of time. Provide voluntary tools that allow migration early. And eventually, bite the bullet and enforce with a mandatory shift that either automates the split or that grandfathers the original Notes field into a wholly local field alongside a new, clean, official Notes field.

If I'm understanding what you wrote... So, that middle field is [(Submitted notes) - (Official Notes)] concatenated with (Grading Notes)? To a non-seller, that was not clear. In practice, I'm glad that there is a full user or local field being used alongside Notes. Functionally and descriptively, I'm not sure that a field called "Grading Notes" is the best solo field to use. While I'm sure actual grading notes are useful for a prospective purchaser, I'm equally sure that there is additional information a seller wants to convey to a purchaser and that a purchaser wants to see that would not be considered "Grading Notes", and that there are people who take recording their grading information serious enough to not like having to multiplex it with additional selling details. If Grading Notes is to be the preferred field for AtomicAvenue display, is there a timeline for the removal of Notes from AtomicAvenue and the end to its mixed use in the database? As an interim step, is there a way to detect and generate a warning message to people posting sales that they are posting with modified notes? And I said warning message - a "The submission will work as previously, but you are using a datafield in a way that will eventually be discontinued in favor of xxxxx". Preferably before submitting, but possibly during or after? Or to send an e-mail when submissions are received? I'd picture this being implemented for a year or so, just as a warning, providing the seller a timeframe to be aware of the upcoming change and make adjustments. If AtomicAvenue is performing [(Submitted notes)] - (Official Notes)], could a tool be created that could be downloaded and run for the user to strip Notes modifications into a new or custom field, to aid the transition? I'd further imagine that this tool would be an automated part in a Comicbase Version update with underlying database version update, so that when Notes is finally stopped from its double duty, conversion of older databases would automatically separate out modifications from baseline.

So start the transition. Add the replacement fields, wait a year or two, and then BURN THE NOTES FIELD WITH FIRE!!! 😁 Seriously though. If Grading Notes is an equivalent to what I am suggesting, then good. It is hard to tell (for someone who doesn't sell), as AtomicAvenue is inconsistent in whether it labels columns in grids, so while I can see that there is user information provided in listings, I can't always tell what field that information is coming from. When I look at a grid in AtomicAvenue of issues for sale, I thought that the unlabeled column of data taking up most of the middle of the grid was from Notes. How does one see Grading Notes on an issue posted on AtomicAvenue?

Turn it off with a programmable setting, setting initially on for the new user?

While it might not always, I'd imagine that the Item Description would go a long way to answering the obvious question to be asked when looking at these reports, namely "Why are these comics on this list?"

I can use custom fields to hold information like that, but I can't get ComicBase to use them like that. I can type supplemental information to the Item Notes, Title Description and Item Description in Custom Fields I call Local Item Notes, Local Title Description and Local Item Description, but I can't get all the reports generated to include those fields merged with the Official fields for compactness and maintaining the current look and feel. I can't submit my Local Item Description to AtomicAvenue and have that information provided to the customer. And, this idea was not born out of wanting new fields for new information. I make this suggestion more than just a complaint about the current mixed-use Notes field, but as a positive solution to the current negative situation. ComicBase continues to not just support the Notes field as a mixed-use field for legacy purposes, they continue to require it to be used in this way as the only method for AtomicAvenue users to convey how their copy for sale of Shanda the Panda #123/A-2 is different from all the other solicitations. Because the official and the local information is inseparable in the current implementation, they are hesitant to make changes to the official. Because the official and the local information is inseparable, when they make changes those have to be rolled out by concatenating new info onto old. They are maintaining a Database where every record has a field that is an unreconcilable crowd-sourced document co-authored by every user of the software. This implementation would be a lot simpler for new users to learn, for continuing users to use, and for ComicBase to code for and support.

1) Okay then, bold font. 2) I don't know that you can't use different colors in columns as in rows... blue rows for ownership and pink columns for local fields, with purple cells for overlaps. 3) the fonting/coloring could also be applied to the headers I'm trying to suggest a way to better inform the user at the point of deciding to make edits, not at the point of downloading updates. Warning before the data is overwritten, while friendlier than no warning, is too late. Warning before entering data that could be overwritten is better.

Thought for a brief segment on the next ComicBase TV... Dissection of a UPC code. Current practices, past practices, compare and contrast how different publishers handle them...

First, let's get the distractors out of the way... Most typical cases, it doesn't make any difference where the setting is, at the program level or at the database level. The basic user with the default install never touches it. The user with multiple databases all pointing to the official store, as long as the setting is consistent/is copied across all databases, doesn't care. The common computer with multiple users, again as long as the setting is consistent/is copied across all databases, doesn't care. For the user who relocates the storage location, it's slightly more convenient immediately after the relocation that the setting is at the program level and not the database level, as if at the database level, that user would have to adjust the stored location in each pre-existing database. But, once that adjustment has been made, new and copies of databases would carry that new location over. The main usage case is for those people who have multiple different picture stores. For those who do, why do they have them? Those who do have multiple picture stores because they find a reason to have more than one. Meaning, they have times when they will be switching between them. For this purpose, at this time, I want to interact with picture store 1. For this other purpose, at this other time, I want to interact with picture store 2. Now, maybe these people have specific, discrete, separate databases that they associate with the different picture stores; For example, a personal databaase matched with personal scans vs. an online sales database with sales scans vs. a purchasing database with official scans. These people definitely associate database -> picture store. With sidekick, it doesn't matter how many different databases you maintain - it can automate weekly updates on multiple databases. They load database 2, and switch to picture store 2. They load back to database 1, and switch back to picture store 1. and if they forget, things go wrong. That leaves the people who maintain a single database and flip back and forth between the separate picture stores as they perform the different tasks that they feel require the different picture stores. They could maintain separate databases, but since they have to switch stores anyways, why bother? Well, for this I remind you of what currently happens when you change picture storage locations. Picture references are cleared. Whether flipping back and forth on a single database, or pointing custom database to custom picture storage location, picture references are cleared. And, depending on what you're trying to do with the database with the different picture storage location, that probably means that you have to run Rebuild Pictures. Every time. If the setting was at the database level, after you set a database up with a new location and rebuilt pictures, you wouldn't have to rebuild pictures every time you changed between databases that used different picture stores. Currently, it doesn't matter whether you use separate databases or a single database; you swap between picture stores, you probably need to rebuild picture references with each swap. If the setting was moved to the database level scope, users with multiple picture stores would maintain separate databases for separate stores, and would never have to run Rebuild Pictures when swapping between different tasks/databases. And again, anyone who uses a single picture store would pretty much never notice and never care.

How about the ability to use custom Media? Either provide a fourth hard-coded Custom Media table, or the ability to add multiple Custom Media tables (which, if not provided, a user who really wanted to could simply make multiple databases to have access to multiple Custom Media tables.) This table would not be involved in user submissions to the Master database. This table would not be modified by Content updates. This table would not be involved in AtomicAvenue. This table could be used for report generation. Use it to track card collections. Poster collections. Record Collections. Pogs. AtomicAvenue SWAG.

Color Code the grids and data entry screens to show which fields can/will be overwritten by data updates. I would prefer the color coding to be the background of the cells, but could also be bold vs. regular font or colored vs. black font. Either a third style/shade could be used for those that are optional (cover date, Creators, etc), or the current/last used setting could just be reflected on those fields. For those who say "Eww, I know which fields are which, I don't like this change, it's ugly.", provide a programmable setting that will turn off this feature. But, make this feature default on for new databases, so that new users will see this detail and understand that while all fields can be changed, not all fields will retain these changes.

Let's clear up this public/private Item Notes nonsense and extend the capabilities while we're at it. Official Item Notes, Title Description and Item Description are under the control of Human Computing. A user modifies these with the intention to submit changes. These fields are transmitted up with submit changes. These fields can and will be overwritten by content updates. Local Item Notes, Title Description and Item Description are under the control of the user. A user modifies these for their own purposes. These fields are not transmitted up with submit changes. These fields will not be overwritten by content updates. In the grid, these will be separate columns/fields. In reports, you can choose whether to show Official, Local or both, and if both, they will be concatenated. Sellers in Atomic Avenue would post with their Local Item Notes/Item Description. AtomicAvenue grids at the title level will show Official Notes and Descriptions in the grid. AtomicAvenue grids at the issue level will show individual sales with their submitted Local Notes and Descriptions.

Update this week, Total comics 1,004,310, delta 864, 2M in 22+ years.... What, did Vampirella not come out last week?

I think that a part of the Find process is acting on the media you were browsing before changing to the media that you selected in the Find dialog. In my initial post, look at the first two scenarios BrowseMag/FindMag vs. BrowseComic/FindMag. I had requested to sort on ComicTitles.AlphabetizedTitle. That raised an error and died in the first scenario (Browse selected Mag), while it did not raise an error (Browse selected ComicBook) but did switch media to Magazine and loaded a list of all the issues of the currently focused Magazine. I'm thinking something like this... The search is done on the Browse media selection, not the Find Media selection. Scenario 1, throws an error (Comic term on Magazine data), and the process stops right there, leaving you back at the original browsing view. Scenario 2, I think the search actually happens as I thought was going to happen without error (Comic term on Comic Data), but then it wants to display in the Find Media context. The media is switched from Comic to Magazine, and instead of showing the Comic search result that was run, it tries to show a Magazine search result (which wasn't run), and ends up showing as a search result the last set of Magazine entries displayed, which was the last browsed set of issues.