I agree 100%.Rinzwind wrote:Thats the weak excuse we got, however each platform has its own specific ways/standards. Some should be considered “essential” for the platform, and as such included.
Because of this refusal, we get to reinvent the wheel or sometimes use untested or unstable code because theres also a lack of time tested open source third party libraries. macOS has plists (also not supported in any way, not even when compiling), Windows registry, Linux config files.
This stands alone from the fact that Im not a fan at all of the registry idea and execution. It can be quite a mess. Still, it should be supported. FreePascal has it too, which is a compiler that has more architecture targets than PB.
PBs official ecosystem has to grow, supporting each platforms uniquenesses.
Native Registry Support
Re: Native Registry Support
A+
Denis
Denis
Re: Native Registry Support
Try to think this thing throughRinzwind wrote: PBs official ecosystem has to grow, supporting each platforms uniquenesses.
Who's going to do that?
Who has access to the code and can make changes and extensions in high quality.
Is the effort in relation to the effect ?
What are the most important open construction sites that should have priority ?
On the page of FreePascal I see eight developers presented who work on it
It is not difficult to see that here the tail is wagging the dog !
地球上の平和
Re: Native Registry Support
If crossplatform is the reason why windows specific library can't be added, then the native like commands such as "GetTickCount_()" should be removed too.
poor English...
PureBasic & Delphi & VBA
PureBasic & Delphi & VBA
Re: Native Registry Support
Full agreement!!!Saki wrote:The discussion about this is rather pointless.
There are in itself only three criteria
1. suggest a feature and wait to see what, or whether something will come up over time
Asking more often is rather counterproductive, as experience shows. LOL
2. make a financial offer for the implementation
3. change the programming language if the desired feature is indispensable
Common program parameters can be created in a structure and stored in the user folder.
The read and write access can be done binary and is very easy to implement, this is then Multi OS.
OS specific access to the Windows registry is a completely different matter, just special.
Although I use Pb just for Windows and thus actually speak against myself, I consider a separate library for the registry as completely exaggerated:
- All registry accesses are guaranteed by Apis and are no science. This could perhaps be simplified a bit by a Pb support, but it doesn't change much.
- I cannot accept the argument that Pb also supports other operating system specific commands. These are additional commands to existing libraries, but not whole libraries that are only valid for one operating system.
- It is a bad habit anyway, that application settings are stored in the registry. They should be stored in an .ini, .prefs, .xml for whatever. These can then be used in other operating systems.
- 4) If anyone really wants to make changes in the system settings of the operating system, he should be familiar with the native Windows commands or better keep his hands off them.
sorry for my bad english
- NicTheQuick
- Addict
- Posts: 1227
- Joined: Sun Jun 22, 2003 7:43 pm
- Location: Germany, Saarbrücken
- Contact:
Re: Native Registry Support
That makes no sense. Why removing API calls?leonhardt wrote:If crossplatform is the reason why windows specific library can't be added, then the native like commands such as "GetTickCount_()" should be removed too.
At the moment it is not that hard to read from and write to the registry using the normal Windows API. I don't think a native implementation into Purebasic would make it any easier. And I guess since Windows 10 there will be no more big differences here.
The english grammar is freeware, you can use it freely - But it's not Open Source, i.e. you can not change it or publish it in altered way.
Re: Native Registry Support
Finally if I understand some of you, these functions must disappear because they aren't cross-platform?
So why were they added?
https://www.purebasic.com/documentation ... cific.html
The more "basic" the code is, the easier it will be for many coders to understand. Native functions are essential.
Removing non-cross-platform functions makes no sense..
DesktopFrequency
AudioCDLength
EjectAudioCD
RawKey
ClearConsole
ConsoleCursor
ConsoleLocate
ConsoleTitle
EnableGraphicalConsole
DragFiles
DragPrivate
DragText
GadgetItemID
MDIGadget
InitScintilla
KeyboardMode
GetFunctionEntry
CountLibraryFunctions
ExamineLibraryFunctions
LibraryFunctionAddress
LibraryFunctionName
NextLibraryFunction
MovieAudio
MovieInfo
MovieLength
MovieSeek
MouseWheel
UseJCALG1Packer
CocoaMessage
SelectedFontColor
ChangeGamma
ScreenID
GetSoundFrequency
SetSoundFrequency
SoundPan
ThreadPriority
ToolBarStandardButton
SetWindowCallback
SmartWindowRefresh
PdfVectorOutput
SvgVectorOutput
So why were they added?
https://www.purebasic.com/documentation ... cific.html
The more "basic" the code is, the easier it will be for many coders to understand. Native functions are essential.
Removing non-cross-platform functions makes no sense..
DesktopFrequency
AudioCDLength
EjectAudioCD
RawKey
ClearConsole
ConsoleCursor
ConsoleLocate
ConsoleTitle
EnableGraphicalConsole
DragFiles
DragPrivate
DragText
GadgetItemID
MDIGadget
InitScintilla
KeyboardMode
GetFunctionEntry
CountLibraryFunctions
ExamineLibraryFunctions
LibraryFunctionAddress
LibraryFunctionName
NextLibraryFunction
MovieAudio
MovieInfo
MovieLength
MovieSeek
MouseWheel
UseJCALG1Packer
CocoaMessage
SelectedFontColor
ChangeGamma
ScreenID
GetSoundFrequency
SetSoundFrequency
SoundPan
ThreadPriority
ToolBarStandardButton
SetWindowCallback
SmartWindowRefresh
PdfVectorOutput
SvgVectorOutput
A+
Denis
Denis
- Jac de Lad
- Enthusiast
- Posts: 106
- Joined: Wed Jul 15, 2020 7:10 am
- Contact:
Re: Native Registry Support
Just to get back to what I was asking for, I know I can access the registry via api and I also know how. I know it's not a big deal to create an include. I just think it's better to include it in PureBasic natively. It's just 4 or 6 functions in the end (read/write/exist/delete...).
Re: Native Registry Support
After using OS X and Linux, I find the Windows registry pointless and annoying for general applications. There's nothing you can put in the registry that you can not put/store in your own created file within your own application folder. Hiding registration keys or activation code in the registry is a joke. Also, I find it very annoying when you uninstall an app and its uninstaller doesn't clear out what it created in the registry. So I say, leave the registry alone and if you do create something in it, make sure your uninstaller cleans what your app or installer created.
www.posemotion.com
PureBasic Tools for OS X: PureMonitor, plist Tool, Data Maker & App Chef
Mac: 10.13.6 / 1.4GHz Core 2 Duo / 2GB DDR3 / Nvidia 320M
PC: Win 7 / AMD 64 4000+ / 3GB DDR / Nvidia 720GT
Even the vine knows it surroundings but the man with eyes does not.
PureBasic Tools for OS X: PureMonitor, plist Tool, Data Maker & App Chef
Mac: 10.13.6 / 1.4GHz Core 2 Duo / 2GB DDR3 / Nvidia 320M
PC: Win 7 / AMD 64 4000+ / 3GB DDR / Nvidia 720GT
Even the vine knows it surroundings but the man with eyes does not.
Re: Native Registry Support
@J. Baker
You mean like how OS X also leaves configuration files and caches laying around
You mean like how OS X also leaves configuration files and caches laying around
Re: Native Registry Support
As long as people program software, also OS, there will be errors.
Even crazy things.
Maybe one day artificial intelligence will free us from them.
Screwing with the Windows registry is not a good idea.
Now that we will stick to the concept of Win 10, the registry will never disappear again.
It is just a part of Win 10.
I don't think it's a good part, it's just too cluttered and opaque.
They say: "Many cooks spoil the broth".
It's also a fact that big companies start doing things that you think are controlled by the competition.
Are things or even states controlled by just one person,
everything stands and falls with this person and their views or even quirks;
For better or worse.
Even crazy things.
Maybe one day artificial intelligence will free us from them.
Screwing with the Windows registry is not a good idea.
Now that we will stick to the concept of Win 10, the registry will never disappear again.
It is just a part of Win 10.
I don't think it's a good part, it's just too cluttered and opaque.
They say: "Many cooks spoil the broth".
It's also a fact that big companies start doing things that you think are controlled by the competition.
Are things or even states controlled by just one person,
everything stands and falls with this person and their views or even quirks;
For better or worse.
地球上の平和
Re: Native Registry Support
What a discussion
The registry is simply a relevant part of the windows operating system infrastructure. Purebasic is a language which does currently not offer native support. It is simply a negative point on the checklist of somebody who compares programming languages. That this can be easily solved is something they would realize much later. The initial comparision matrix of purebasic and many other languages simply has a missing feature "native windows registry support". The lack of native windows registry support, may simply lead to less sales and use because of that.
For such a simple and tiny library addition.
The registry is simply a relevant part of the windows operating system infrastructure. Purebasic is a language which does currently not offer native support. It is simply a negative point on the checklist of somebody who compares programming languages. That this can be easily solved is something they would realize much later. The initial comparision matrix of purebasic and many other languages simply has a missing feature "native windows registry support". The lack of native windows registry support, may simply lead to less sales and use because of that.
For such a simple and tiny library addition.
Re: Native Registry Support
Guys, PB is multiplatform language, it means that it doesn't support all API or specific functions for all OS.
Registry is specific thing for Windows = nobody is limited to wrote own routines for it.
Not only for me are more important things to add to PB. At least support of AVR MCUs.
BTW: What is profit to use registry instead of separate configuration file?
Lukas
Registry is specific thing for Windows = nobody is limited to wrote own routines for it.
Not only for me are more important things to add to PB. At least support of AVR MCUs.
BTW: What is profit to use registry instead of separate configuration file?
Lukas
-
- Addict
- Posts: 2228
- Joined: Mon Jun 02, 2003 9:16 am
- Location: Germany
- Contact:
Re: Native Registry Support
I have no opinion on this topic, I just want to throw in that there is an equivalent on most linux systems: dconf/gsettings. Besides this, I could imagine a more generalized library in PureBasic: System Configuration library. Common tasks could be included like
CreateDesktopShortcut (registry in windows, freedesktop .desktop file on linux, dunno what on mac)
AssociateFileType (registry, mime database)
SetAudioVolume
Enable/RunService()
Shutdown()
Restart()
...
They aren't all using the registry, but they are common tasks changing system properties.
CreateDesktopShortcut (registry in windows, freedesktop .desktop file on linux, dunno what on mac)
AssociateFileType (registry, mime database)
SetAudioVolume
Enable/RunService()
Shutdown()
Restart()
...
They aren't all using the registry, but they are common tasks changing system properties.
bye,
Daniel
Daniel
Re: Native Registry Support
Josh wrote:It is a bad habit anyway, that application settings are stored in the registry. They should be stored in an .ini, .prefs, .xml for whatever.
J. Baker wrote:There's nothing you can put in the registry that you can not put/store in your own created file within your own application folder.
I wish people would stop saying that this is only about saving/loading our app data. It's not. As I said (twice now), access to the Registry is for reading and applying system settings that can't be done any other way.l1marik wrote:What is profit to use registry instead of separate configuration file?
I also like DarkDragon's idea of an enhanced System lib that can handle more generic PC settings.
Re: Native Registry Support
Interesting, which exactly do you want to change, name them !BarryG wrote: As I said (twice now), access to the Registry is for reading and applying system settings that can't be done any other way.
地球上の平和