Live data from Hacker News

Lightweight SQLite Editor for Windows

github.com

71–80 of 114 posts

Re: Lightweight SQLite Editor for Windows

#71

Earlier quoted context omitted.

Nope, you get the pleasure of implementing dpi support yourself. https://building.enlyze.com/posts/writing-win32-apps-like-it...

Thanks for the link. Glancing at it, I still don't see where there's a need to patch system controls for high DPI support, though. The closest thing I see there is for changing their fonts, but that seems different from patching them (no superclassing that I can see, etc.). Moreover, it's for dynamic DPI support (i.e. supporting DPI changes), not high DPI support. Is that what you were referring to?

I think you should try a plain win32 program on a high dpi and just see for yourself.

Re: Lightweight SQLite Editor for Windows

#72

Earlier quoted context omitted.

Thanks for the link. Glancing at it, I still don't see where there's a need to patch system controls for high DPI support, though. The closest thing I see there is for changing their fonts, but that seems different from patching them (no superclassing that I can see, etc.). Moreover, it's for dynamic DPI support (i.e. supporting DPI changes), not high DPI support. Is that what you were referring to?

I think you should try a plain win32 program on a high dpi and just see for yourself.

That's not exactly a... helpful answer. In fact I already have a Win32 (dialog-based, if that makes any difference) one that looks just fine on 200% DPI on Windows 10. All it required handling was scaling the obvious stuff (icon sizes, overall window size, etc.) and the manifest, nothing that required superclassing or otherwise patching common controls. i.e. I just haven't run into the problem you're mentioning. I'm kind of confused why you linked to an article that doesn't support your claim either. Hence why I'm asking you instead of spending hours trying to reproduce what you're saying.

Re: Lightweight SQLite Editor for Windows

#74

Earlier quoted context omitted.

I think you should try a plain win32 program on a high dpi and just see for yourself.

That's not exactly a... helpful answer. In fact I already have a Win32 (dialog-based, if that makes any difference) one that looks just fine on 200% DPI on Windows 10. All it required handling was scaling the obvious stuff (icon sizes, overall window size, etc.) and the manifest, nothing that required superclassing or otherwise patching common controls. i.e. I just haven't run into the problem you're mentioning. I'm…

I don't know why you assume I'm here to give you helpful answers, but I'll bite.

Try a combo box on high dpi. The arrow button gets a lot thinner than on 96 dpi.

Re: Lightweight SQLite Editor for Windows

#75

Earlier quoted context omitted.

That's not exactly a... helpful answer. In fact I already have a Win32 (dialog-based, if that makes any difference) one that looks just fine on 200% DPI on Windows 10. All it required handling was scaling the obvious stuff (icon sizes, overall window size, etc.) and the manifest, nothing that required superclassing or otherwise patching common controls. i.e. I just haven't run into the problem you're mentioning. I'm…

I don't know why you assume I'm here to give you helpful answers, but I'll bite. Try a combo box on high dpi. The arrow button gets a lot thinner than on 96 dpi.

I didn't assume you'd give a helpful answer, but I didn't expect you to give that kind of an answer, either. You're always welcome not to respond if this is taking too much of your time. I figured maybe at least one of us would learn something about high DPI issues, hence why I engaged.

And I did just try what you said and the combo box fine to me: https://imgur.com/a/Mb83tPj

Re: Lightweight SQLite Editor for Windows

#76
It’s funny but I only just had this thought: in the dark ages of text editing we would use ed to write commands that edited line by line, and then another command to show the changes.

What a chore! Enter vi where you can see a window into large parts of the file while editing it at the same time. It was a quantum leap in productivity for sure especially because I could work form a terminal (as opposed to jumping to a different system more geared towards word processing etc.)

But for SQLite databases I am somehow still fooled into thinking I am content, when in a terminal, to issue INSERT/UPDATE commands to make changes and SELECT commands to see those changes is adequate.

If this is the equivalent of ed…

  > sqlite3 my.db
  UPDATE table …
  SELECT …
…and if this post is linking to a GUI equivalent of Microsoft Word 6.0, then is there instead a vi equivalent for editing database tables, and what is it?

Re: Lightweight SQLite Editor for Windows

#77

Earlier quoted context omitted.

I don't know why you assume I'm here to give you helpful answers, but I'll bite. Try a combo box on high dpi. The arrow button gets a lot thinner than on 96 dpi.

I didn't assume you'd give a helpful answer, but I didn't expect you to give that kind of an answer, either. You're always welcome not to respond if this is taking too much of your time. I figured maybe at least one of us would learn something about high DPI issues, hence why I engaged. And I did just try what you said and the combo box fine to me: https://imgur.com/a/Mb83tPj

That is not the default Win32 combobox. I don't know what you're using, but it's not the plain c api.

Re: Lightweight SQLite Editor for Windows

#80
post #78

I believe I speak for everybody when I say that win2k was the best UI. So...is that demo gif running on win2k?

Not necessarily Windows 2000. It might be Windows 7 or Windows XP with classic theme as well (or Windows Server 2003-2008, either R2 or non-R2).
Post reply on HN