Christopher Mayo's dashboard

Yes. I have been using it for about a month now with Windows 7 (Starter). No problems at all.

Thanks digitaldoctor. It took several days, but I made the shift from OneNote to BladeWiki a month or so ago. I had been using them both separately until that point. To reiterate what I said above, BladeWiki is infinitely less troublesome to use. Files are small, easily backed up, and best of all, everything is in txt, so quickly searchable and I'll never have to worry about future compatibility issues. – Christopher Mayo, on November 28, 2009 07:49

Indeed. We can drag images. I had no idea until I fiddled around with it (in Edit mode)! Would be cool if the links would adjust themselves, but in the meantime, I'd still keep the files in one location.

I wasn't aware that we could drag pictures. My version of bLADE Wiki doesn't support such a feature.

I prefer to keep my bLADE Wiki files separate from other stuff. That way everything remains easily portable and searchable. I have a large number of pdf, word, jpeg, and other files linked to my bLADE Wiki pages, though. If I take notes on a journal article, I link to a PDF of the article so I can review it again if I want to.

Because I move between computers and find it rather cumbersome to carry all of my files with me every time (I am up to about 100GB of linked files), I only move the bLADE Wiki files around on a regular basis. The rest of them I save to my C: drive in a folder called "Archived". I move this around once a week or so. The file is in the same location on all of my computers, so the links work fine. Basically, the key (in my opinion) is to create a single, stable location for all of your linked files.

And, since every file I save has a unique file name, I don't accidentally write over important stuff when I move the "Archived" folder around. I have found this to be extremely nice. One of the great features about bLADE Wiki is that there is no cache folder with these linked files. When I tried linking OneNote to files it created a cache and soon I could not move it around anymore. Very, very frustrating.

I hope this helps!

Thanks Julio! I had misunderstood the nested features function. I have split the index page into 26 pages (one for each letter) and I have a nested page link for each of them in the index page. I think this will work after all. With the new 64k page limit I doubt any of the sub-pages will have any problems for some time to come.

@Julio

Good points! I probably do not represent a large number of people. And, I would like to stress that I am using a workaround now (editing Notepad outside of BladeWiki) that solves the problem. I would only like to see the option to increase page sizes if it was not too much trouble for Dale.

Perhaps some background is in order. I have tried out dozens of wiki-type programs in the hope of finding an application that functions as well as VoodooPad for Mac. Alas, it does not seem to exist. They all have some kind of flaw (no unicode support, etc.) or less robust features (automatic linking of terms, search capability, etc.). For a while I tried OneNote and was pretty pleased with it, even though it also fell short of VoodooPad. Over time, however, it gobbled up huge chunks of memory and became too large to easily transfer from computer to computer. Specifically, links to PDF / WORD files caused it save those files in a separate cache that quickly grew unwieldy and kept trying to come along with it. Very, very frustrating. It also cost an arm and a leg.

I am a historian and BladeWiki is definitely the best program out there (in my opinion) for my work. I can easily take notes on all the historical source materials, secondary works, and my own ideas in a format that is easily searched and moved about from computer to computer, because this is one of the few programs that saves the files in text format and provides support for unicode. Most of my work is in Chinese and Japanese, and I have no problem using these files. BladeWiki has quite literally revolutionized how I do my work. No longer do I have hundreds of WORD files (the way I did things a few years ago). Now it is all tight, compact, and user-friendly.

I am EXTREMELY grateful to Dale for making this product, and I would gladly pay for it if it were commercially distributed. Thanks Dale!

Thanks Julio. In the other thread Dale mentioned that he is unlikely to make an unlimited size, because it would affect mobile performance. That sounds fair.

However, I suggested the ability in the menu to specify the page size (somewhere between 32KB and 32MB) so that users could tailor it for their platform and needs (mobile users smaller, netbook users like me larger). That would certainly be ideal. Better to be flexible than force everyone into the same Procrustean bed. I envy you guys with the mobile app, but since I have an iphone, I cannot use it that way.

Several of the .NET classes used internally by the app require a limit to be set.
===>Thanks for explaining this. I was not sure what the rationale was for the limit.

I could just pick some random very-large number, but I'm reluctant to do this... largely because I use this primarily as a mobile app, and I don't want the app to allocate big chunks of memory for handling large strings.
===>That makes sense. I am using this on my netbook (I have an ipod, so cannot use it there) so I have different needs.

I guess I could try and workaround this by providing some way to modify this on the fly - so if you do something that would exceed the limit, modifying all of the runtime classes to set a new maximum. This would be a less trivial piece of work. Something to think about, but not something that I've got time for at the moment, sorry.
===>Understood. My workaround (editing the files in Notepad) will work for now.

It would be nice if there was a setting in the menu so that we could modify it ourselves (like the nested page limit--we can modify this from 0 to 9) to have file sizes ranging from say 32kb to 32mb. That way users could modify it based on the platform they are using.

Alternatively, maybe we could have different versions for the laptop and mobile device, though I suspect this would simply mean more work for you.

Would you be willing to consider increasing the number of nested pages we could include?

@Julio

If I understand correctly, I would have to first divide my index into 26 pages (a-z) total. I would then make three main pages with 9 nested pages inside each (a-i), (j-r), (s-z).

It's possible, of course, but I could not print out the entire index on one page (I would have to do three), I could not view them all at once, and editing the index (adding and removing information) would require a little more work (26 files instead of one). I'll think about it. At this point, though, it is easier to just keep editing the index page in notepad and use it (the links and so forth) in BladeWiki.

Or, I could divide my index into 9 pages with three letters each (as you suggested) and nest them all onto one page. That would solve the printing and viewing problem, but maintaining them would still be a pain. I will think about it.

Ideally there would be no page length limit and I could edit the file inside BladeWiki.

Thanks Dale!

But, I wonder if you could completely remove the limit. I posted on the "Pages longer than 32K cannot be edited" page this message. It pretty much summarizes my problem. Basically, I am loathe to separate my index page into smaller ones.

------------------

@Julio

Good point. The inner pages link feature would be a great fix for this, except that I have the pages in alphabetical order and would need 26 inner page links. Bladewiki only supports 9. So, there is a limit on it as well.

I've got about 400 pages total of information right now (all but a few much smaller than 32k) and I have one page to index them all (about 67k now and growing). It is difficult to see how I would split up this index page. If I split it up into 26 separate index pages (the most obvious solution) it would be impossible to see everything at one glance, much less print it out on occasion.

Ideally, the size limit on pages would be removed entirely. But, if Dale could give us more innerpage links, that would solve the problem as well.

@Julio

Good point. The inner pages link feature would be a great fix for this, except that I have the pages in alphabetical order and would need 26 inner page links. Bladewiki only supports 9. So, there is a limit on it as well.

I've got about 400 pages total of information right now (all but a few much smaller than 32k) and I have one page to index them all (about 67k now and growing). It is difficult to see how I would split up this index page. If I split it up into 26 separate index pages (the most obvious solution) it would be impossible to see everything at one glance, much less print it out on occasion.

Ideally, the size limit on pages would be removed entirely. But, if Dale could give us more innerpage links, that would solve the problem as well.

@Dale

Thanks for the change!

But... I have a 67k page (index of all my pages--continues to grow). Is there any possibility we could set the limit. Or, could we have an unlimited size. 99% of my pages are well under 32k, and only a couple go over 64k, but it would still be more convenient to keep this index page all together.

Wonderful! Thank you so much. I am looking forward to the new version :)

Thanks for the answer! If you can get them to link correctly, I can live with their illegibility :)

I don't know why the links don't work. Please paste in [我的檔案] and see what you think.

Here is what I do know:

(1) The text file name is: %E6%88%91%E7%9A%84%E6%AA%94%E6%A1%88.txt
(2) The html file that it is trying to link to has extra numbers: %25E6%88%91%25E7%9A%84%25E6%AA%94%25E6%A1%88.htm
(3) The actual htm file that exists is named the same as the text file:%E6%88%91%E7%9A%84%E6%AA%94%E6%A1%88.htm
(4) Pasting the actual html file name into the browser does not take me to the page either. However, it does display the proper Chinese characters: 我的檔案.htm

Those were the results with Firefox and Chrome. With Explorer it is worse, because it tries to link to: %E6ˆ‘%E7š„%E6a”%E6¡ˆ.htm

I do not know exactly what happens, but it seems that bLADE Wiki is turning foreign language page titles into English letter/number combinations that only it is capable of interpreting instead of creating new pages with titles using the appropriate unicode characters.

If I create a page called "my file" bLADE Wiki creates a text file named "my%20file.txt," but if I create a page with the same name in Japanese (no spaces) "マイファイル" or Chinese "我的檔案" the text file is named "%E3%83%9E%E3%82%A4%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB.txt" or "%E6%88%91%E7%9A%84%E6%AA%94%E6%A1%88.txt." If they followed the same format as the English, because they have no spaces, they ought to appear as "マイファイル" or "我的檔案".

This is a big problem if I want to locate the text file in my folder, but fine as long as I am running bLADE Wiki. I can link to the files and they are displayed properly within the program. If I have a block of text in Chinese or Japanese and make a word into a link (creating a new page) I can follow it without problem and the name of the file (in the top left corner of the display) is correct.

However, if export my wiki to html the links do not work correctly. The links display correctly in Japanese or Chinese on the browser page, but I cannot go to the pages they are linked to. And, of course, it is very difficult to locate the html file on my own because it has one of those unwieldy and cryptic names.

Any chance that this problem can be solved?

Thanks for the reply!

RE: "Wikiwords."
That's too bad, but I understand. I am using it on a desktop and laptop and was not thinking much about the impact on performance this would have. If we could turn the feature off and on, maybe this would please everyone?

RE: "Tree structure hierarchy."
I had in mind a more visual representation of the wiki locations and their files that would allow me to drag and drop files from one location to another. But, after reading what you wrote, I can see that isn't necessary. With separate wiki locations we already have our main categories, and we can just cut and paste files from one folder to another if we would like to move them around. Please disregard this suggestion--it is fine the way it is!

RE: "Grep" search capability
Currently the search function only returns page names. If a word occurs in several pages, then you have to go into each one and look for it. Ideally, I would like to see:
(1) the search display the page name with a snippet of text containing the search term. This alone would add a lot of functionality.
(2) the ability to search for variants in text strings, A(B or C)D or (Not A or B)C

Thank you! I took a look at the discussion. Did you make any decision on allowing larger pages? Is there any chance that we could have control over the maximum page length? I tend to work with larger files and prefer not to split them up.