I often get this error:
mtScrollContainer: Run-time error '380': Invalid property value.
How to solve?
If I do the compare in many chunks (starting at only looking at the largest files, then going down in filesize) instead of one go, it often helps. But that takes a _lot_ more work and time, days instead of hours.
Run-time error: 380 Invalid property value
Run-time error: 380 Invalid property value
Last edited by undupit on 07 Jan 2026, 12:38, edited 2 times in total.
-
Administrator
- Site Admin
- Posts: 4139
- Joined: 04 Oct 2004, 18:38
- Location: Thailand
- Contact:
Re: Run-time error: 380 Invalid property value
We need the complete bug report to help you with this error.
What version of AllDup do you use?
What version of AllDup do you use?
Re: Run-time error: 380 Invalid property value
4.5.64 PE.Administrator wrote: ↑02 Feb 2025, 07:34 We need the complete bug report to help you with this error.
What version of AllDup do you use?
Next time doing a large compare, I'll check if I can set log options and create a log.
Re: Run-time error: 380 Invalid property value
And just what type of search are you performing?
And what settings are you using for that search?
And what settings are you using for that search?
Re: Run-time error: 380 Invalid property value
File content, Byte by Byte compare. Match 100%.
No options ticked under Byte by Byte. Block size etc: 32768, and other defaults.
Search options: all unticked, except CPU to low priority.
Archive files: do not extract if larger than 0 bytes.
Database: Use database... = unticked. File filter: not used. Exclude: smaller than 10 kB.
Folder filder: exclude recycle bin, c:\windows, and other default exclusions.
I did not see a way to enable logging other than what is does by default, or change the settings. Is that correct, there are no (special) (debug) settings?
Re: Run-time error: 380 Invalid property value
(Not that I know about such things) but on reading "invalid property", so I'm thinking you're gather "properties" (meta-data) from say picture files, & something there is causing the issue.
But given that you're just doing a plain jane content search, then you'd think, well the above thought then doesn't make sense.
So google (& again I don't know if it applies) but points out things like "controls" & "sizing"...
What causes this error? "Runtime error 380: Invalid property value"
So... maybe it could be something like you've got a "4k" monitor & ... (I'm just throwing stuff out
).
Anyhow, at what point in time does the issue manifest itself?
Not when you simply open AllDup, but at what point in the process?
But given that you're just doing a plain jane content search, then you'd think, well the above thought then doesn't make sense.
So google (& again I don't know if it applies) but points out things like "controls" & "sizing"...
What causes this error? "Runtime error 380: Invalid property value"
So... maybe it could be something like you've got a "4k" monitor & ... (I'm just throwing stuff out
).Anyhow, at what point in time does the issue manifest itself?
Not when you simply open AllDup, but at what point in the process?
Re: Run-time error: 380 Invalid property value
I don't use meta-data search options.
At the step where the byte-by-byte comparisons are made.Anyhow, at what point in time does the issue manifest itself?
If I click on log, I see there are _no_ entries added. So, the program exits without writing anything to the log.
The last entries visable, are from when the program _did_ succesfully a dupe search run.
I still suspect it's some kind of overflow, built-in limits, maybe too many stuff/entries written to the comparing database, being the database in memory, not on file.
Therefore (my PC is probably powerful enough), i'd like to see a version of AllDup which can hold (10x) more data / larger data fields.
Or maybe there is somewhere an integer being used, so it overflows at 2^15 (32768).
Last edited by undupit on 23 Apr 2025, 05:03, edited 2 times in total.
Re: Run-time error: 380 Invalid property value
I'm out of ideas.
Do I have to give up?
Do I have to give up?
Re: Run-time error: 380 Invalid property value
Another thing: when either error 380 or 440 or another error is thrown (I don't know which one), the error popup is one micro second visable, and than disappears, as well as the program disappears.
Can the program written in such a way that the error always stays visable until the user clicks on 'Ok'?
And that errors are written to an error log file? I found error.log, but the last error I had (error 440) is not in it. The program probably exits before it has the chance to write error information to it.
Can the program written in such a way that the error always stays visable until the user clicks on 'Ok'?
And that errors are written to an error log file? I found error.log, but the last error I had (error 440) is not in it. The program probably exits before it has the chance to write error information to it.
Re: Run-time error: 380 Invalid property value
Recently, I saw an approx. 15..30-line empty filename in the search results. That is: instead of a filename, it showed an extremely large empty field. Asking GPT about this, it says:
[[[
That symptom is directly related, and it is the same underlying bug class. What you are seeing is layout/state corruption inside the result list, and mtScrollContainer is part of that chain.
# What the “~20-line empty filename” actually is:
It is not an empty filename.
It is a row whose text pointer or layout height is wrong, so the control:
Reserves vertical space (≈20 text lines)
Has no valid string to render
Still counts the row in layout calculations
Visually: a tall blank entry.
Internally: a record with invalid or uninitialized display data.
#How this links to runtime error 380:
1. Invalid row height → invalid content height
When one result row suddenly has a huge height:
ContentHeight += RowHeight // RowHeight is wrong
Now the scroll container believes the content is much taller than it really is.
Later, when layout is recomputed or the window resizes:
ScrollMax = ContentHeight - ContainerHeight
If the row height later collapses back (or is recalculated differently), that value can become negative or inconsistent → error 380.
2. String buffer / pointer failure:
AllDup is VB6 and uses:
*Fixed-length strings
*API calls
*Possibly owner-drawn list rows
If the filename string is:
*Not initialized yet
*Overwritten
*Temporarily empty due to timing
The row still exists, but its text is missing. The UI logic still measures its height, but with bad input.
3. DPI + font metrics magnify the problem:
VB6 row height is often calculated using:
TextHeight("X")
If DPI scaling changes:
*Row height calculation differs per run
*Blank rows can become very tall
*Scroll math becomes unstable
That is why the blank row is often around 15–25 lines, not random.
4. Same cause, different symptom:
Symptom / / Root cause:
Runtime error 380 // Invalid scroll range / size
Tall empty row // Invalid row data / height
Intermittent // Timing + DPI + resize order
They occur independently or together depending on when the layout recalculation hits bad state.
#Why it happens with identical searches:
Because:
*The result data is correct
*The UI layer misprocesses one row during population
*That corrupts layout math
Nothing in the filesystem or search result itself is broken.
#Why this confirms it is a UI bug:
A filesystem or parsing bug would produce:
*Wrong filenames consistently
*The same file missing every time
A UI/layout bug produces:
* Random rows affected
* Different behavior per run
* Visual artifacts tied to scrolling
Which is exactly what you observe.
#Practical implication:
When you see the tall empty row, the UI state is already inconsistent. At that point, a later resize, scroll, or redraw can easily trigger runtime error 380.
#Final conclusion:
Yes — the blank ~20-line “filename” and the intermittent mtScrollContainer runtime error 380 are manifestations of the same underlying VB6 ActiveX layout bug, caused by invalid row data and unstable scroll calculations under modern Windows DPI and timing conditions.
]]]
Having said that, I hope the creator of the software can look into this. If GPT is speaking the truth, and if so, if he can do something to prevent error mtScrollContainer 380.
[[[
That symptom is directly related, and it is the same underlying bug class. What you are seeing is layout/state corruption inside the result list, and mtScrollContainer is part of that chain.
# What the “~20-line empty filename” actually is:
It is not an empty filename.
It is a row whose text pointer or layout height is wrong, so the control:
Reserves vertical space (≈20 text lines)
Has no valid string to render
Still counts the row in layout calculations
Visually: a tall blank entry.
Internally: a record with invalid or uninitialized display data.
#How this links to runtime error 380:
1. Invalid row height → invalid content height
When one result row suddenly has a huge height:
ContentHeight += RowHeight // RowHeight is wrong
Now the scroll container believes the content is much taller than it really is.
Later, when layout is recomputed or the window resizes:
ScrollMax = ContentHeight - ContainerHeight
If the row height later collapses back (or is recalculated differently), that value can become negative or inconsistent → error 380.
2. String buffer / pointer failure:
AllDup is VB6 and uses:
*Fixed-length strings
*API calls
*Possibly owner-drawn list rows
If the filename string is:
*Not initialized yet
*Overwritten
*Temporarily empty due to timing
The row still exists, but its text is missing. The UI logic still measures its height, but with bad input.
3. DPI + font metrics magnify the problem:
VB6 row height is often calculated using:
TextHeight("X")
If DPI scaling changes:
*Row height calculation differs per run
*Blank rows can become very tall
*Scroll math becomes unstable
That is why the blank row is often around 15–25 lines, not random.
4. Same cause, different symptom:
Symptom / / Root cause:
Runtime error 380 // Invalid scroll range / size
Tall empty row // Invalid row data / height
Intermittent // Timing + DPI + resize order
They occur independently or together depending on when the layout recalculation hits bad state.
#Why it happens with identical searches:
Because:
*The result data is correct
*The UI layer misprocesses one row during population
*That corrupts layout math
Nothing in the filesystem or search result itself is broken.
#Why this confirms it is a UI bug:
A filesystem or parsing bug would produce:
*Wrong filenames consistently
*The same file missing every time
A UI/layout bug produces:
* Random rows affected
* Different behavior per run
* Visual artifacts tied to scrolling
Which is exactly what you observe.
#Practical implication:
When you see the tall empty row, the UI state is already inconsistent. At that point, a later resize, scroll, or redraw can easily trigger runtime error 380.
#Final conclusion:
Yes — the blank ~20-line “filename” and the intermittent mtScrollContainer runtime error 380 are manifestations of the same underlying VB6 ActiveX layout bug, caused by invalid row data and unstable scroll calculations under modern Windows DPI and timing conditions.
]]]
Having said that, I hope the creator of the software can look into this. If GPT is speaking the truth, and if so, if he can do something to prevent error mtScrollContainer 380.
Re: Run-time error: 380 Invalid property value
GPT says for the software code to prevent runtime error 380 in mtScrollContainer (underflow and overflow):
1. Container size/position: Width, Height, Left, Top – must be > 0 and not excessively large
2. Scroll: ScrollTop, ScrollLeft, ScrollMax – must stay within valid range (0 ≤ ScrollMax ≤ control maximum)
3. Child controls / content: heights must be ≥ 0 and not excessively large; handle empty rows safely
4. Layout / resize / timers: validate all calculations before assigning to scroll or size
5. Text/row heights: use default height if string is empty/missing, and cap at reasonable maximum
6. Assign properties only after control is fully initialized
7. Watch for timing/DPI differences that change dimensions between runs
According to GPT, I have to wait to 2035 or longer, so that GPT can create an AllDup clone itself.
(If GPT can compete with Gemini.)
1. Container size/position: Width, Height, Left, Top – must be > 0 and not excessively large
2. Scroll: ScrollTop, ScrollLeft, ScrollMax – must stay within valid range (0 ≤ ScrollMax ≤ control maximum)
3. Child controls / content: heights must be ≥ 0 and not excessively large; handle empty rows safely
4. Layout / resize / timers: validate all calculations before assigning to scroll or size
5. Text/row heights: use default height if string is empty/missing, and cap at reasonable maximum
6. Assign properties only after control is fully initialized
7. Watch for timing/DPI differences that change dimensions between runs
According to GPT, I have to wait to 2035 or longer, so that GPT can create an AllDup clone itself
.(If GPT can compete with Gemini.)
Re: Run-time error: 380 Invalid property value
Gemini thinks it's a race condition problem within (or is triggered by) the mtScrollContainer.ocx logic during its interaction with the Windows UI thread. It advices to set CPU priority to high for AllDup. But: that didn't help. Full:
"The "Race Condition" in Error 380 happens because the scanning engine (worker) is often faster than the interface (UI). If the engine pushes a data update while the UI is stalled by Windows, the property calculation fails.
Setting AllDup to "Low" (Internally): Slows down the "pusher" (the scanning engine).
Setting Windows to "High" (Externally): Speeds up the "drawer" (the UI thread).
This creates a "buffer" where the UI always has enough CPU time to finish drawing one set of results before the engine pushes the next one, preventing the invalid property crash"
"The "Race Condition" in Error 380 happens because the scanning engine (worker) is often faster than the interface (UI). If the engine pushes a data update while the UI is stalled by Windows, the property calculation fails.
Setting AllDup to "Low" (Internally): Slows down the "pusher" (the scanning engine).
Setting Windows to "High" (Externally): Speeds up the "drawer" (the UI thread).
This creates a "buffer" where the UI always has enough CPU time to finish drawing one set of results before the engine pushes the next one, preventing the invalid property crash"