|
Post by xxgeek on Dec 13, 2022 22:49:35 GMT
on error goto [restart]
'with [restart] run DefaultDir$;"\c-jbsearch.exe" if resultsIsOpen then close #results close #main end
Should work as long as the dll's sll's and jbrun2.exe and c-jbsearch.tkn are copied to DefaultDir$, and jbrun2.exe is renamed to c-jbsearch.exe.
I tried it by sending it to [restart] if searchFor$ = "" and it worked
So if 2 copies of the app are made with 2 different names, one can start the other when/if errors = never a crash
Thoughts? Bad practice? Unforeseen problems? Anything that would cause concern?
|
|
|
Post by Rod on Dec 14, 2022 7:22:27 GMT
You would be better off switching off the main.tb so that the user cannot interfere till the search is done. So as soon as the search is done re enable and set focus to main.tb
|
|
|
Post by xxgeek on Dec 14, 2022 9:34:00 GMT
I'll do that Rod, thanks. Figured out how to get search results in one [enter] hit.
Now when it opens the user types a search word, [hits [enter], and the search list window opens populated. Escape closes the results window. Just as I wanted it to work. For my purposes I never want the #main to close. In fact it won't even be it's own window, just a textbox and a button in a larger window. This is more of an example for others to edit to their liking.
I'll clean it up and post tomorrow.
|
|
|
Post by xxgeek on Dec 14, 2022 20:30:41 GMT
Just posted a new, and possibly the Final version. First post updated. ' NEW Version# 1.3 Dec 14 2022 posted approx 3:20pm (Eastern) ' Now the user can just type a search word and hit [enter] to get results, no more hitting [enter] twice ' When the "Escape" key was pressed. A character was being typed into the search textbox. Fixed ' Noticed a new issue. When "Shift" was pressed a character was being typed into the search textbox ' causing the next search to fail. It also prevented any uppercase characters from being used as search words. Fixed. ' Users can now search for characters like $,#,@,!,~ & * ( ) _ + | without problems ' Main update = When you open this app now, just type a search word and hit [Enter] and the list is populated without ' - having to type ]Enter} again. ' Am I happy now? Darn right I am Anyone finds another issue "I KILL YOU". "There are NO MORE ISSUES" - jk of course, speak up if 'anything at all' comes to mind. You know me, I usually forget "Something" The double [enter] problem was a dumb mistake, but hard to track down. I had it going to [search] after opening and displaying the results page on first search. It needed to go back to the place it was called from. For the versions you guys are working on you may or may not need to do the same.
|
|
|
Post by xxgeek on Dec 14, 2022 20:34:47 GMT
In the post just above this one, I had stated that to fix the double {enter] problem was a need to go to [displatKeysPressed] after opening the results window and that you guys may need to change your versions too. I actually made the opening of the results window a sub, and didn't give it a directive once finished. So it now goes back to where it was called from and DOES NOT go to[displatKeysPressed], sorry about the mistake.
One last thing I wanted to make sure of.
Rod, is this working now as users are expecting it to?
|
|
|
Post by Rod on Dec 15, 2022 13:35:10 GMT
On my PC it is fast enough to not notice anything. On my iMac the search is a lot slower. What happens is that the search text disappears and while the search result window opens, it is blank for a second or more.
To give the user more feedback I would put up a message in the results window saying "Searching" and I would not clear the search term out of main.tb That way the user has some confidence that his search is underway. They will be less likely to click go again which would set us off on an empty string search would it not?
|
|
|
Post by xxgeek on Dec 18, 2022 0:07:11 GMT
On my PC it is fast enough to not notice anything. On my iMac the search is a lot slower. What happens is that the search text disappears and while the search result window opens, it is blank for a second or more. To give the user more feedback I would put up a message in the results window saying "Searching" and I would not clear the search term out of main.tb That way the user has some confidence that his search is underway. They will be less likely to click go again which would set us off on an empty string search would it not? An empty string search will take the code back to [search] I have implemented your suggested change "put up a message in the results window saying "Searching"" Not clearing the textbox will cause another issue, but I'll work on it to see what I can do. My main problem is keeping focus on the #main after opening the #results window. Once opened it gets focus, but I can use code to change to focus on #main. But, if the user clicks in the textbox to do another search aftr the first search focus is lost, and no way for code to change to #main. So, I disabled the textbox to disallow users from editing it manually. But when disabled, and after the first search, whatever gets typed doesn't appear in the textbox, and no search happens, [enter] is useless. I'll keep experimenting for now. If I can't get what I want out of the code, I may have to settle with what I have, but I'm not about to give up yet, I think it may just be my lack of understanding JB code, or my logic. Focus absolutely needs to stay with #main no matter what happens or the user could get confused, although all they would need to do is click the #main window somewhere, or select an item in the list to reset back to operational. Counting on users to do the right thing is an indication the programmer is becoming dilutional.
|
|
|
Post by xxgeek on Dec 21, 2022 6:00:01 GMT
New Version posted in first post of this thread a few seconds ago
' When selecting any of the font resizing buttons the text would resize once and quit. Fixed ' Did some editing to what gets displayed, depending on the circumstances of the results. ' Added indication a search is underway while waiting for a results (for slower older hard drives and PC's) ' Took Rod's advice to avoid complexity and changed from a graphics to dialog windows (on all 3 windows) ' Focus can be lost (by clicking on an open (list)window, including scroll bars, but regained easily ' _ by hitting [enter] or [GO], resetting a font, a checkbox, or clicking anywhere in the small window. ' Escape closes the window with focus, (if main(small window) then all windows close) ' Change - put Contents back functioning for those who like having it available. ' Changes - checkbox and font resize buttons put in view, and main window is slightly smaller ' _ plus the help button has changed from "Help" to "?" ' Change - Contents, Results and Main windows are each separate windows. ' Contents menu opens to the left of Results window when Contents button is pressed '_ and closes if a search is made (can be editted to stay open easily) '_ code lines for changing are marked with a comment.
I think this version addresses every issue mentioned. If I forgot something, or something is amiss, please let me know.
All feedback and suggestions welcome. Please do speak up.
|
|
|
Post by xxgeek on Dec 21, 2022 6:28:54 GMT
Yup, forgot something again. Singleclickselect on results window, fixed in code in first thread.
|
|
|
Post by xxgeek on Dec 21, 2022 7:29:51 GMT
Man, I'm losing it. I did so much experimenting that I rewrote this many times over, and removed a lot to speed things up during testing.
Forgot to copy the jb folder. Fixed in code above.
|
|
|
Post by xxgeek on Dec 24, 2022 2:27:21 GMT
NEW Version # v1.9 Dec 23 2022 posted approx 9:30pm Cleaned up the code a bit. Changed Font resizing method and let Windows take care of initial font size Added the Tutorial menu - The TuT button - Opens to the left of Results Changed name of Contents to Help (space was limited), wanted to keep it tiny, needed room for TUT.
I think that's about it.
|
|